PDA

View Full Version : Horrifyingly bogus things in the world of computers


Paul C. Anagnostopoulos
14th May 2004, 10:32 AM
What are the most horrifyingly bogus things in the world of computers?

My vote for #1 is the Unix case-sensitive file system. Never has something so patently worthless caused so much trouble. A couple days work to fix this would save countless hours of wasted time talking about the case of URLs.

A close second is the abomination known as Perl.

~~ Paul

Iconoclast
14th May 2004, 10:48 AM
Originally posted by Paul C. Anagnostopoulos
What are the most horrifyingly bogus things in the world of computers?

My vote for #1 is the Unix case-sensitive file system. Never has something so patently worthless caused so much trouble.SQL Server's worse. It uses a system that Microsoft calls "case agnostic". It matches object names using no case sensitivity, but if the two or more objects have the same name with different case styles, then it matches that name using case sensitivity.

So, if you have a table called MyTable, you can reference it using the name mytable.

However, if you have two tables MyTable and mytable, then you must exactly match the case of the table you're trying to reference.

It just seems like a potential for confusion with no real benefits.

DickK
14th May 2004, 10:53 AM
May I nominate some bogus behaviours?

17 weeks prior to real date of software delivery into integration test, "It's 99% complete [smirk]...".

"I want some indicative estimates, just for the solution design [snicker]..." otherwise known as "the grindstone on which I will capriciously render your six-monthly performance review to dust".

"This is the data model [fnaarr fnaarr]..." placing down a creased sheet of coffee-mug stained A4 with three boxes, two lines, no relationship names and a sodding Word graphic of a bunch of users gathered round a workstation with the insolent title "User Community".

Oy!

Hagrok
14th May 2004, 10:54 AM
The fact that, even in the latest version of Windows, there are still applications that you have to reboot the machine after installing?

WTF is up with that?

--Dan

Uh_Clem
14th May 2004, 10:55 AM
WWW

The only freakin' letter in the alphabet that has multiple syllablyes and some genius decided to use three of them when any old letter would have done. I wonder how much of my life has been wasted saying "okay, go to doubleyou doubleyou doubleyou dot...."

Iconoclast
14th May 2004, 11:05 AM
Originally posted by Uh_Clem
WWW

The only freakin' letter in the alphabet that has multiple syllablyes and some genius decided to use three of them when any old letter would have done. I wonder how much of my life has been wasted saying "okay, go to doubleyou doubleyou doubleyou dot...." There's a comedian that uses that bit in his act, something along the lines of "Why do we say WWW, it's got nin syllables but World Wide Web has only three". Around my office it's most common to hear someone say "dub dub dub randi org".

roger
14th May 2004, 11:12 AM
Originally posted by Hagrok
The fact that, even in the latest version of Windows, there are still applications that you have to reboot the machine after installing?

WTF is up with that?

--Dan Usually because the application is installing a newer version of a dll that is already in use by the system, and dll's do not have versioning. High bogusity value, yes, but that is "what is up" with that.

roger
14th May 2004, 11:16 AM
How about multiple, inconsistant implementation of strings in MS windows. you have char strings, MBCS (multi byte character strings), and Unicode. Different operating systems use different versions. When programming with COM, then you also have to deal with a whole 'nother string type which is not easily compatible with the std::string or whatever your legacy code may be using. And the requirement to put macros around your quotes T("hi").

Basically, writing any kind of string code in windows in C++ pretty much means that the code will not be portable.

MrMonty
14th May 2004, 11:40 AM
That this 21" monitor in front of me has only 19" viewable. Who let manufacturers get away with measuring things like that? Is that inherited from how TVs are measured? Why not put some extra plastic, give me a useless 2" border, and call it a 23" monitor?

Monty

Iconoclast
14th May 2004, 11:49 AM
Leif Roar just reminded me of another unbelievable annoyance in your other thread on good programming stuff.

Oracle 8i. It actually has two separate compilers, one to compile Stored Procedures, and another to compile Immediate SQL. Now, you'd assume Oracle would use the same compiler for both tasks, and indeed Oracle 9i does, but 8i has a lot of weird stuff. So, 8i the Immediate SQL compiler supports the case statement, but the Stored Proc compiler doesn't. If you need to use the case statement in a stored procedure, you have to instead create a view that contains the stuff that requires the case statement, and use the view in the stored proc. Bleh.

Iconoclast
14th May 2004, 11:52 AM
Originally posted by MrMonty
That this 21" monitor in front of me has only 19" viewable. Who let manufacturers get away with measuring things like that? Is that inherited from how TVs are measured? Why not put some extra plastic, give me a useless 2" border, and call it a 23" monitor?

Monty Well, that dates back to the first days of cathode ray tubes, the size of the tube is the diagonal measurement on it's front face. The beam can't scan right to the edges of the tube, so the size of the image is smaller than the size of the tube. However, new displays that use LCD instead of a CRT don't have this problem, the pixels go (virtually) right to the edge, so if you buy a 17" LCD panel, it will have a 17" picture, which is about the same size as on a 19" CRT.

tedly
14th May 2004, 12:18 PM
The title did say computers- is hardware allowed?

There is a class of things I call butter keepers. (Or maybe Spider Robinson did it first, but the secret to originality is not remembering your sources.) Inside the fridge is a space that we use electricity to keep warm. Outside that is a space that we use electricity to keep cold. That is inside a space that we use gas to keep warm.

Here I sit at a machine that, in the event of a power glitch will save fuses by eating my $300 monitor. So I have an UPS.
AC power is delivered to my house where it is converted to DC and stored, then reconverted to AC and fed to the computer where it is turned back to DC then chopped to a square wave so it can be turned into all those lovely voltages the machine needs. I would love a power suppy that ran my monitor and machine from a 12v DC supply so I could plug in my drill batteries for backup. And charging my portable's batteries might just be the most useful thing I do on the beast.

Hagrok
14th May 2004, 12:32 PM
Originally posted by roger
How about multiple, inconsistant implementation of strings in MS windows. you have char strings, MBCS (multi byte character strings), and Unicode. Different operating systems use different versions. When programming with COM, then you also have to deal with a whole 'nother string type which is not easily compatible with the std::string or whatever your legacy code may be using. And the requirement to put macros around your quotes T("hi").

Basically, writing any kind of string code in windows in C++ pretty much means that the code will not be portable.
On that note, why does MS C++ have DWORD and UDWORD data types? It's exactly the same as a "long" and an "unsigned long"" type as far as I can tell.

Seems fairly pointless unless you're gonna rename all the standard types to something else (I've actually seen plenty of programs that do that).

--Dan

Hagrok
14th May 2004, 12:34 PM
Originally posted by roger
Usually because the application is installing a newer version of a dll that is already in use by the system, and dll's do not have versioning. High bogusity value, yes, but that is "what is up" with that.
Well, I actually knew that, it was more of a rhetorical "WTF is up with that" :p

I think part of the problem, also, is that an installing program frequently dumps a ton of stuff into the windows temp directory that doesn't get removed until you reboot. That also makes no sense :)

--Dan

roger
14th May 2004, 12:41 PM
Originally posted by Hagrok

On that note, why does MS C++ have DWORD and UDWORD data types? It's exactly the same as a "long" and an "unsigned long"" type as far as I can tell.

Seems fairly pointless unless you're gonna rename all the standard types to something else (I've actually seen plenty of programs that do that).

--Dan How long have you been programing?

Back in the day, int was commonly 16 bits. So int would be tydefed as WORD. These days, int is 32 bits, so the typedef is different. C and C++ does not guarantee the sizes of any of the data types, except enforcing ordering (long cannot be shorter than an int).

Basically, it is microsoft's way of enforcing a well defined size to the variables in the API, independent of compiler implementation.

We'll go though this again with the 64 bit chips and operating systems. So long as you used the microsoft typedef, and not int, long, etc, you will be fine. If you used int, you have a lot of recoding to do.

Leif Roar
14th May 2004, 12:52 PM
Originally posted by MrMonty
That this 21" monitor in front of me has only 19" viewable. Who let manufacturers get away with measuring things like that? Is that inherited from how TVs are measured? Why not put some extra plastic, give me a useless 2" border, and call it a 23" monitor?

Monty

Yes, it's inherited from TVs, and the reason is simply that it's a measurement of physical size. It's the maximum dimension of the cathode ray tube, which for various reasons has to be somewhat larger than the viewable area. For LCD screens and plasma screens they actually measure the viewable area, wich is why a 17" LCD screen has as much "screen real-estate" as a 19" CRT.

Hagrok
14th May 2004, 01:24 PM
Originally posted by roger
How long have you been programing?

Back in the day, int was commonly 16 bits. So int would be tydefed as WORD. These days, int is 32 bits, so the typedef is different. C and C++ does not guarantee the sizes of any of the data types, except enforcing ordering (long cannot be shorter than an int).

Basically, it is microsoft's way of enforcing a well defined size to the variables in the API, independent of compiler implementation.

We'll go though this again with the 64 bit chips and operating systems. So long as you used the microsoft typedef, and not int, long, etc, you will be fine. If you used int, you have a lot of recoding to do.
Hmmm, well, ANSI C++ guarantees that short is "at least 16 bits" and long is "at least 32 bits", which should get you through just about anything. Of course, that standard is only 7 years old, and a lot of compilers out there probably don't use it... hell, I've run into embedded compilers in the past few years that make a mockery of any standard. :)

I suppose using the DWORD and UDWORD guarantees that you don't get anything more than 32 bits, which could be important in some instances.

--Dan

{edit}changed bytes to bits.. sheesh!{/edit}

Uh_Clem
14th May 2004, 01:41 PM
MrMonty,

I'm guilty of participating in that scam. I sold thousands of monitors for years before it was called to my attention. I can't believe how long it was before I actually put a tape measure up to one and exclaimed "Well, I'll be damned."

Now, I _could_ make a joke about how this relates to my percetion of my own genetailia...... but this is a pretty clean board.

Paul C. Anagnostopoulos
14th May 2004, 03:59 PM
All excellent bogosities so far. However, I'm shocked no one has said "You're absolutely right, Paul, that Unix case-sensitive file system is the Devil's work!"

~~ Paul

Soapy Sam
14th May 2004, 04:18 PM
Technical support numbers.

I was given one for Philips (A DVD writer) which turned out to be an Indian restaurant in London.

Fortunately, the head waiter had just bought one the same...No, no. I'm lying now. Remember the MISSION.

gnome
14th May 2004, 05:13 PM
Originally posted by Hagrok

Well, I actually knew that, it was more of a rhetorical "WTF is up with that" :p

I think part of the problem, also, is that an installing program frequently dumps a ton of stuff into the windows temp directory that doesn't get removed until you reboot. That also makes no sense :)

--Dan

Based on my experience, that windows automatically deletes anything from the temp directory is pure mythology and wishful thinking.

evildave
14th May 2004, 05:42 PM
Mine does, but only because there's a shortcut to this batch in the 'startup' folder.

In this case, C:\temp is my 'official' temporary folder, but if I log on as 'Administrator' or using a different account, I still need to be able to clean that up.

@echo off
echo Clean out temp files
del /Q /s %temp%\*.*
del /Q /s %tmp%\*.*
del /Q /s C:\temp\*.*

ULTRA BOGUS: Web browsers that download to "C:\temp" and then move it to the place you told it to download it to. On systems where you have multiple volumes, and for big files, this can take a lot of extra time. EVEN WORSE (an IE version did this): When they try to move it, and only then do they discover the destination did not have enough space, the original (cached) file is destroyed as well, so you have to download it from scratch.

WinZip will also use the 'temp' folder when you make an archive, which is truly annoying because when temp is on another volume on the same physical disk, it will thrash the hard disk heads BADLY, and then have to do a very long copy to "finish" its archive. Especially when you want to make an enormous archive.

MEGA BOGUS: Download sites (and browser/ftp/etc. software) that don't support a 'resume' feature. They are trying to be 'fair' because people use download software that opens multiple connections to download different parts of files (which reduces the total number of people who can download at once), but usually what happens is some sort of error occurs 2/3 of the way through downloading and you have to try several times; net download (and bandwidth) required is several times the size of the file you were trying to get.

Yahweh
14th May 2004, 09:47 PM
Totally Bogus:

Line 38.

rockoon
14th May 2004, 10:38 PM
The completely idiotic names for windows services

Iconoclast
14th May 2004, 11:39 PM
Originally posted by Hagrok
I suppose using the DWORD and UDWORD guarantees that you don't get anything more than 32 bits, which could be important in some instances.No, Microsoft uses typedefs for the opposite reason. For example, many windows messages supply a WPARAM and an LPARAM, so if you wish to handle that message your function SHOULD be something like:

LRESULT CMyClass::OnMyMessage(WPARAM wParam, LPARAM lParam)
{

}

but unfortunately, many people are lazy and just use:

LRESULT CMyClass::OnMyMessage(long wParam, long lParam)
{

}

Now, WPARAM is currently a typedef of unsigned int (actually it's a typedef of UINT which is in turn a typedef of unsigned int) , and LPARAM is currently a typedef of long. In a future version of Windows, Microsoft might typedef WPARAM and LPARAM to 64 bit types, so when this happens, the code in my second example will no longer compile since we'll be trying to pass a 64 bit piece of data into a 32 bit parameter.

Zombified
14th May 2004, 11:48 PM
Originally posted by roger
How about multiple, inconsistant implementation of strings in MS windows. you have char strings, MBCS (multi byte character strings), and Unicode. Different operating systems use different versions. When programming with COM, then you also have to deal with a whole 'nother string type which is not easily compatible with the std::string or whatever your legacy code may be using. And the requirement to put macros around your quotes T("hi").

Basically, writing any kind of string code in windows in C++ pretty much means that the code will not be portable. Some of this wasn't Windows fault so much as the whole world of character encodings, to which Windows (and DOS) was merely a contributor. (That macro was supposed to allow portability if you were good about using it and tchar or whatever the type was...)

No support for Unicode is just one of many reasons to forget the Win9X variations of Windows ever existed.

Nonetheless, Unicode has its own share of annoyances, and if you are serious about international text, you are really in for some headaches.

Half-width and full-width katakanas from DBCS: An artifact of early Japanese text video cards, but they're still in Unicode. Are these two katakana strings the same or not?

Han unification in Unicode. Universal character set? Not really...

Did you know there's still lead and trail code points in Unicode? Yup! The creature lives! Fortunately, now those ranges are unique, so you know by looking at just one character whether it's a trail point or not... but still.... ick.

Multiple ways to encode accents in Unicode: you get both character-with-accent points, and you get combining diacritical code points you can put after an unaccented letter! Sort and compare algorithms, start your engines... actually, diacriticals behave a little like trail characters: they aren't whole characters by themselves, really.

Breaking Japanese text into lines: no space characters! Very complicated rules for determining where you can break lines!

Hebrew and Arabic. Right to left layout, practically the whole screen is reversed, in fact. However, if you quote English, or if you include a Latin-numeral number, it is written left-to-right, so you have to actually reverse the order of layout mid-line.

In Arabic, you get the extra bonus feature of combining multiple characters into single-glyph ligatures, plus text is justified by stretching strokes rather than inserting space.

Some letters are lower case only, for example the German ss (looks like a Greek beta). What's toupper supposed to do?

Turkish: has an I with a dot, and one without, in both lower and upper case. Some code is more zealous about normalizing than other code, and may or may not treat the two I's as equivalent.

General metacomplaint: actually comparing or sorting strings correctly (for a given culture) is a major nuisance.

Oh yes, and Unicode byte-order marks... yecccch.

Zombified
14th May 2004, 11:55 PM
Originally posted by Iconoclast
No, Microsoft uses typedefs for the opposite reason. For example, many windows messages supply a WPARAM and an LPARAM, so if you wish to handle that message your function SHOULD be something like...You're right in that instance, but there are typedefs for both purposes: some (like LPARAM) change when your integer and/or pointer size do, and others (like DWORD) don't.

Iconoclast
15th May 2004, 12:28 AM
Originally posted by Zombified
You're right in that instance, but there are typedefs for both purposes: some (like LPARAM) change when your integer and/or pointer size do, and others (like DWORD) don't. Yes, but WORD and DWORD were created for the C++ SDK V1.0, which was around the same time that most compilers' definition of an int changed from 16 bits to 32 bits, and the ANSI version of an int was not fixed at 32 bits until later. So yes, Miscorsoft defined the WORD and DWORD because at the time the size of an int was compiler specific, not fixed.

evildave
15th May 2004, 12:30 AM
Actually Microsoft should've enumerated the messages; i.e.
enum WindowMessage
{
WM_COMMAND = 0,
WM_PICKYOURNOSE,
WM_ETC
};

Then made the 'param' parameters unions. To actually use the language, anyway. Then a lot of debuggers would've been able to just tell you that it was 'WM_MOUSEMOVE' instead of '132'.

But even more horrible, the deepest sin I've ever seen, repeatedly in API libraries: not using 'const'.

When you use const, it makes a lot of code easier and makes a lot of errors 'obvious', and then when the API you have to call doesn't use const, it becomes a punishment.

Leif Roar
15th May 2004, 12:38 AM
Originally posted by Zombified
Some letters are lower case only, for example the German ss (looks like a Greek beta). What's toupper supposed to do?

I don't think that's unicode's fault though. The German double-s is a ligature rather than an actual letter in it's own right and, as far as I know, it's only ever used to replace the lower-case "ss" - upper-case "SS" are just written as "SS". (Since no words in German begins with ss you very rarely need upper-case "SS" anyway.)

Iconoclast
15th May 2004, 12:50 AM
Originally posted by evildave
Actually Microsoft should've enumerated the messages; i.e.
enum WindowMessage
{
WM_COMMAND = 0,
WM_PICKYOURNOSE,
WM_ETC
};

Then made the 'param' parameters unions. To actually use the language, anyway. Then a lot of debuggers would've been able to just tell you that it was 'WM_MOUSEMOVE' instead of '132'.Microsoft weren't able to define all the message types as an enumeration for two reasons. Firstly, WIndows was designed with extensibility in mind, so a programmer can create User Messages which are simply user defined messages, very commonly used by control library developers. To avoid value clashes with any of the Windows defined message IDs, there's a #define called WM_USER which is the lowest value of a UINT we are allowed to use when creating custom messages, so we give our message IDs a value like WM_USER + 1, WM_USER + 2 etc, these message IDs only need be unique within a single application.

Secondly, Windows allows us to register new messages at runtime using such calls as RegisterWindowsMessage which passes back a UNIT that is unique for our message throughout the system. This functionality is required for passing unique messages between applications.

Originally posted by evildave
But even more horrible, the deepest sin I've ever seen, repeatedly in API libraries: not using 'const'.Yes, but using a wrapper library like MFC abstracts us away from such issues since the MFC guys were more careful to explicitly mark parameters that should be constant as const.

Zombified
15th May 2004, 08:12 AM
Originally posted by Leif Roar
I don't think that's unicode's fault though. The German double-s is a ligature rather than an actual letter in it's own right and, as far as I know, it's only ever used to replace the lower-case "ss" - upper-case "SS" are just written as "SS". (Since no words in German begins with ss you very rarely need upper-case "SS" anyway.) You just reminded me of another Unicode bitch: it contains ligatures when it was supposed to only contain characters. Besides German ss there's at least ae, fi and fl.

These are there for backwards compatibility - so you can round-trip strings in old 8-bit language-specific code pages to Unicode and back again without messing up the ligatures.

Another mess for normalizing strings...

Paul C. Anagnostopoulos
15th May 2004, 08:41 AM
But if Unicode didn't contain all the ligatures, how would you represent them in a Unicode string? For example, how would you access them from a font encoded in Unicode?

~~ Paul

NightG1
15th May 2004, 09:03 AM
This is a horribly non-technical rant but...what's up with Macromedia's "upgrade"policies. I checked a while back to see what it would cost to upgrade my copy of Freehand 7 to Freehand MX and the answer turned out to be that I couldn't. I would have had to purchase a new copy of MX for $400. Seeing red, I immediately checked the Canvas 9 web site and I could (and did) upgrade my copy of Canvas 5 to Canvas 9 for $100. In fact I could have upgraded my copy of 3.5 for the same cost. I know Canvas is somewhat underpowered compared to the vector tools you get with MX or Illustrator but a for a hundred bucks I'll stick with Canvas. Macromedia won't see another dime from me.

Zombified
15th May 2004, 09:13 AM
Originally posted by Paul C. Anagnostopoulos
But if Unicode didn't contain all the ligatures, how would you represent them in a Unicode string? For example, how would you access them from a font encoded in Unicode?Characters and glyphs are different things, and ligatures are glyphs. Unicode was supposed to be characters and not glyphs, but unfortunately, legacy code pages contained both.

The clearest example is the fi ligature. If you are a really hardcore typesetter, an i following an f shouldn't have the dot over it; when the characters are properly positioned the dot collides with the f's ascender. This is purely a typesetting convention and has no linguistic significance whatsoever: the characters are still an f and an i.

Your typeface should have an (fi) ligature in it. But the characters are (f) and (i) so if you are uppercasing, comparing, sorting, or scanning for vowels or whatever, that's how you should treat them. If you have an (fi) ligature in your Unicode string, comparing by a simple point-by-point equality is wrong: you have to normalize your strings first.

If you have a character string, you really ought not to represent ligatures at all; it should be a function of the text-scribbling support in your graphics engine to do the translation from strings of characters to strings of glyphs.

Here's a fun hypothetical security bug: let's say you have some code that takes a URL in from the outside world, and you disallow file: because you don't want something access the local file system. So you compare the first five characters of the string to "file:". But if the OS does a proper Unicode normalization of all strings, and I, evil haxx0r, give you a URL starting with "(fi)le:" your comparison will fail while the OS's will work. Oops, now I can pass you file: URLs.

Unfortunately, with all the ligatures Unicode does include, plus all the accented characters (instead of using combining diacriticals) Unicode has made just as many concessions to glyphs as any old codepage. We're stuck with this confusion forever.

I'll grant, as well, there's cases where dealing with the glyphs themselves is important. It's just unfortunate systems couldn't have been more disciplined about the difference.

roger
15th May 2004, 09:38 AM
Originally posted by Zombified
Nonetheless, Unicode has its own share of annoyances, and if you are serious about international text, you are really in for some headaches.

Half-width and full-width katakanas from DBCS: An artifact of early Japanese text video cards, but they're still in Unicode. Are these two katakana strings the same or not?. I've done my share of Japanese text processing, and I hear you.

One thing I haven't had to deal with is the vertical and horizontal writing that I think Thai uses. And I donwanna.

scribble
15th May 2004, 09:44 AM
Originally posted by Iconoclast
So yes, Miscorsoft defined the WORD and DWORD because at the time the size of an int was compiler specific, not fixed.

Last time I read the C++ official standard, the sizeof() int, char, and every other internal type wasn't fixed. Still isn't. Are you really suggesting it's fixed now? Or was that just bad wording?

roger
15th May 2004, 09:48 AM
Originally posted by Iconoclast
Yes, but WORD and DWORD were created for the C++ SDK V1.0, which was around the same time that most compilers' definition of an int changed from 16 bits to 32 bits, and the ANSI version of an int was not fixed at 32 bits until later. So yes, Miscorsoft defined the WORD and DWORD because at the time the size of an int was compiler specific, not fixed. int is STILL compiler specific. When we start using 64 bit operating systems, int will be 64 bits for most compilers.

Plus, don't forget that windows doesn't just run on x86. There are all those CE devices, with various architectures, etc. The true bogosity would be if microsoft used int, long, etc.

this is a place where they definitely did it right. I do exactly the same thing when writing code for an embedded processor. You have to.

A good rule of thumb for truly portable code is NEVER to use built in types. I feel that is somewhat overstated, but there are very good reasons for it.

It's probably worth mentioning that although most of my development these days is just windows stuff, I come from an embedded background, where I used different compilers for the same code, different processors, etc. int, long, etc., will bite you in the @ss in that environment, and they will bite you each time the x86 family changes word lengths.

Leif Roar
15th May 2004, 10:01 AM
Originally posted by Zombified
You just reminded me of another Unicode bitch: it contains ligatures when it was supposed to only contain characters. Besides German ss there's at least ae, fi and fl.

Æ, at least, is both a ligature and a letter - depending on what language you're using. (It's a ligature in English, but a separate letter in Norwegian.)

Iconoclast
15th May 2004, 10:10 AM
Originally posted by scribble
Last time I read the C++ official standard, the sizeof() int, char, and every other internal type wasn't fixed. Still isn't. Are you really suggesting it's fixed now? Or was that just bad wording? No, you're right. I was under the erroneous impression that the size of int had been fixed by ANSI. They have however defined types such as __int32, __int64 etc for fixed sized types.

Zombified
15th May 2004, 10:25 AM
Originally posted by Leif Roar
Æ, at least, is both a ligature and a letter - depending on what language you're using. (It's a ligature in English, but a separate letter in Norwegian.) I did not know that, but this, I think, illustrates the problem of mixing glyphs and characters: the character Æ and the glyph Æ are two different things and ought not to have been assigned the same code point. If the English Æ had been treated strictly as a glyph and not a character, there would be no ambiguity.

As a result of this (it's a good example) I actually need to know what language I'm using in order to compare correctly: if I'm comparing English, I need to normalize Æ into AE, and if I'm comparing Norwegian, I must not.

This is why Windows has those culture-dependant string functions, along with the so-called "invariant culture" used for strings that aren't in a particular language (internal strings like registry keys, identifiers, etc), or, too often, because a programmer is too lazy to treat you like a proper Norwegian instead of a generic American-like creature.

I'm not naive enough to believe that a more disciplined approach would have solved all the culturally-senstive aspects of text processing, but it could have been simpler...

Paul C. Anagnostopoulos
15th May 2004, 12:00 PM
Zombified, I understand your objections to ligatures in Unicode, but I still don't understand how I could access one from a Unicode-encoded font if they weren't assigned Unicode values. Perhaps the concept of a Unicode-encoded font is bogus?

Seems to me that each Unicode glyph needs a boolean attribute that says whether it's an actual character in a language or a ligature/whatever. Then you could easily check a string to make sure it contains only characters.

Note that from Unicode I know nothing.

~~ Paul

Zombified
15th May 2004, 02:06 PM
You have to have a seperate encoding for glyphs in fonts, and a mapping from character strings to glyph strings that selects ligatures and/or glyph alternatives alternatives.

OpenType does this: it supports a number of features for translating character strings into glyph strings including character composition, ligature substitution, and contextual ligatures. It's the glyphs that are represented by paths in an OpenType font.

There are ligatures and glyph variations that don't have Unicode code points, a few in Western languages and a whole lot in Arabic. In fact, different Arabic fonts use different sets of ligatures because they are based on different calligraphic styles.

Also, you still have to normalize text to get the right ligatures, for example, if the text entered contains "(f)(i)" but you need to paint "(fi)". So you end up having to do all these substitutions whether the encoding contains code points for ligatures or not.

It's the old joke: any problem in computer science can be fixed by adding a level of indirection, except performance problems, which are fixed by eliminating levels of indirection. And you can optimize any program if correctness is not a requirement. ;)

evildave
15th May 2004, 02:21 PM
Originally posted by Iconoclast
Microsoft weren't able to define all the message types as an enumeration for two reasons. Firstly, WIndows was designed with extensibility in mind, so a programmer can create User Messages which are simply user defined messages, very commonly used by control library developers. To avoid value clashes with any of the Windows defined message IDs, there's a #define called WM_USER which is the lowest value of a UINT we are allowed to use when creating custom messages, so we give our message IDs a value like WM_USER + 1, WM_USER + 2 etc, these message IDs only need be unique within a single application.

Secondly, Windows allows us to register new messages at runtime using such calls as RegisterWindowsMessage which passes back a UNIT that is unique for our message throughout the system. This functionality is required for passing unique messages between applications.

Yes, but using a wrapper library like MFC abstracts us away from such issues since the MFC guys were more careful to explicitly mark parameters that should be constant as const.

It's quite simple to 'extend' an enumeration. You simply cast it away and throw invalid values through. Of course, this is "bad", but so is just passing an int with preprocessor defined labels to switch off of.

My preferred method for writing an enum is...

#define ENUM_SOMETHING(def) \
def(eFirst) \
def(eSecond) \
def(eThird) \
def(eFourth)

typedef enum
{
#define Xtract(def) def ##_Something,
ENUM_SOMETHING(Xtract)
Count_Something
#undef Xtract
} Something;


Primarily because I can generate different kinds of things based on the code. For instance, if I wanted to build a switch or vector table based on that enumeration, I would write a dispatcher that token pasted the enum and extracted it to the table, and named the dispatch functions accordingly. No muss, no fuss.

I also tend to wrap a lot of disperate kinds of things in the same enum to be extracted into different places in the runtime code with extractor 'queries'.



// Card suits (EDEF_CARD must match: see below)
#define EDEF_SUIT(def) \
def( sC, "c", "club", "clubs" )\
def( sD, "d", "diamond", "diamonds" )\
def( sH, "h", "heart", "hearts" )\
def( sS, "s", "spade", "spades" )

// Card rankings
#define EDEF_RANK(def) \
def( r2, "2", "deuce", "deuces" )\
def( r3, "3", "three", "threes" )\
def( r4, "4", "four", "fours" )\
def( r5, "5", "five", "fives" )\
def( r6, "6", "six", "sixes" )\
def( r7, "7", "seven", "sevens" )\
def( r8, "8", "eight", "eights" )\
def( r9, "9", "nine", "nines" )\
def( rT, "T", "ten", "tens" )\
def( rJ, "J", "jack", "jacks" )\
def( rQ, "Q", "queen", "queens" )\
def( rK, "K", "king", "kings" )\
def( rA, "A", "ace", "aces" )


This allows me to glue a lot of things together that can be extracted (or not) at no runtime cost. I can even perform SQL database like queries against the preprocessor data to extract specific rows and columns by keying certain details among the definitions.

If I wanted to allow an enumeration to be "extended", I could (for instance):



typedef enum Extensible
{
DEF_EXTENSIBLE(xtract);
#ifdef USER_EXTENSION
USER_EXTENSION(xtract);
#endif
} Extensible;



So don't tell me that enumerations "aren't extensible" just because you personally haven't put any thought into how to do it. You may as well claim the "C preprocessor is useless" because you don't understand how to use that, either.


MFC is an absolute horror. I've used it. I've dissected it. I officially dismissed it for my work. wxWindows (http://www.wxwindows.org/) (wxWidgets) is a lot closer to what I'd prefer to work with when I want one more big, fat sloppy layer of abstraction. At least it's not quite as big, fat and sloppy as MFC, and I get to support more platforms than MS Windows, MS Windows and MS Windows.

There is nothing in MFC for me. The most efficient way to write a GUI interface is still the WindowProc, assuming you know what you're doing. Both in time spent writing the code and in time spent running it. If you "don't understand", then by all means let the 'Wizard' write your application for you, but be warned the first time you want to do anything besides display one of their grey boxes "their way", you will have one hell of a time learning all the guts of Windows you didn't want to understand, anyway.

Rat
15th May 2004, 06:16 PM
Originally posted by NightG1
This is a horribly non-technical rant but...what's up with Macromedia's "upgrade"policies. I checked a while back to see what it would cost to upgrade my copy of Freehand 7 to Freehand MX and the answer turned out to be that I couldn't. I would have had to purchase a new copy of MX for $400. Seeing red, I immediately checked the Canvas 9 web site and I could (and did) upgrade my copy of Canvas 5 to Canvas 9 for $100. In fact I could have upgraded my copy of 3.5 for the same cost. I know Canvas is somewhat underpowered compared to the vector tools you get with MX or Illustrator but a for a hundred bucks I'll stick with Canvas. Macromedia won't see another dime from me.
Macromedia won't see custom from a lot of former customers. See their own forums for evidence. If you buy Freehand MX now, all well and good. We (at work) got it when it came out. Never has such a bug-ridden, unwieldy pile of crap been released to the public. I believe that MX is actually version 11. So they released a patch, 11.01, that makes it at least semi-workable. Then they released another, 11.02, that apparently fixes most of the problems; and these weren't trivial problems. It would sometimes, indeed often, corrupt a document from a previous version on opening it, and make it unopenable thereafter, even if it wasn't specifically saved.

But can you just go to the Macromedia website and download a patch? No. Presumably because it was so bollocksed up that they had to recreate the entire application from scratch, and didn't want people downloading the whole package (this is a BIG download), you have to ring them up (not a free number by any standards) and give them your original registration details. Name, address, serial number, and so on.

This wouldn't be so bad, except that I never personally registered it. The lass on the phone couldn't tell me who had, because of data protection. She could only tell me a postcode, which I could tell was geographically really quite close, but I didn't know where. It turned out that it was registered by a former employee who had given his home address in the registration. But they wouldn't give me the download until I told them the name under which it was registered, which I didn't then know.

Unbelievable.

Autodesk are not very forthcoming with customer support or bug fixes, either. Which may come as a surprise to some users after they've paid £3500 or so for the product. They're very supportive if you're buying; but not so if you've bought.

Dell are also very helpful if you ring their business tech support line. But my mother has a Dell, and it's a VERY different story if you're a non-business customer. I know this is true for most companies, but not to anything like this extent.

Cheers,
Rat.

Leif Roar
16th May 2004, 12:31 AM
Originally posted by Zombified
I did not know that, but this, I think, illustrates the problem of mixing glyphs and characters: the character Æ and the glyph Æ are two different things and ought not to have been assigned the same code point. If the English Æ had been treated strictly as a glyph and not a character, there would be no ambiguity.

There wouldn't have been any ambiguity, but then you'd end up with people using the ligature instead of the character, and vice versa, and programs that have to deal with the character would have to check both for the character and the ligature anyway. It's a lose-lose situation, really.

Iconoclast
16th May 2004, 05:56 AM
Originally posted by evildave
It's quite simple to 'extend' an enumeration. You simply cast it away and throw invalid values through.Sure, but that completely defeats the purpose of defining an enum in the first place.
Originally posted by evildave
Of course, this is "bad", but so is just passing an int with preprocessor defined labels to switch off of.Well, when it comes to the Windows messaging system (is that still what we're talking about), I would have preferred it if Microsoft had used const UINT instead of #define to define Message and Resource IDs, only because #defines don't end up in the debug symbol file, so the debugger doesn't know that (say) ID_MY_CTRL is equal to the value 2254.
Originally posted by evildave
My preferred method for writing an enum is...

#define ENUM_SOMETHING(def) \
def(eFirst) \
def(eSecond) \
def(eThird) \
def(eFourth)

typedef enum
{
#define Xtract(def) def ##_Something,
ENUM_SOMETHING(Xtract)
Count_Something
#undef Xtract
} Something;


Primarily because I can generate different kinds of things based on the code. For instance, if I wanted to build a switch or vector table based on that enumeration, I would write a dispatcher that token pasted the enum and extracted it to the table, and named the dispatch functions accordingly. No muss, no fuss.

I also tend to wrap a lot of disperate kinds of things in the same enum to be extracted into different places in the runtime code with extractor 'queries'.



// Card suits (EDEF_CARD must match: see below)
#define EDEF_SUIT(def) \
def( sC, "c", "club", "clubs" )\
def( sD, "d", "diamond", "diamonds" )\
def( sH, "h", "heart", "hearts" )\
def( sS, "s", "spade", "spades" )

// Card rankings
#define EDEF_RANK(def) \
def( r2, "2", "deuce", "deuces" )\
def( r3, "3", "three", "threes" )\
def( r4, "4", "four", "fours" )\
def( r5, "5", "five", "fives" )\
def( r6, "6", "six", "sixes" )\
def( r7, "7", "seven", "sevens" )\
def( r8, "8", "eight", "eights" )\
def( r9, "9", "nine", "nines" )\
def( rT, "T", "ten", "tens" )\
def( rJ, "J", "jack", "jacks" )\
def( rQ, "Q", "queen", "queens" )\
def( rK, "K", "king", "kings" )\
def( rA, "A", "ace", "aces" )


This allows me to glue a lot of things together that can be extracted (or not) at no runtime cost. I can even perform SQL database like queries against the preprocessor data to extract specific rows and columns by keying certain details among the definitions.

If I wanted to allow an enumeration to be "extended", I could (for instance):



typedef enum Extensible
{
DEF_EXTENSIBLE(xtract);
#ifdef USER_EXTENSION
USER_EXTENSION(xtract);
#endif
} Extensible;



So don't tell me that enumerations "aren't extensible" just because you personally haven't put any thought into how to do it.I didn't say enumerations weren't extensible, I said that Windows was designed with extensibility in mind, quite another thing. Now, if you want to come up with some data structure and call it an "enum" and then claim that enums are extensible, go for gold, but the C++ enum by it's very design has only a limited set of values, that's the whole point of them.

Originally posted by evildave
You may as well claim the "C preprocessor is useless" because you don't understand how to use that, either.Um, where did you get that idea? And why have you decided to adopt this condescending tone? While macros certainly have their place (I used to use them to define complex try/catch routines to remove that code from the body of functions), I've also seen many instances where someone's been so clever with a macro that nobody else on the design team can understand what's going on. If you've got tight constraints on available memory, or you're building real time apps where every instruction cycle counts, then extensive use of macros may reduce the footprint of the application and make it faster, but where such things are not critical I prefer clean easy to read code.
Originally posted by evildave
MFC is an absolute horror. I've used it. I've dissected it. I officially dismissed it for my work.You've "officially dismissed" it? I guess I never read the press release. I know a lot of programmers who absolutely hate MFC, and it leaves me a little baffled. I've used MFC in Visual C++ from version 1.52 right through to Version 6, though I've not used VC Version 5 which apparently came with a dodgy build of MFC, and I've always found it to be a truly lovely class library to work with. Sure, the VersionableSchema code is broken and never got fixed (it may have been fixed in Visual Studio 7, I dunno), and I think the PropertySheet/PropertyPage model is flawed, but apart from that I can't really think of anything about MFC that I hate. Since this is the thread to slag off anything you hate in the world of computers, would you be able to give some specific examples of MFC that are an "absolute horror"? I'm not saying I won't agree with you, perhaps I'm looking back with rose-coloured glasses, but I was pretty much in love with MFC when I used to use it.
Originally posted by evildave
wxWindows (http://www.wxwindows.org/) (wxWidgets) is a lot closer to what I'd prefer to work with when I want one more big, fat sloppy layer of abstraction. At least it's not quite as big, fat and sloppy as MFC, and I get to support more platforms than MS Windows, MS Windows and MS Windows.See, here's where things get interesting. Perhaps half the people I've talked to who hate MFC cite that it's extremely heavy, yet the other half hate it because Microsoft didn't provide many advanced controls, unlike products such as Delphi and VB that came out of the box with a billion or so controls. Regarding this lack of advanced controls, the MFC team never intended to include such things, as the name implies, MFC is a Foundation upon which third parties are expected to build. It neatly abstracts away a lot of the tedium of writing windows applications so the developer can concentrate on the task at hand. Now as to your claim that MFC is "big, fat and sloppy", I've stepped across a large portion of MFC during discovery and debugging sessions, and I can't see your point. The MFC code from memory) wraps up the Windows windows into real objects so I don't have to, it has a bunch of asserts to make sure all the function parameters are valid, a bunch of checks to make sure that the Windows objects are getting created properly, all the stuff that I'd have to add myself if MFC didn't do it for me. Originally posted by evildave
There is nothing in MFC for me. The most efficient way to write a GUI interface is still the WindowProc, assuming you know what you're doing. Both in time spent writing the code and in time spent running it.I don't think it will come as a surprise to anyone that calling a Windows API method directly will be faster than calling a method on an MFC object, but that's scarcely the point. MFC is a class for writing object oriented, rich GUI desktop applications, so all the Windows window objects have been wrapped up into nice objects with a (usually) understandable set of public methods. If you're going to build a large scale application with a plethora of different document types, each allowing several different views on the document data, then using the Windows API will require the developer to write several orders of magnitude more code than if he'd used MFC, so I don't see how your assertion that writing directly against the Win API required less pregramming effort. If you're talking about a simple, single window application, then it may be possible to get it done with less lines of code than in MFC, but only for the most trivial of applications.

Which reminds me, for anyone who's interested, Microsoft released their excellent WTL (Windows Template Library) source code onto Source Forge this week. This is a library that extends ATL to allow the creation of very lightweight, simple Windows GUI applications for when most of the features of MFC aren't required, so if you're interested, check it out.
Originally posted by evildave
If you "don't understand", then by all means let the 'Wizard' write your application for you, but be warned the first time you want to do anything besides display one of their grey boxes "their way", you will have one hell of a time learning all the guts of Windows you didn't want to understand, anyway. Well, that's the case with a lot of things, if you're doing something radically different to what the library developers envisaged, you'll have to go outside of it to get the job done. In any case, the point of using MFC is not that the developer doesn't want to learn the Windows API, we use it because it provides greater productivity and more simplicity by leveraging a bunch of pre-built classes, that's what any class library that sits on top of Windows does. By your logic we should all still be programming in assembler.

evildave
16th May 2004, 12:46 PM
I'm always doing something "radically different", and you ignored the point about wxWindows supporting other platforms besides Windows, something MFC was originally intended for, but "somehow" got lost over the years.

A library on top of windows would be worth it for cross-platform compatibility.

MFC is not "worth it"... unless all you do is exactly what MFC generates its default little application frames for, and all the cookie cutter "make me a function" stuff fits perfectly with what you do most of the time. Not for me.


Exerpted from C:\dev\vcnet\Vc7\atlmfc\src\mfc\wincore.cpp; Code is "Copyright (C) 1992-2001 Microsoft Corporation"

const AFX_MSGMAP_ENTRY* AFXAPI
AfxFindMessageEntry(const AFX_MSGMAP_ENTRY* lpEntry,
UINT nMsg, UINT nCode, UINT nID)
{
#if defined(_M_IX86) && !defined(_AFX_PORTABLE)
// 32-bit Intel 386/486 version.

ASSERT(offsetof(AFX_MSGMAP_ENTRY, nMessage) == 0);
ASSERT(offsetof(AFX_MSGMAP_ENTRY, nCode) == 4);
ASSERT(offsetof(AFX_MSGMAP_ENTRY, nID) == 8);
ASSERT(offsetof(AFX_MSGMAP_ENTRY, nLastID) == 12);
ASSERT(offsetof(AFX_MSGMAP_ENTRY, nSig) == 16);

_asm
{
MOV EBX,lpEntry
MOV EAX,nMsg
MOV EDX,nCode
MOV ECX,nID
__loop:
CMP DWORD PTR [EBX+16],0 ; nSig (0 => end)
JZ __failed
CMP EAX,DWORD PTR [EBX] ; nMessage
JE __found_message
__next:
ADD EBX,SIZE AFX_MSGMAP_ENTRY
JMP short __loop
__found_message:
CMP EDX,DWORD PTR [EBX+4] ; nCode
JNE __next
// message and code good so far
// check the ID
CMP ECX,DWORD PTR [EBX+8] ; nID
JB __next
CMP ECX,DWORD PTR [EBX+12] ; nLastID
JA __next
// found a match
MOV lpEntry,EBX ; return EBX
JMP short __end
__failed:
XOR EAX,EAX ; return NULL
MOV lpEntry,EAX
__end:
}
return lpEntry;
#else // _AFX_PORTABLE
// C version of search routine
while (lpEntry->nSig != AfxSig_end)
{
if (lpEntry->nMessage == nMsg && lpEntry->nCode == nCode &&
nID >= lpEntry->nID && nID <= lpEntry->nLastID)
{
return lpEntry;
}
lpEntry++;
}
return NULL; // not found
#endif // _AFX_PORTABLE
}


Here is a little example of what's wrong in MFC. For every touch of the mouse (WM_MOUSEMOVE), every WM_TIMER, every PostMessage or SendMessage, the above linear search occurs. Not just for the top-level window, either. No, it has to percolate through class after class of linear searches. From the top-level application window to the

Have a look at
BOOL CWnd::OnWndMsg(UINT message, WPARAM wParam, LPARAM lParam, LRESULT* pResult) to see what else happens in every window.

What do you say? They 'optimized it' as assembly code? Oh goody, goody. They may as well have optimized a bubble sort to ASM to run a database.

The third problem with MFC (besides being locked into flavors of Microsoft Windows ONLY, and this 'flexibility' that amounts to shoveling CPU cycles into the bit bucket), is that it generates code much larger than you should expect. Of course, given Parkinson's Law of data, this is unsurprising, but why embrace a bad example of how to do things?

As for wrapping API functions in classes, let's have a look at this, now. If you were to wrap, say a rendering Device Context in a class, would you simply grab every function in the Win32 API that takes an HDC and paste them into a class body, and then take the HDC parameters out of each and make it a member of a class and call it a brilliant achievement? Perhaps so. I wouldn't.

Perhaps this is because I would have a specific sort of rendering that I need to do, and will write functions that help to do it, rather than blindly echo the awful naming and calling conventions the Win32 SDK evolved with.

How about the Window dispatch code? Wrapping that in exactly the same way, but adding a that dispatch layer into the dispatch and hiding HWND sounds 'brilliant' to you? After all these years, you'd think they would spend an hour and improve it. Maybe not.

Basically, MFC provides no real help over invoking things with the Win32 SDK, especially for someone who has to write graphical interfaces that are not based on grey boxes in grey boxes.

Now let's look at all of those 'common controls' that MFC helps you to use! This is the very best!

You see, if you look into it, those natively supported 'widgets' in Microsoft Windows require specific versions of Internet Explorer or (by extension) versiuons of Windows. If your user is running Win98 (and let's face it, if you're using MFC to develop your code, it probably bloated up so big by now it won't run on most '98 boxes anymore), and you just used the things .NET provided for you, guess what? You're going to have to require that this customer either upgrade Windows or install a new version of Internet Explorer. Both operations potentially will cripple their computer, because lots of nasty bad old software like Virus scanning junk hook into things they "shouldn't", and when they blindly follow your instructions to "upgrade", there's a good chance their computer will not boot afterwords, or will have lots of nasty stability issues. Now it's a problem for your customer support, who can respond with the ever helpful "Reinstall Windows" or "Call Microsoft" advice that really endears you to everyone.

Reb
16th May 2004, 01:21 PM
Originally posted by Iconoclast
SQL Server's worse. It uses a system that Microsoft calls "case agnostic". It matches object names using no case sensitivity, but if the two or more objects have the same name with different case styles, then it matches that name using case sensitivity.

So, if you have a table called MyTable, you can reference it using the name mytable.

However, if you have two tables MyTable and mytable, then you must exactly match the case of the table you're trying to reference.

It just seems like a potential for confusion with no real benefits.

This seemed strange to me (contrary to my experience) so I tried to test it using this script on my SQL2000 server:

create table MyDate (datecol datetime)
go
create table mydate (datecol datetime)

It wouldn't run the second statement, giving me a "already an object named mydate ..." message. Could you cite the source for this "case agnostic" term? I could not find the term in BOL.

Reb

Wudang
17th May 2004, 05:09 AM
COBOL

At university in the 80s I learned Pascal, some C and Ada. I got my first job and had to learn PL/1 and 370 assembler. Later I learned some PL/AS, C++, Rexx, ksh etc etc. Then in 99 I joined this company and had to pick up COBOL. WTF? A '.' signifies the end of a block? IBM's High-Level Assembler has a more modern syntax!! I had to re-configure my editor to highlight periods in glaring turquoise when I was doing maintenance coding. And how often have I had this conversation
X: "I don't get you. I think COBOL is a great language"
Me: "How many have you worked with?"
X: "Just COBOL"
Me: "Oh, I'm terribly sorry. Were those your teeth?"

And I can only set an address to a Level 1 something in the Linkage Section? And trying to explain linked-list processing to someone who thinks in COBOL? "But how do you fit all that as a level ......"
"Oh I'm terribly sorry. Were.." etc

Fortunately I spent years doing press-ups on my finger-tips so my fingers aren't worn down to stubs yet. And I dumped my new keyboard for an old IBM PS/2-style 166 keyboard which can take the battering.

a_unique_person
17th May 2004, 06:38 AM
Originally posted by Paul C. Anagnostopoulos
All excellent bogosities so far. However, I'm shocked no one has said "You're absolutely right, Paul, that Unix case-sensitive file system is the Devil's work!"

~~ Paul

It is, and so is 'hidden files' that start with a full stop. WTF is that. They aren't really hidden, nor are they really visible. Just f**ing annoying.

Also, the rubbish that was spouted, when I was an IBM systems programmer, about how Unix was a fast, small operating system that dispensed with all that mainframe overkill.

Guess what, all that overkill is being added, bit by bit, because it's all necessary. Reliability, security and tolerance to stress are all required to make an operating system do what it is supposed to do, that is, keep on working.

Unix is now every bit as complex as MVS was, and there is no way around it, unless you want to run important applications on something that may suddenly put up a useless 'kernel panic' message and go on strike.

Also, the hierarchical file system, that requires links and aliases to abound everywhere, because a strict hierarchical file system cannot work.

Iconoclast
17th May 2004, 06:53 AM
Originally posted by evildave
I'm always doing something "radically different", and you ignored the point about wxWindows supporting other platforms besides Windows, something MFC was originally intended for, but "somehow" got lost over the years.OK, I forgot to address that point. I've only ever written code to target Windows, except for when I was a student and had to tangle with UNIX, HP-9000, and VAX-VMS, so I've never really given other platforms much thought. I'm just not particularly interested in other OSs, I should probably install a Linux onto my machine one day to see what all the fuss is about, but I write applications for a living so it makes sense (to me at least) to target the operating system that's most pervasive. While there may be OSs that are "better" than Windows -- and according to the posters on slashdot even a piece of chalk and a slate is better than Windows -- but I write software for the money, not to find the holy grail of shaving some number of bytes from some particular implementation of some particular algorithm.
Originally posted by evildave
A library on top of windows would be worth it for cross-platform compatibility.

MFC is not "worth it"... unless all you do is exactly what MFC generates its default little application frames for, and all the cookie cutter "make me a function" stuff fits perfectly with what you do most of the time. Not for me.There's a lot more to MFC -- as you're surely aware -- than some wizards. If I wish to build an MDI app with OLE support, I can either let MFC generate the framework code for me, or I can write it all myself. Now, Microsoft don't try to hide the fact that MFC is a tool to use if you're building Dialog based apps, SDI apps, or MDI apps, which are the same style of applications that Microsoft themselves build; MS Word, Excel, Visual Studio. If you wish to build something that looks nothing like any of these styles, you can do that too, but you need to write more of the code yourself. Use can use MFC to make an app "look" like anything you like, but you might have to implement your own drawing code to get the specific window look you're after.

Originally posted by evildave
Here is a little example of what's wrong in MFC. For every touch of the mouse (WM_MOUSEMOVE), every WM_TIMER, every PostMessage or SendMessage, the above linear search occurs. Not just for the top-level window, either. No, it has to percolate through class after class of linear searches. From the top-level application window to the To the what? To the what? Oh, well, I guess we'll never know. I thought that the idea of traversing the list of message entries for a command target to find a match, then finding the parent of the target and repeating the search until the message disappears into DefWindowProc would be pretty slow, but it's a simple pattern that anyone can understand and in practice it seems to work very well. Apps written under MFC are renowned for their "snappyness", so any slowness of this method is not really important, you can only click a button so many times in a second.

Note that there's plenty of apps out there with unresponsive interfaces, but that's not due to that routine, it comes from developers trying to do too much work (or using inefficient routines) in their message handlers instead of offloading the processing to a worker thread. Perhaps there's faster ways of routing messages, I dunno, don't really care either.

By the way, you omitted the first line of that function:

// Routines for fast search of message maps

Surely if it says it's fast, it must be fast, shouldn't it? If you had been in (say) Mike Blaszczak's position, how would you have written the routine.

Originally posted by evildave
Have a look at
BOOL CWnd::OnWndMsg(UINT message, WPARAM wParam, LPARAM lParam, LRESULT* pResult) to see what else happens in every window.Well, first it checks if the message is a WM_COMMAND, since they occure most frequently and have the most effect on the user experience, then it checks if it's a WM_NOTIFY for the same reason, then a littel later it dips into the Message Cache, so it can save a bit of time if the message was recently handled, then it works out the message handler's signature and calls the appropriate handler for the message, so some intelligent optimising was done by the developers. But again, the messaging system is fast enough that it doesn't get in the way or damage the user experience. If you think MFC messaging is slow, then you're in for a rude shock if and when you start building apps in .NET which is currently slow enough to be annoying even on a high end system. Their windows grid control is damn, damn, damn slow.

Originally posted by evildave
The third problem with MFC (besides being locked into flavors of Microsoft Windows ONLY, and this 'flexibility' that amounts to shoveling CPU cycles into the bit bucket), is that it generates code much larger than you should expect.Well, I have to disagree. One of the apps sitting on my machine is a medium size commercial 2D graphics application, it lets the user create symbol libraries from primitive objects, then you can use these library objects to draw schematics, then the app will analyse the schematic for such things as signal strength on any node in the system, channel to channel signal strength differential at each node, node to node signal strength differential for each channel, composite triple beat, lots of stuff. It has 176 source files (I just counted them), several dozen dialogs, and a few hundred classes, yet a release build dynamically linked to MFC yields an executable of just 561kB. I don't call that large at all. Sure it requires MFC42 which is 973kB and the common controls library at 544kB, but it's expected for any real life end user machine that those libraries will be loaded and running do to other applications anyway. Even if the user is running no other MFC apps, a 2Mb footprint can harldy be considered bloated.

Originally posted by evildave
As for wrapping API functions in classes, let's have a look at this, now. If you were to wrap, say a rendering Device Context in a class, would you simply grab every function in the Win32 API that takes an HDC and paste them into a class body, and then take the HDC parameters out of each and make it a member of a class and call it a brilliant achievement? Perhaps so. I wouldn't. You chose the largest class in MFC (at least I think it is) to pick on, but from an OO perspective it could be considered correct since it deals with just a single logical entity: the Device Context. On the one hand you're calling MFC "bloated", but on the other you're slagging off the fact that Microsoft applied the lightest possible wrapper around the API DC functionality. Just because a class' interface has many methods doesn't necessarily mean it has a bad design, some classes simply have a lot of functionality.
Originally posted by evildave
Perhaps this is because I would have a specific sort of rendering that I need to do, and will write functions that help to do it, rather than blindly echo the awful naming and calling conventions the Win32 SDK evolved with.What do you mean? Function names like "Rectangle", "MoveTo", "LineTo", "SetTextColor". When you say the calling conventions are awful, are you speaking generally, or is there only a handful of methods that make you hate this library with such passion?
Originally posted by evildave
Basically, MFC provides no real help over invoking things with the Win32 SDK, especially for someone who has to write graphical interfaces that are not based on grey boxes in grey boxes.Well the CAD app I alluded to before just handles it's drawing in the OnDraw method of the applicable View class, all my objects are responsible for rendering themselves, so the OnDraw routine just delegates the drawing to every object inside the clipping region, it works fine for me and pays my bills. I've never had a customer complain about the draw speed or responsivity, if it was too slow I would have changed the way I did it. However, this app is only for 2D, so if you're talking about 3D graphics, then sure, you'll hit the performance wall much sooner.
Originally posted by evildave
Now let's look at all of those 'common controls' that MFC helps you to use! This is the very best!

You see, if you look into it, those natively supported 'widgets' in Microsoft Windows require specific versions of Internet Explorer or (by extension) versiuons of Windows. If your user is running Win98 (and let's face it, if you're using MFC to develop your code, it probably bloated up so big by now it won't run on most '98 boxes anymore), and you just used the things .NET provided for you, guess what?What? Hang on, what's this talk of .NET, where'd that bastard come from?

Originally posted by evildave
You're going to have to require that this customer either upgrade Windows or install a new version of Internet Explorer.Again, I've never had a problem of bloated or slow running code with MFC, but I take care to keep my classes light and tight anyway. For every job there's a tool, and MFC is obviously only suited to a small subset of all programming tasks, but like any tool I use it when it makes the most sense to me. When I was working on N-Tier systems with COM+ in the business layer I used ATL, these days I write exclusively in .NET because that's the flavour of the month and a lot of customers ONLY want their apps built in .NET, even if they're not entirely sure what .NET actually is. But if a job to build a desktop windows app that doesn't talk to the web and doesn't require XML files comes across my desk, I'll probably build it with MFC.

Iconoclast
17th May 2004, 06:56 AM
Originally posted by Reb
This seemed strange to me (contrary to my experience) so I tried to test it using this script on my SQL2000 server:

create table MyDate (datecol datetime)
go
create table mydate (datecol datetime)

It wouldn't run the second statement, giving me a "already an object named mydate ..." message. Could you cite the source for this "case agnostic" term? I could not find the term in BOL.

Reb You're absolutely right Reb, and I'm completely wrong. I read this in (I thought) some SQL Server book quite a few years ago and it stuck in my mind because it all seemed so pointless. Of course I never bothered to test it out, so now I look like a complete doofus. Again.

Reb
17th May 2004, 07:03 AM
Originally posted by Iconoclast
You're absolutely right Reb, and I'm completely wrong. I read this in (I thought) some SQL Server book quite a few years ago and it stuck in my mind because it all seemed so pointless. Of course I never bothered to test it out, so now I look like a complete doofus. Again.

A Google search revealed a reference to that term ("case agnostic") in connection with PostGRE SQL. Maybe that's where you saw it ...

Reb

Iconoclast
17th May 2004, 07:06 AM
Originally posted by Wudang
And how often have I had this conversation
X: "I don't get you. I think COBOL is a great language"
Me: "How many have you worked with?"
X: "Just COBOL"Most of the account managers where I work at the moment were all COBOL guys in their youth and they say the same thing. They'll ask "why do you need this fancy object oriented rubbish and step-through debuggers, we didn't need any of that"? So you start to explain that OO lets you build really large and complex apps without the code getting tied up in knots, but then they'll point out that some of the very largest applications ever built were written in COBOL, so you find you've just talked yourself into a corner.

Iconoclast
17th May 2004, 07:08 AM
Originally posted by Reb
A Google search revealed a reference to that term ("case agnostic") in connection with PostGRE SQL. Maybe that's where you saw it ...

Reb I saw those entries, but I've never heard of PostGRE. It's weird, because I could never come up with a bizarre term like "case agnostic" on my own.

Gestahl
17th May 2004, 11:18 AM
OK, I will bite. I like Unix's case sensitivity. Why? Because Unix (nor does your computer ultimately) separate character data from binary data. 01100010 is different from 011000011, no matter if in one case it means "B", and in another "b". Case-insensitivity is built in, makes it great for internationalization and changing Unicode standards, because you don't have to recode *anything*. Unix puts *no* unnecessary limitations on filenames. In Unix, you get what you type, period.

Now for this hierarchical filesystem bit... dude, unless you already have WinFS or have worked on extremely large/prototype systems, you have been using a hierarchical filesystem everywhere. Everything else is a hack on top of it (WinFS is too, it just abstracts and contorts it). Having a hierarchical base filesystem is necessary to have mount points, which just makes sense to me (what else would you do, make them all one namespace? How do you handle collisions?).

The "dot-file" is just a shorthand for a way to hide files you normally do not need to access for visual clarity. They wanted to make the base file semantics as loose as possible for interpretation, so the "hidden" thing is implemented elsewhere. In order to truly hide the file, use permissions on directories.

Being case-insensitive requires more work, more overhead, for *no* benfit except for people who are used to MSFT's stupidity stemming from DOS, and simply cannot handle the concept.

Paul C. Anagnostopoulos
17th May 2004, 01:59 PM
Yeah, that's lovely Gestahl, but could you at least implement a case-insensitive file system option, so that web server drives can use it? Then I don't have to give a damn what the case of a URL is.

Really, who in their right mind wants a file foo.bar and another foo.Bar?

~~ Paul

a_unique_person
17th May 2004, 04:23 PM
Originally posted by Gestahl


Now for this hierarchical filesystem bit... dude, unless you already have WinFS or have worked on extremely large/prototype systems, you have been using a hierarchical filesystem everywhere. Everything else is a hack on top of it (WinFS is too, it just abstracts and contorts it). Having a hierarchical base filesystem is necessary to have mount points, which just makes sense to me (what else would you do, make them all one namespace? How do you handle collisions?).



MVS was fine for me. It was hamstrung by relics to maintain compatibility, but the whole idea of cd .. cd.. cd .. is a real time waster. In the famous '3.4' panel, you could type in any high level qualifier and wild cards, and bring up all the files that met those criteria. It was just a big flat space, but you didn't need too much imagination to see what a relation filing system could achieve.



The "dot-file" is just a shorthand for a way to hide files you normally do not need to access for visual clarity. They wanted to make the base file semantics as loose as possible for interpretation, so the "hidden" thing is implemented elsewhere. In order to truly hide the file, use permissions on directories.



Yep, I know what it is, but it is still a dumb idea. If you want to have, say, shell start up scripts, have it in a subdirectory. Any idiot can, and has, created a 'hidden' file.

evildave
17th May 2004, 05:39 PM
Surely if it says it's fast, it must be fast, shouldn't it? If you had been in (say) Mike Blaszczak's position, how would you have written the routine.

Presort at instantiation, or build time, binary search at runtime.

Leif Roar
17th May 2004, 10:39 PM
Originally posted by a_unique_person
Yep, I know what it is, but it is still a dumb idea. If you want to have, say, shell start up scripts, have it in a subdirectory. Any idiot can, and has, created a 'hidden' file.

Personally, I think it's a pretty useful convention - in general useage you're mostly interested in your data files, and not the plethora of configuration files, so why should the configuration files clutter your view of the filesystem?

The Unix filesystem / shell combination is hardly perfect, though. Have you ever tried removing a file named "-rf ~"?

Wudang
18th May 2004, 12:16 AM
Originally posted by Iconoclast
, but then they'll point out that some of the very largest applications ever built were written in COBOL, so you find you've just talked yourself into a corner.

Sure, but how large a team, how much time spent in debate and planning etc etc? How many "coding clerks"?

a_unique_person
18th May 2004, 12:35 AM
Originally posted by Leif Roar


Personally, I think it's a pretty useful convention - in general useage you're mostly interested in your data files, and not the plethora of configuration files, so why should the configuration files clutter your view of the filesystem?

The Unix filesystem / shell combination is hardly perfect, though. Have you ever tried removing a file named "-rf ~"?

What if an important part of your job involves working with these 'hidden' files? You can work around it, but the word 'bogus' sums them up perfectly.

MRC_Hans
18th May 2004, 01:34 AM
Originally posted by Paul C. Anagnostopoulos
What are the most horrifyingly bogus things in the world of computers?

My vote for #1 is the Unix case-sensitive file system. Never has something so patently worthless caused so much trouble. A couple days work to fix this would save countless hours of wasted time talking about the case of URLs.

A close second is the abomination known as Perl.

~~ Paul Coming originally from a pure UNIX environment, I'd say the problem is not with UNIX. Case sensitivity is simple consistency: 'A' is not and never will be equal to 'a'.

The problems started when MSDOS arrived and wasn't case sensitive :(.

In C, I have used case sensitivity for some good purposes, for example:

#define LEVEL=7
.
.
.

static int level=LEVEL;

....Thus, I would put the variable's names in lower case, and their default values would be the name of the variable in upper case. Easy to remember. Of course, if you do kosher structured programming, you will only ever initiate a variable in one place, but, "real programmers" etc...........

My suggestion for an infamity is long filenames that are not really that long: I'm not sure what the current state of things is (haven't done much programming or system work lately), but in most versions and dialects of Windows (and UNIX, too), you are allowed filenames of arbitrary length, but really only the first n characters are significant, thus:

Introductory letter to Joe.doc
and
Introductory letter to Jill.doc

will actually reference the same file for any value of n below 25.

Also, I nominate the . extensions in MS OS'es for filetype identification. This has caused endless problems and confusions.

And, I just HATE the suggest last entry function in e.g. MSIE; I mean, its cool that it suggests earlier entries as I type, but how do you delete them? Problem is that old, misspelled entries keep popping up.

Hans

MRC_Hans
18th May 2004, 01:49 AM
Originally posted by Leif Roar


*snip*

The Unix filesystem / shell combination is hardly perfect, though. Have you ever tried removing a file named "-rf ~"? Heheh, write

rm -va "-rf~" to be safe (at least for some dialects, heheh).

the a directive tells rm to ask for acknowledgement, thus, if the filename, in spite of the quotation marks, should fit other files than the one you want, you can tell it not to remove it, but in some dialects, this does not work unless you also include the v (verbose) directive (REALLY bogus :eek: ).

Non-UNIX people may wonder why you would create such a file in the first place, but a basic paradigm of UNIX is that the operator is assumed to do her own thinking and know what she is doing, so typing errors may well result in generating files with weird names.

Leif Roar
18th May 2004, 02:19 AM
Originally posted by a_unique_person


What if an important part of your job involves working with these 'hidden' files? You can work around it, but the word 'bogus' sums them up perfectly.

Then you just write "ls -a" instead of "ls". You don't really have to work around anything - the files are perfectly accessible and visible; they're just not shown by default. (And you can always set ls up to use the "-a" switch by default.)

Leif Roar
18th May 2004, 02:24 AM
Originally posted by MRC_Hans
My suggestion for an infamity is long filenames that are not really that long: I'm not sure what the current state of things is (haven't done much programming or system work lately), but in most versions and dialects of Windows (and UNIX, too), you are allowed filenames of arbitrary length, but really only the first n characters are significant, thus:[SNIP]

This reminds me of a fun fact with Fortran77 - you could have as long variable names as you wanted (well, up to about 128 or 256 characters), but only the first two were significant. So conditionalExit and countOfItems was the same variable.

Oh, and let's not forget Fortran's ability to redefine the value of "4".

a_unique_person
18th May 2004, 03:05 AM
Originally posted by Leif Roar


Then you just write "ls -a" instead of "ls". You don't really have to work around anything - the files are perfectly accessible and visible; they're just not shown by default. (And you can always set ls up to use the "-a" switch by default.)

But the whole idea is just bogus. I work on many servers, using ids that aren't my own, that I can't just arbitrarily fiddle with. The basic idea of a hidden file is bogus.

Leif Roar
18th May 2004, 03:19 AM
Originally posted by a_unique_person


But the whole idea is just bogus. I work on many servers, using ids that aren't my own, that I can't just arbitrarily fiddle with. The basic idea of a hidden file is bogus.

What's so bogus about it? I find it quite useful and convenient. (Besides, you can always just do an "alias ls='ls -a'" as the first command.)

richardm
18th May 2004, 05:37 AM
Re: long filenames that aren't really long. I came across an interesting thing with an AIX server a year or two ago. It would let you have passwords of arbitrary length, but would only actually check the first 5 or 6 (can't remember which). The server in question had its root password changed every now and then, but the sys admin person was keeping most of it the same and changing a 4 digit number at the end to make it different. As luck would have it, the bit that stayed the same was 5 (or 6) characters long.

I didn't know she'd changed it, and started to log in as root to mount a CD. She was just about to tell me I wouldn't be able to when the root shell appeared on my terminal screen.

Aghast, she let me mount my CD then changed the password again.

"Try now", she said, so I retyped my original password, regained access, and we both learned something new about AIX.

Paul C. Anagnostopoulos
18th May 2004, 06:00 AM
MRC said:
Coming originally from a pure UNIX environment, I'd say the problem is not with UNIX. Case sensitivity is simple consistency: 'A' is not and never will be equal to 'a'.
They are not equal from an encoding point of view, but they are equal from a semantic point of view. Do these two sentences have different meanings?

How are you doing?
how are You doing?

....Thus, I would put the variable's names in lower case, and their default values would be the name of the variable in upper case. Easy to remember. Of course, if you do kosher structured programming, you will only ever initiate a variable in one place, but, "real programmers" etc.
Yes, you shouldn't need LEVEL. However, if you do, is there a problem with level_default or some such? Too much typing?

If you won't change the Unix file system, then change web servers so they fold a URL before finding the file. Or at least adopt the convention that all filenames are in lowercase, even though they don't have to be. But do something, damn it!

~~ Paul

MRC_Hans
18th May 2004, 06:30 AM
Originally posted by Paul C. Anagnostopoulos
They are not equal from an encoding point of view, but they are equal from a semantic point of view. Do these two sentences have different meanings?

How are you doing?
how are You doing?

The the first one is correct, the second one is flawed. I would read #2 as an emphasis on "you". I notice, however, that you do use versals when you write (unlike some here ;)), so you do not seem to consider them redundant.

Yes, you shouldn't need LEVEL. However, if you do, is there a problem with level_default or some such? Too much typing?

How is level_default better than LEVEL?

If you won't change the Unix file system, then change web servers so they fold a URL before finding the file. Or at least adopt the convention that all filenames are in lowercase, even though they don't have to be. But do something, damn it!

Obviously, I cannot do much about it, and neither can anybody else. We are really looking at a darwinistic system, and apparantly, the selection pressure for this is not very high.

~~ Paul

Gestahl
18th May 2004, 11:24 AM
Originally posted by Paul C. Anagnostopoulos
Yeah, that's lovely Gestahl, but could you at least implement a case-insensitive file system option, so that web server drives can use it? Then I don't have to give a damn what the case of a URL is.

Really, who in their right mind wants a file foo.bar and another foo.Bar?

~~ Paul

You can. Its called naming everything lower case when you absolutely need to, and it is no extra work to do so, if you do it to begin with. If retroactive, I would suggest just using a different FS. I don't like FAT32, but if you really want it...


In fact, the really cool thing is, you can even have directories that are case-insensitive too!

Grep has a case-insensitive option.
Most do other programs that deal with text.

I don't see how case sensitivity complicates things, and it sure allows for more options.

Paul C. Anagnostopoulos
18th May 2004, 12:38 PM
MRC said:
The the first one is correct, the second one is flawed. I would read #2 as an emphasis on "you". I notice, however, that you do use versals when you write (unlike some here ), so you do not seem to consider them redundant.
If I want to emphasize you, I'll italicize it. Can I have italics in my file names? :D:

How is level_default better than LEVEL?
It's composed of different characters, so it doesn't differ only by case! And it's more meaningful, anyway.

If I want an identifier called JREF, I guess I'm forced to call it jref or Jref, to make sure no one thinks it's a macro. Oh wait, if it starts with an uppercase letter and contains at least one lowercase letter, then it's a class name. So it has to be jref. Case is a stupid way to convey meaning.

Obviously, I cannot do much about it, and neither can anybody else. We are really looking at a darwinistic system, and apparantly, the selection pressure for this is not very high.
You mean, as in, "I'm leaving the World Wide Web and finding a case-insensitive world-wide network!"?

Gestahl said:
I don't see how case sensitivity complicates things, and it sure allows for more options.
Yes, more options that no one should exercise. It makes for confusing naming conventions. See above.

Here's a fragment of code I just ran across:

class COREDLL BSDF {
public:
...

Oops!

~~ Paul

Gestahl
18th May 2004, 01:30 PM
Originally posted by Paul C. Anagnostopoulos
Yes, more options that no one should exercise. It makes for confusing naming conventions. See above.
[/B]

There are lots of things no one should exercise... like dereferencing a null pointer or using gets() or writing past the end of a static buffer. This does not mean the machine should prevent you from doing it (it can be useful to rewrite the stack, even null pointers if the signal is properly caught... think forcing the program to dump core easily. gets(), however, has no excuse).

Making un-intelligent use of the facilities available and not succeeding well is not the fault of the computer, nor should we make the base of computing of, for, and by the programmers and computer experts account for human mis-management of said tools. You can screw up in any language, in any environment. You can't idiot-proof computers.

Note I mean you no offense, nor mean that you are incompetent. Its just that most other people are. That's why we don't let them on Unix boxen.

Leif Roar
18th May 2004, 02:22 PM
Originally posted by Gestahl


There are lots of things no one should exercise... like dereferencing a null pointer or using gets() or writing past the end of a static buffer. This does not mean the machine should prevent you from doing it (it can be useful to rewrite the stack, even null pointers if the signal is properly caught... think forcing the program to dump core easily. gets(), however, has no excuse).

However, the machine should prevent you from doing it without explicitly removing safeguards. A good programming language should require that you disable the safety before you can shoot yourself in the foot.

While there's no such thing as a fool-proof programming language or system, there's certainly programming languages that are more safe than others (and safety doesn't necessarily come at the expense of power) and a programming language should certainly strive to be as safe as possible. We can't abolish traffic accidents, but that's no reason not to require cars to have seat-belts.

Paul C. Anagnostopoulos
19th May 2004, 06:05 AM
Sheesh-o-rama, Gestahl. :D I'm not making some giant philosophical argument about software protecting us from our mistakes. All I'm saying is the differentiating names, particularly file names, by case alone is semantically bogus and causes trouble for naive users. The Windows NTFS file system is case insensitive, works just fine, does not restrict my creativity, and eliminates the problem. In order to justify why Unix's file system should be case sensitive, you need to give a reason that is fundamentally useful, other than:

When Unix was invented, computers were slow and disks were small, so we didn't want to burden it with case folding.
followed by:

When the Web came along, we were so entrenched in case sensitive file systems that it didn't occur to us to add a switch to make it case insensitive.

No offense taken, of course.

~~ Paul

MRC_Hans
19th May 2004, 06:36 AM
Originally posted by Paul C. Anagnostopoulos

If I want to emphasize you, I'll italicize it. Can I have italics in my file names? :D:

No, and that is why I would expect you to use versals :D:D.


It's composed of different characters, so it doesn't differ only by case! And it's more meaningful, anyway.


If I want an identifier called JREF, I guess I'm forced to call it jref or Jref, to make sure no one thinks it's a macro. Oh wait, if it starts with an uppercase letter and contains at least one lowercase letter, then it's a class name. So it has to be jref. Case is a stupid way to convey meaning.

Well, you have made your case ;)

You mean, as in, "I'm leaving the World Wide Web and finding a case-insensitive world-wide network!"?

Something like that, yes. Actually, if somebody granted me three wishes for changing something on the WWW, resolving the case sensitivity problem would not be among them ;)


Yes, more options that no one should exercise. It makes for confusing naming conventions. See above.

Well, look at the bright side: If code was perfect, we wouldn't need programmers. (And the world would surely be better for that, still..........).

Here's a fragment of code I just ran across:

class COREDLL BSDF {
public:
...

Oops!

~~ Paul [/B]

;) Hans ;)

Beerina
19th May 2004, 12:34 PM
Originally posted by Uh_Clem
WWW

The only freakin' letter in the alphabet that has multiple syllablyes and some genius decided to use three of them when any old letter would have done. I wonder how much of my life has been wasted saying "okay, go to doubleyou doubleyou doubleyou dot...."

There used to be an Internet radio "station" called Pseudo.com. One of their shows was about the game "Quake", weekly on Thursdays. Their announcers used to say "dub dub dub" to shorten it.

Go ahead and use it wherever possible, in hopes it catches on.

Beerina
19th May 2004, 12:36 PM
Originally posted by roger

We'll go though this again with the 64 bit chips and operating systems. So long as you used the microsoft typedef, and not int, long, etc, you will be fine. If you used int, you have a lot of recoding to do.

Not necessarily. Who wants to bet there'll be a compiler switch, -64_bit_ints?

Beerina
19th May 2004, 12:41 PM
Originally posted by Leif Roar


I don't think that's unicode's fault though. The German double-s is a ligature rather than an actual letter in it's own right and, as far as I know, it's only ever used to replace the lower-case "ss" - upper-case "SS" are just written as "SS". (Since no words in German begins with ss you very rarely need upper-case "SS" anyway.)

Dutch is funky that way, too. Evidently a "y" is actually an "i" followed by a "j", an Eeee sort of sound, and that etymology lives on in current day. Others prolly know more, but I think dijk and dyk for dyke are the same thing. I never could figure out the exact rule on which were permissible when.

roger
19th May 2004, 12:49 PM
Originally posted by Beerina


Not necessarily. Who wants to bet there'll be a compiler switch, -64_bit_ints? I stand corrected. I quote from here (http://msdn.microsoft.com/visualc/using/building/64bit/default.aspx?pull=/library/en-us/dnnetserv/html/ws03-64-bitwindevover.asp): The 64-bit version of Windows uses the LLP64 data model. What this means is that the standard C types int and long remain 32-bit integers. The data type size_t is mapped to the processor's word size (32-bits for IA32 and 64-bits for IA64), and __int64 is a 64-bit integer. This was done to assist in porting 32-bit code. The significance is that you can have the same code base for both the 32-bit and 64-bit version of your application

Now, I'm a bit confused by this, because Microsoft, being Microsoft, do not consider the possibility of any other vendor existing. I assume what they meant to say is that their .NET compiler will implement int as 32 bits, but I am not familiar enough with the C and C++ standards to know if the LLP64 data model is specified in them. Off to do research....

(in any case, the article makes it clear why to use the fixed precision names like WORD, INT32, etc).

Paul C. Anagnostopoulos
19th May 2004, 05:15 PM
There is just something so wrong about the name __int64.

~~ Paul

rockoon
19th May 2004, 09:43 PM
Originally posted by roger
I stand corrected. I quote from here (http://msdn.microsoft.com/visualc/using/building/64bit/default.aspx?pull=/library/en-us/dnnetserv/html/ws03-64-bitwindevover.asp):

Now, I'm a bit confused by this, because Microsoft, being Microsoft, do not consider the possibility of any other vendor existing. I assume what they meant to say is that their .NET compiler will implement int as 32 bits, but I am not familiar enough with the C and C++ standards to know if the LLP64 data model is specified in them. Off to do research....

(in any case, the article makes it clear why to use the fixed precision names like WORD, INT32, etc).

From what I understand of the C definition, int is supposed to be the fastest non-floating point datatype on the architecture. On these new 64-bit designs, perhaps 32-bit integer operations is faster than 64-bit integer operations (certainly there would be less memory/cache bandwidth pressure)

evildave
20th May 2004, 12:01 PM
The int/unsigned int are the native register type, which tends to be the 'fastest', but on say 32 bit architecture with a 16 bit data bus, a short/unsigned short might be faster in several cases.

"Fastest" is subjective.

In any event, it's true. There is no standard to data types in C, except the kind you apply to them for yourself. That goes for big/little endian-ness and other things. The bit order in bitfields varies as well.

You have fairly direct access to the hardware, but it's at the cost of a few little inconveniences because in all the decades of CPU architecture existing, nobody can agree which way, how big or where.

What's more annoying is when different people extend the language incompatibly. How long could it possibly take to ask an ANSI committee, "What shall we call a 64 bit integer type on 32 bit architecture?"

Actually, the answer is "long", because that's what "long" was for. Of course, the problem comes in the flavor of supporting previous code versions and libraries that used "long" interchangeably with "int", especially in packed structures where fixed offsets were expected. So in GNU we have "long long" and variants of "%lld" in printf, and in MSVC we have "__int64" and "%I64d".

This is one of the big reasons most C/C++ code starts with a list of typedefs, but that doesn't go far enough.



/* The following tables define the supported scalar data types as well
* as the sorts of things you'd scrounge for in LIMITS.h in a consistent
* naming format.
*/
#ifdef __GNUC__
#define MSVC(x)
#define GCC(x) x
#define MSSTD(x,y) y
#define bits64 ll
#define int64const(v) ppConcat(v,ll)
#define uint64const(v) ppConcat(v,ull)
#define LLD(tchar) szconst(tchar,"lld")
#define LLU(tchar) szconst(tchar,"llu")
#define LLX(tchar) szconst(tchar,"llx")
#endif
#ifdef _MSC_VER /* Just assume it's MSVC - TODO: revisit */
#define MSVC(x) x
#define GCC(x)
#define MSSTD(x,y) x
#define bits64 i64
#define int64const(v) ppConcat(v,i64)
#define uint64const(v) ppConcat(v,i64)
#define LLD(tchar) szconst(tchar,"I64d")
#define LLU(tchar) szconst(tchar,"I64u")
#define LLX(tchar) szconst(tchar,"I64x")
#endif

#ifndef __cplusplus
typedef enum { false, true } bool; /**< Make bool real for C */
#endif
typedef signed char int8;
typedef unsigned char uint8;
typedef signed short int16;
typedef unsigned short uint16;
typedef signed long int32;
typedef unsigned long uint32;
typedef signed MSSTD(__int64,long long) int64;
typedef unsigned MSSTD(__int64,long long) uint64;
typedef float float32;
typedef double float64;



The above code is trivial, and very naiive. It supports Visual Studio versions after they added their __int64, and gcc/Linux versions after they added 'long long'.

In the unix world, they have to run a 'configure' script to generate a makefile to set up all the twiddly little things to build projects across platforms. There are a bunch of versions of gnu compiler to start with, and a bunch of versions of Unix/Linux, and a bunch of versions of GUI, different character coding, and a bunch of different hardware to run all of it on.

Isn't that all very complicated?

Yes, it is.

Developing in C is a bit of an art. It's not quite as specialised as developing in various flavors of assembly language, but you must be aware of the compromises you make to take advantage of certain features on different platforms. If having your code work on different platforms is what you wanted.

Leif Roar
20th May 2004, 01:43 PM
Originally posted by evildave

Developing in C is a bit of an art.

That's what they say about necromancy too. ;-q

rockoon
20th May 2004, 02:21 PM
Originally posted by evildave
The int/unsigned int are the native register type, which tends to be the 'fastest', but on say 32 bit architecture with a 16 bit data bus, a short/unsigned short might be faster in several cases.


I had read this and was convinced that you were right.. but then while reading another thread on politics the back of my assembler programming mind was thinking about it.

There is no single native register type on 80x86/Pentium line of processors. Byte registers, Word registers, DWord registers, and now presumably QWord registers on the new 64-bit chips. Not to mention the packed-QWord registers of the MMX extensions and the SSE extensions have packed 128 bit registers.

As far as the 32-bit chips go, a case can certainly be made that the 16-bit registers are the most versatile of the native registers. You can access both the high and low byte (of most registers) individualy with 8-bit machine language instructions while the 32-bit registers lack any instructions that access the high 16 bits seperately.

Under win32, the 16-bit register operations require a prefix to distinguish them from 32-bit register operations but this is defined by a processor flag that can be arbitrarily set. Usualy under 32-bit OS's its set to default to 32-bit operations with 16-bit operations requiring the prefix, while the opposite is usualy true under 16-bit OS's. This is not to be confused with 16-bit and 32-bit addressing which is an entirely seperate issue.

In either case, the 8-bit operations never require a prefix to distinguish them from 16-bit or 32-bit operations, but 8-bit operations can only access one byte of the low 16-bits of a 32-bit register.

So I believe on 80x86, the 16-bit registers are the most native because they allow full access to the registers by 8-bit instructions.

However, due to the requirement of a prefix byte under 32-bit OS's, that makes 16-bit operations slightly slower than 32-bit operations.

I just checked several ansi-c definitions and the only requirements they seem to place on INT's is that they be at least 16-bits wide.

-----

Horrifyingly bogus intel chips:

If you will note how increadibly insane the 80x86 CPU architecture has become as they piled on more and more stuff.. 8-bit, 16-bit, 32-bit, 64-bit, hell even 80-bit and 128-bit operations - most of them not being interchangable - so this could be a 'horrifyingly bogus thing' in the computer world. Is this also the fate of the C language as they also pile on more and more stuff, redefining the size of its data types and so forth?

This doesnt even touch on the descriptor/segment registers which have always been bogus.

Also, the sharing of registers between FPU and MMX (where the FPU 'registers' are on its own stack and MMX doesnt have anything to do with a stack.. and going from FPU to MMX mode completely trashed the "registers" aka "stack".. are they insane? who proposed that? who signed off on it?)

and so on and on..

a_unique_person
20th May 2004, 04:11 PM
The 8008/x86 architecture is testament to the difficulty of writing software.

Intel has actually tried to kill it off numerous times, and knows perfectly well it is bogus.

That was how the monstrosity of the x86 architecture was started. Intel had spent a fortune and many years (does this sound familiar), on the 432. This was to be a totally new architecture that would be engineered to work with modern, object oriented languages.

They realised, after pouring all that time and money into it, that it was never going to work. (Again, stop me if you have heard this story before).

Apparently, over a few beers and a weekend, the monstrosity of the 8086 was born. It may have been the ugliest CPU architecture invented, and it may have had better competition around, but it was compatible with 8080 code( at an assembly code level), and that was what mattered the most.

IBM was involved with the 80386 design, which was much cleaner and rational, but also allowed for the previous code to run directly. The curious things was the amount of time it took for the software to take advantage of the 32 bit architecture of the 386.

So, the moral of this story is that the existing programming languages are the major failure in the history of computer development.

evildave
20th May 2004, 07:44 PM
Actually, I was thinking more of 68000 or 80386SX, where the internal registers were 32 bit, but the external address buss was 16 bit. In the earlier 8088 architecture, the internal registers were 16 bit, while the data bus was 8 bits... if I remember correctly.

The 'native' word can mean a lot of things, but for the purposes of C, it generally means the largest register all of the common ALU operations work on.

In other words, what is the biggest register a shift-left or add operation can be accomplished in with one opcode?

Of course, this is also tempered by the OS as well. If the OS simply calls all 'int' types 32 bit, then it would be folly to write a compiler for the platform that had an 'int' that was 64 bits, even if the CPU supported it.

bignickel
21st May 2004, 03:23 PM
I know all you hardcore programmers have dominated this thread from post 1 with complaints about case and registers and umlauts and whatever....

BUT, as for us normal computer-using joes who happen to know a few things about computing...

I find the most bogus thing in computing these days is the half hour I spent last night removing all traces of vx2.betterinternet spyware from my system. Because from a USER standpoint, it is quite horrifying that we have evolved from downloading a sheet from the web into a web BROWSER, which simply DISPLAYS said sheet..,

to a point where the sheet arrives in browser, and the browser starts executing CODE in the sheet, which installs programs ON MY COMPUTER, making entries in the Registry, putting files in my Winnt folder, adding lines to a file that gets executed on startup (to reinstall the spyware if you managed to delete ALMOST all of it), ALL without my PERMISSION.

To someone who has been using computers for 20 years, who has seen us go from BBS to newsgroups to the web..,

THIS is just ghastly.

And I knew what was going on because I've had experience with this baloney. What about the vast unwashed masses who were told they'd be just fine as long as they avoided clicking on files emailed to them? All thanks to the stupid stupid decision of wedding a network browser to the OS.

Uncle Bill, you're a dumbass.

evildave
21st May 2004, 07:40 PM
You could always get a Lindows box that boots off CD to browse the web and collect your email.

rockoon
21st May 2004, 10:04 PM
Originally posted by bignickel


And I knew what was going on because I've had experience with this baloney. What about the vast unwashed masses who were told they'd be just fine as long as they avoided clicking on files emailed to them? All thanks to the stupid stupid decision of wedding a network browser to the OS.

Uncle Bill, you're a dumbass.

I use Internet Explorer.. have been running windows since 3.1.. and have never had a web page install anything on my computer without me giving the OK to do so (activeX controls) - perhaps the problem is that you are giving the OK for these things to be installed?

Certainly there are various VBScript programs being executed, as well as JavaScript and even Java (since I installed a Java VM) but in none of these cases can they install anything on their own.

And for sure there are various security risks involved with these scripting languages - no program is perfect - buffer overflows and so on can lead to memory being overwritten which might then be executed but those risks are inherent in pretty much all programs, not just scripting languages.

Zombified
21st May 2004, 10:13 PM
It isn't necessarily coming in through IE. A lot of spyware comes from seemingly innocuous software you download from the internet... some 'free' software comes with spyware, and if you actually bother to read the fine print in the license agreement, you may find that buried on page 12, paragraph something, you've actually agreed to installed the triple-damned things.

Yes, this is a horribly bogus thing. Way more bogus than any complaints about Unicode.

bignickel
22nd May 2004, 01:00 AM
Uh.... no.

I'm not installing any software. At all. These days you don't need to.

Just going thru the web, and no box is popping up asking if you want to install "weather-Clock" or "Happy Fun Box" for your web browsers. Just going thru the web, and bang: you've got this stuff installed.

Rockoon, if you'd like to have the pleasure, then by all means, type in "vx2.betterinternet" in google, and spend the next 10 minutes clicking thru every site you see.

Then do a search on any file on your computer with today's date on it. What's this?: new .zip & .exe files in your /winnt folder? How'd they get there. Better run Ad-Aware. Look at that: you've got a BOC pointing to a .dll with today's date on it! And new registry entries! And a .bat file that gets run on startup!

If you REALLY want to have some fun, check out a bunch of websites from goldencities.com, and experience the full pleasure of COOLWEBSEARCH
ie Hell on Earth.

http://www.spywareinfo.com/~merijn/cwschronicles.html#realyellowpage

Running little bits of code to make little .gifs of pikachu jump around a web page? Maybe. But that has lead to MS building a browser that executes all kinds of code. So it's a bit INEVITABLE that there's going to be a few holes. Which isn't much of a problem unless the friggin browser is wedded to the OS. Which, in Windows, it is.

I spent over 5 hours trying to get rid of the latest version of CWS, by the way. I certainly didn't sign up for that crap when I simply wanted to surf the web that day I got infected months ago.

a_unique_person
22nd May 2004, 02:21 AM
Originally posted by rockoon


I use Internet Explorer.. have been running windows since 3.1.. and have never had a web page install anything on my computer without me giving the OK to do so (activeX controls) - perhaps the problem is that you are giving the OK for these things to be installed?


I bet you don't have kids.

rockoon
22nd May 2004, 02:41 AM
Originally posted by bignickel
Uh.... no.

Rockoon, if you'd like to have the pleasure, then by all means, type in "vx2.betterinternet" in google, and spend the next 10 minutes clicking thru every site you see.

Then do a search on any file on your computer with today's date on it. What's this?: new .zip & .exe files in your /winnt folder? How'd they get there. Better run Ad-Aware. Look at that: you've got a BOC pointing to a .dll with today's date on it! And new registry entries! And a .bat file that gets run on startup!


Nothing was installed. Ad-Aware found some cookies. Cookies are harmless.

rockoon
22nd May 2004, 02:44 AM
Originally posted by a_unique_person


I bet you don't have kids.

I keep trying to land myself a lady but they are just too slickery for me.

:D

bignickel
22nd May 2004, 11:03 PM
Originally posted by rockoon

Nothing was installed. Ad-Aware found some cookies. Cookies are harmless.

No *****? Cookies harmless? Really?

Fine.

You can't get programs installed on your computer without clicking a box authorizing them. So please: proceed along without any spyware/adware blockers. Enjoy the web.

Didn't notice you mention anything about your travels thru the goldencities.com sites. But since you've got nothing to fear... why not have a spin thru?

BTW- if you find you home page changed everytime you reboot your computer, and ad-aware keeps removing it, and it keeps getting changed anyway... can you record your screams of anguish in a .wav file and send them to me? Thanks.

evildave
23rd May 2004, 01:38 AM
Actually, what makes horrifyingly bogus things for computers is that people expect them to be horrifying and bogus, just the way they're used to.

For instance, there once were a lot of word processors for the PC that had absolute garbage for user interfaces (I mean, cryptic multi-keystroke with control held and not held options just to SAVE AND QUIT), but people who bought the original versions and got used to the horror came to INSIST on the abominable behaviors they were used to.

It was difficult to learn, therefore it must be a valuable skill.

People are so used to being reamed by Microsoft, they feel like something's missing when their butts aren't freshly bleeding from another jolly good Microsoft rogering. "Oh, $800 for a Microsoft Office upgrade? Times a hundred seats? How could we lose? Those dancing paperclips are so cute, anyway! While we're at it, I suppose we'll have to buy $300 per seat worth of 'security' products to replace the ones that broke with the latest gigabyte of Windows patches, because Microsoft Windows is the VERY BEST!"

rockoon
23rd May 2004, 04:43 AM
Originally posted by bignickel

Didn't notice you mention anything about your travels thru the goldencities.com sites. But since you've got nothing to fear... why not have a spin thru?

BTW- if you find you home page changed everytime you reboot your computer, and ad-aware keeps removing it, and it keeps getting changed anyway... can you record your screams of anguish in a .wav file and send them to me? Thanks.

Went. Browsed around. Looks familiar. Been there before. Upon leaving the site, a VBScript popup asks if I want to set my homepage to that site. Of course, I declined. Perhaps you didn't.

AdAware reports 7 cookies. Nothing else.

Leif Roar
23rd May 2004, 07:29 AM
Originally posted by evildave
Actually, what makes horrifyingly bogus things for computers is that people expect them to be horrifying and bogus, just the way they're used to.

For instance, there once were a lot of word processors for the PC that had absolute garbage for user interfaces (I mean, cryptic multi-keystroke with control held and not held options just to SAVE AND QUIT), but people who bought the original versions and got used to the horror came to INSIST on the abominable behaviors they were used to.


Personally, my editor of choice is Emacs, which is probably the "King of multi-key control sequences," and while multi-key sequences take a little longer to learn they're really just as quick to execute as single-key sequences, and they have the advantage that you can bind so many more functions to the keyboard - which is a very good thing.

No, if you want to talk about something that's bogus - let's talk about the position of the scroll-lock key on most keyboards. Wasting primary all-but-home-row keyboard real-estate on a key that's really nothing but a hold-over from the typewriter days, that is nothing short of criminal.

evildave
23rd May 2004, 09:13 AM
Actually, emacs or vi are sensible tools when you consider the variety of platforms that they had to run on, compared to what WordPerfect and other DOS word processors from the 80's, that forced people to do crazy things with memorizing 'F' key sequences.

[Ctrl]+[F5], 3: 'Save As'
[F10] 'Save' (assuming you ever figured out above sequence)
[F7] To get out

My current favorite is http://www.openoffice.org
The price is right.

Paul C. Anagnostopoulos
23rd May 2004, 12:19 PM
I use Epsilon, a great editor in the fine tradition of Emacs. However, I unbind all the horrifyingly bogus default key bindings and bind the keys in a way I can remember them.

~~ Paul

ceptimus
23rd May 2004, 12:28 PM
Programming using only text is bogus. We only do it because of the limitations of previous and existing computers. We ought to be able to include diagrams in our programs, at the very least.

evildave
23rd May 2004, 12:52 PM
True. By now we should be able to organize the code more visually.

Of course, the same rule applies for programmers as users. It was hard to learn to do things with only text, and we're used to it.

Remember when editors didn't have syntax highlighting?

roger
23rd May 2004, 06:43 PM
Pleeeaasee.. no visual programming.

Maybe it's just because I am not very visually inclined, but I hate that stuff. It takes a lot longer to write, doesn't really help my comprehension, and you end up with people arguing endlessly about layout, what looks *pretty*, etc. In my last job we did a bunch of that, and hoo-boy, what a waste of time.

But perhaps you are talking about something different - we were using case tools.

Now, sometimes I *do* find pictures helpful - high level architectures with annotations explaining differrent scenerios, for example, are very helpful. I'll often make some of those up and include it with the project documentation. But here I am often taking the exact same diagram, copying it 2 or three times, and annotating it differently to document how different processes are carried out. Can't do that with any CASE tool I'm aware of, becuase you create one of each thing. You can't make "examples".

Now, I'd like to be corrected, or at least challenged, because visual code has a great intuitive appeal, but in practice it has always been a nightmare. I've seen it either completely drag a development project to a complete halt, or get abandanded or done substandardly just to get the code done .

I've always wanted to embed, or at least link documentation with my code, to avoid them getting out of sync with one another.

Zombified
23rd May 2004, 07:55 PM
Originally posted by Paul C. Anagnostopoulos
I use Epsilon, a great editor in the fine tradition of Emacs. However, I unbind all the horrifyingly bogus default key bindings and bind the keys in a way I can remember them.And herein lie my favorite editor bogosities: whenever I have to use a colleague's computer, then (a) they are using a different editor and (b) they have remapped all the keys to something else anyway.

evildave
23rd May 2004, 08:55 PM
Well, that's the problem: nobody's figured out how to do the visual stuff 'right', that I'm aware of.

Now 'doxygen', backed up with DOT is pretty sweet. Right price, too.

Decorate your comments slightly, and it'll annotate an HTML page with links to other pages, with little charts and everything.


/**
* \brief Function to squidificate things
* \param squid Instance pointer
* \param tentacle Tentacle list
* \param cTentacle Tentacle count
* \return Number of squidificated things
**/
int cSquid( Squid* squid, const Tentacle* tentacle, size_t cTentacle );


It even does some nice things for un-decorated code.

Paul C. Anagnostopoulos
24th May 2004, 05:49 AM
Zombified said:
And herein lie my favorite editor bogosities: whenever I have to use a colleague's computer, then (a) they are using a different editor and (b) they have remapped all the keys to something else anyway.
Then you'll just have to switch to my key bindings, because I ain't going back to the meaningless default key bindings. Some examples of mine:

Ctrl-K Ctrl-L kill line
Ctrl-C Ctrl-R copy region
Ctrl-F Ctrl-W forward word (also bound to Ctrl-W)
Ctrl-Y Ctrl-K yank kill buffer

Get the idea? Anyway, I very much doubt you'll ever borrow my editor. :D:

How about literate programming? Anyone ever written a literate program? It was invented by Knuth when he did TeX and related applications. I just finished typesetting a book generated from literate programming source files. The code and documentation are intertwingled; use one filter to get the code and another filter to get the book text.

~~ Paul

roger
24th May 2004, 06:55 AM
Originally posted by evildave
Well, that's the problem: nobody's figured out how to do the visual stuff 'right', that I'm aware of.

Now 'doxygen', backed up with DOT is pretty sweet. Right price, too.

Decorate your comments slightly, and it'll annotate an HTML page with links to other pages, with little charts and everything.


/**
* \brief Function to squidificate things
* \param squid Instance pointer
* \param tentacle Tentacle list
* \param cTentacle Tentacle count
* \return Number of squidificated things
**/
int cSquid( Squid* squid, const Tentacle* tentacle, size_t cTentacle );


It even does some nice things for un-decorated code.
No, nobody has figured out how to do it right (visual code), and I am not convinced that it is needed. After all, right now code is 2 dimensional, and the 2 dimensions pretty well annnotate control flow. The vertical direction indicates linear sequence, and horizontal indicates loops and conditionals (any nesting). I don't really need a little symbol to differentiate between, say while and if. Visual, to me, only makes sense when dealing with architectures, but since I tend to write a lot of little classes that can be plugged together to do different things (as opposed to big, ponderous OO hierarchies), that doesn't buy me a lot either.

Now, your code commenting to documentation is interesting. A guy I hired here a few years ago used something like that a lot (it was his own home-rolled version). I would use it, except I want more tool support. I hate having more comments than code, and I hate 'obvious' comments. For example:

// brief compute the sqrt of the value
// param value the value to compute the sqrt of
// returns the sqrt of value
double sqrt (double value)

That's about 3 comments too many, or at least 2 too many.

So, it's not that I want to do away with those comments, I just want my editor to hide and show that kind of information for me effortlessly. I like how the .net compiler will show me all of the parameters for a function when I hover over a function, or am typing out the parameters - it would be nice to be able to access all of that with a keystroke.

However, any tool like that depends on _all_ of the code base being developed using the same scheme, and in my experience, my projects never, ever, start from ground zero. I take some code from projects A, B, C, buy code to do D and E, hire somebody to do F-H, get somebody in another department to do I, and write J-M myself. No such thing as consistancy in the real world.

That's why I am dubious about these tool sets like CASE, etc. They handle brand new projects so-so at best, but good god do they blow as soon as you try to include pre-existing code, or work with contractors who don't have the tool set. emacs + gcc + unix tools, or .NET compiler with integrated IDE, gives a pretty powerful environment for developing code, IMO. There are things to regret, or wish for in that environment, but I honestly don't feel that I am especially limited using these tools, and I feel that I am freed from fighting my tools.

Anyway, guess I am probably drifting from the thread a bit, so yes, browsers or email clients that execute code is truly horrifying and bogus.

Paul C. Anagnostopoulos
24th May 2004, 08:35 AM
People spend too much time commenting their imperative code at the expense of commenting their data structures.

~~ Paul

Gestahl
24th May 2004, 09:52 AM
Originally posted by Paul C. Anagnostopoulos
People spend too much time commenting their imperative code at the expense of commenting their data structures.

~~ Paul

"Show my your data structures, and the rest of the program just falls out easily."

Beerina
24th May 2004, 11:08 AM
Originally posted by rockoon


I use Internet Explorer.. have been running windows since 3.1.. and have never had a web page install anything on my computer without me giving the OK to do so (activeX controls) - perhaps the problem is that you are giving the OK for these things to be installed?

Actually, there are a lot of things that will get installed just by surfing, no OK-ing anything required. This happens even if you keep up with the latest security patches.

I currently have something that is resetting the default browser path to be microsoft.com, that immediately redirects into msn.com. As far as I can tell, these are real Microsoft sites, and not malware look-alikes fishing for information. I set default to blank (only Microsoft would require "about:blank" as blank, rather than nothingness), but later on, possibly on shutdown or startup, it gets set to a new thing. The latest Ad-aware cannot find it, nor two other spy-catchers (which I've whittled down from 5 spy catchers, 3 of which installed their own spyware, ugh, that was fun to find, fox guarding the henhouse. Those guys should be in jail. Oh, I'm sure they buried it deep down in the middle of page after page of legal boilerplate. By the way, those 3 were cleaned off months ago. This is recent, within the last 2 weeks.)

Beerina
24th May 2004, 11:10 AM
Originally posted by Gestahl


"Show my your data structures, and the rest of the program just falls out easily."

I hope that's not a serious quote. That guy should be in the unemployment line next to the ivory-tower guy who claimed you should be able to judge how long to program something by studying the input and output transformations as functions.

Paul C. Anagnostopoulos
24th May 2004, 04:36 PM
Beerina said:
I hope that's not a serious quote. That guy should be in the unemployment line next to the ivory-tower guy who claimed you should be able to judge how long to program something by studying the input and output transformations as functions.
I think it's a somewhat accurate quote. I don't think the guy meant that the code writes itself easily, just that he can understand the imperative parts more easily.

~~ Paul

Leif Roar
25th May 2004, 04:02 AM
Originally posted by Paul C. Anagnostopoulos

I think it's a somewhat accurate quote. I don't think the guy meant that the code writes itself easily, just that he can understand the imperative parts more easily.

~~ Paul

I really think that depends heavily on the domain. The project I've been working on for the last year, for instance, is a middleware system which basically implements a protocol for sending payment messages between banks through a secure IP infrastructure. The data-structures are simple, almost trivial - but the behaviour is complex because of the demands of the protocol (which has to be able to integrate seamlessly with an old X25 based network), concurrency issues and demands on logging, robustness and throughput.

Wudang
25th May 2004, 04:51 AM
Originally posted by Paul C. Anagnostopoulos
People spend too much time commenting their imperative code at the expense of commenting their data structures.

~~ Paul

I am almost tempted to put that as my .sig. I am now going to eat a chocolate in your honour.

As an aside - MVS has hidden files as well - you just don't catalog them. And you could look on the IBM ICF as being sort fo hierarchical - UCATs linked to from the master catalog(s).

Paul C. Anagnostopoulos
25th May 2004, 08:05 AM
Leif said:
I really think that depends heavily on the domain. The project I've been working on for the last year, for instance, is a middleware system which basically implements a protocol for sending payment messages between banks through a secure IP infrastructure. The data-structures are simple, almost trivial - but the behaviour is complex because of the demands of the protocol (which has to be able to integrate seamlessly with an old X25 based network), concurrency issues and demands on logging, robustness and throughput.
But all the complex protocol state transitions are table driven, right? So it's just a matter of documenting the tables. :D

~~ Paul

Wudang
25th May 2004, 08:49 AM
Originally posted by Leif Roar


I really think that depends heavily on the domain. The project I've been working on for the last year, for instance, is a middleware system which basically implements a protocol for sending payment messages between banks through a secure IP infrastructure. The data-structures are simple, almost trivial - but the behaviour is complex because of the demands of the protocol (which has to be able to integrate seamlessly with an old X25 based network), concurrency issues and demands on logging, robustness and throughput.

MQSeries?
I am happy to say that X25 is now a dead issue for me.

Leif Roar
25th May 2004, 09:05 AM
Originally posted by Wudang


MQSeries?
I am happy to say that X25 is now a dead issue for me.

We do use MQSeries to communicate between the mainframe and the workstation with the middleware on for some customers, while we use CICS TCP/IP sockets for others. (Fortunately, we haven't had to deal with TCP/IP to and from IMS yet, and hopefully we never will.)

Leif Roar
25th May 2004, 09:12 AM
Originally posted by Paul C. Anagnostopoulos

But all the complex protocol state transitions are table driven, right? So it's just a matter of documenting the tables. :D

~~ Paul

No, unfortunately not. For reasons outside of our control, the middleware product has to be run on a workstation, separate from the main buisness databases and applications running on mainframes. For robustness and security reasons, we keep all data-storeage on the mainframe and don't store anything on the workstation. Since there's communication overhead and rather high throughput demands, we can't base our statemachines on database tables.

Wudang
26th May 2004, 03:04 AM
Originally posted by Leif Roar


We do use MQSeries to communicate between the mainframe and the workstation with the middleware on for some customers, while we use CICS TCP/IP sockets for others. (Fortunately, we haven't had to deal with TCP/IP to and from IMS yet, and hopefully we never will.)

We put everything through CICS and if the data is on one of our IMS systems (locked in a deep dungeon gibbering to itself) we have a CICS interface routine that the application code calls so it does not have to soil itself by contacting IMS directly. Since I'm the CICS troubleshooter this means i get dirty occasionally but also is one more thing keeping me in a job.

Paul C. Anagnostopoulos
26th May 2004, 03:43 AM
Leif said:
No, unfortunately not. For reasons outside of our control, the middleware product has to be run on a workstation, separate from the main buisness databases and applications running on mainframes. For robustness and security reasons, we keep all data-storeage on the mainframe and don't store anything on the workstation. Since there's communication overhead and rather high throughput demands, we can't base our statemachines on database tables.
I'm not sure I follow you. I'm not suggesting that the state transitions be stored in a database system. I'm only suggesting that they be encoded as data structures in the program, rather than as code. Then you can document those data structures and not worry so much about the code. Perhaps you thought that I was referring to database systems when I said that data structures should be documented?

~~ Paul

Leif Roar
26th May 2004, 03:47 AM
Originally posted by Paul C. Anagnostopoulos

I'm not sure I follow you. I'm not suggesting that the state transitions be stored in a database system. I'm only suggesting that they be encoded as data structures in the program, rather than as code.

It wouldn't really work. There's too many concurrency issues, cachings and various error-handlings going on.

Wudang
26th May 2004, 04:09 AM
Since you're using CICS on the mainframe already could use the CICS LU62 over TCP/IP protocol so you get all the goodness of LU62's 2-phase commit and let CICS Universal Client/Txn Gateway do the SNA Service Manager stuff?

Leif Roar
26th May 2004, 04:31 AM
Originally posted by Wudang
Since you're using CICS on the mainframe already could use the CICS LU62 over TCP/IP protocol so you get all the goodness of LU62's 2-phase commit and let CICS Universal Client/Txn Gateway do the SNA Service Manager stuff?

Perhaps we could have done somtehing like that, I wouldn't be able to say. I'm not really a CICS person myself; and we don't have anyone in the division who's ever used CICS outside of a mainframe environment. Anyway, we'd still have to support IMS banks, as well as interface to non-CICS systems, so there's limits to what benefits we would get from a true-blooded CICS system.

Rat
26th May 2004, 02:59 PM
All these people who tell me about adware and spyware; where does it come from? I know html, I can script in js and vbs (this is not meant to imply that I know all there is, though, of course, I do), and I know of no way to install anything without my permission over a net connection.

I have long, long arguments with my boss, who insists that cookies can install things on my machine, or change my browser settings. I ask him to tell me an example site, and he tells me, of course, that he can't, because he'd have to go to them first, which would bugger his machine.

So someone, please, tell me a url, to a website (not an executable, which I won't run) that will do something bad. Any site, anywhere, that will do something to my machine.

Cheers,
Rat.

rockoon
26th May 2004, 03:20 PM
Originally posted by ratcomp1974

I have long, long arguments with my boss, who insists that cookies can install things on my machine, or change my browser settings. I ask him to tell me an example site, and he tells me, of course, that he can't, because he'd have to go to them first, which would bugger his machine.


While exploits are certainly possible, it is unlikely that spyware would be developed to use these exploits since it is rather trivial to get the average computer user to willingly install the spyware.

The law of large numbers comes into play here.. why go through the effort of forcing your way onto someones machine when, as P. T. Barnum put it, theres a sucker born every minute?

Rat
26th May 2004, 03:49 PM
I agree with the gist of your post (Rockoon), but still, is there any way that, say, a cookie can harm my machine? I generally browse with Firefox, and I obviously have a firewall. Therefore no ActiveX controls. Is there any other way that someone can harm my machine?

Cheers,
Rat.

rockoon
26th May 2004, 05:46 PM
Originally posted by ratcomp1974
I agree with the gist of your post (Rockoon), but still, is there any way that, say, a cookie can harm my machine? I generally browse with Firefox, and I obviously have a firewall. Therefore no ActiveX controls. Is there any other way that someone can harm my machine?

Cheers,
Rat.

AFAIK, Not with a cookie. Unless you consider the disk space used as being harmful.

ActiveX controls and browser plugins can do literally anything on your machine. Decline all attempts by a web page to install one on your machine unless you are ABSOLUTELY SURE that its safe.

bignickel
26th May 2004, 10:46 PM
Ratcomp, no, cookies can't DO anything to your box.

However, you can get spy/adware installed on your box just by visiting a web site if you don't have the latest patches installed on your box.

CoolWebSearch is one of the worst: it hijacks your start page, and the latest versions are almost impossible to get rid of. It installs on target computers via a hook in the M$ virtual machine for Java. There is no "install Yes or No" box that appears. goldencities.com is one of the places it hangs out.

I would definitely recommend un-installing the M$ virtual machine and replacing it with the Sun java.

I'm not sure how vx2.betterinternet installs, since it too doesn't have a "install yes or no" box, but luckily it's just an ad displayer, and easier to get rid of (although it took me 30 minutes last time).

I'm considering switching to firefox to avoid this kind of crap.

bignickel
2nd June 2004, 04:14 PM
Folks, it's not goldencities that's the one to worry about (or if it is, I have no idea).

It's FORTUNECITY.COM that you must beware.

I was at work, studying my japanese, and trying to find the definition of satsu. So, I type this in yahoo, go to a page, which happens to be at fortunecity.com, and a box comes up asking me to install something.

I click no. And close down IE.

I don't trust it, so I do a search on files on my computer with a date of today. And guess what? Everytime I do a search, MORE new files show up! And then look: Bettingbuddy, Lycosearch, and whole bunch of garbage icons are on my desktop.

Ad-aware found over 200 malware objects to delete. I spent an hour trying to make sure this junk was dead.

Do what I'm doing now: put a crap IP address in hosts, and put fortunecity.com right next to it. DANGEROUS web sites.

evildave
2nd June 2004, 04:42 PM
127.0.0.1 is preferable to a 'crap' internet address. This is 'localhost', and (assuming you aren't running a web server) will immediately fail.

bignickel
2nd June 2004, 05:25 PM
There's a site that offers a host file that you can use to block alot of these sites.

http://www.mvps.org/winhelp2002/hosts.txt

It's got a LOT of ad/mal sites on there. My only question is how long it takes on windows startup to load this thing into memory.


Check out this article on 'drive-by-downloads'

http://whatis.techtarget.com/definition/0,,sid9_gci887624,00.html

bignickel
3rd June 2004, 10:03 AM
Correspondence between me and Rockoon leads me to believe that a big help to avoiding this stuff is a POP-UP blocker.

His box is unaffected by sites that load tons of junk on mine, and he has one running.

From what I've read so far, the favorite method of these ad/malware installers is thru popup ads. So do yourself a favor and get one if you haven't already.


"And hey... let's be careful out there."

Rat
3rd June 2004, 11:04 AM
I still don't see any that will harm my machine. Can anyone point me in the direction of one? I'll happily turn off the pop-up blockers for that site. Certainly I've come across sites that use annoying scripting to pop up pop-up window after window, launching a new one upon closing one, but that's easy enough to kill. I can't think of another way of this happening, short of someone turning their security settings way down low.

Cheers,
Rat.

bignickel
3rd June 2004, 11:20 AM
I've just emailed you a site, ratcomp

It's the one that hit me yesterday. All I did was type "satsu definition" into yahoo, because I was trying to find the definition of the japanese word satsu.

I spent an hour trying to clean up my box after that.

Again: I DONT recommend going to this site, or others like it. No known virus or worm, but lots of ad/malware. It usually travels in the popups.

Can it 'harm' your machine? Well, depends what you mean by 'harm'. If you define harm as "slowing down your internet connection, constantly having to kill popups that appear", then yes, it's harmful. Or "riddling your OS with badly written programs that destabilize it", yes. Or "messing up your OS so bad that you have to re-image it or build it back up from scratch", then DEFINITELY yes (this happened to someone I know. While at work).

Don't say I didn't warn you. Please don't do this with your main box.

I've assumed you've read the links to the articles I've posted in this thread. This stuff gets installed thru chinks in the M$ 'armor' (LOL). It's what inevitably happens when you give a page in a browser window the ability to run code when said browser is melded to the computer's OS.

Which to me is a horrifyingly bogus thing to do.

Rat
3rd June 2004, 12:10 PM
Well, I've given it a look. Thanks for the link. Nothing to report as of yet. No obvious new programs, no new processes, and my homepage remains the same. I allowed all requested popups, and read the source of both the original window and all the popups. I even clicked a few links within the popups to see about the pages they linked to. Still nothing obvious. The registry wasn't touched, and there's nothing new in my startup group.

I quite merrily did this on my main machine (indeed, currently my only home machine) because if there is a possibility of anything truly malicious, I want to know how to prevent it happening, and I can only do this by finding out how such things could happen.

The only thing occurs to me is that I haven't tried a restart yet, but as my homepage remains the same, no new registry entries were added, and nothing new should run on startup, I don't expect that to be a problem.

I assume everyone keeps up to date with Windows updates, and that everyone runs a decent firewall? As there appears to be no script that even attempts to load anything (that is, install anything or run an executable or malicious script), the only possibility I can think of is that the server logs the ip address and uses Windows security holes to install stuff. That does seem unlikely, though, and then it wouldn't make any difference what browser one uses. It also couldn't affect anyone behind a gateway, as most people at work are.

I guess I'll keep looking for these terrible things that lots of people keep telling me exist. People have been telling me so for the last five years, at least, and I've still not seen one.

Oh, and I assume that no one who's been affected has clicked 'yes' to any script prompt or ActiveX control?

Cheers,
Rat.

rockoon
3rd June 2004, 12:44 PM
My experience with those sites is like yours. Nothing. No script prompts. No ActiveX requests. Just two cookies. One for the site and one for gator. They appear to be affiliated.

Is it possible that the people affected have a wide-open hole in their system such as a completely unprotected intranet configuration? (read: Sharing C:\* with the Whole Wide World)

bignickel
3rd June 2004, 12:58 PM
Well, to share C you actually have to go about sharing the drive, which takes some doing. And a desire to do so.

One thing I've done is set "Net. reliant component" for "Run scripts not signed by Authenicode" to Disabled. Everything else is already Prompt. Except for Run Active X controls and plugins and Script Active X controls, which are set to Enabled.

As it stands, I'm glad that your box is OK. To not run this on a test box... well, I consider such action unwise.

(any work updates, btw, is handled automatically by SMS, run by the IT people; it's always updating our boxes 24/7)

As to your other question, read up a page or two. There's also a thread in this forum of LukeT's nearly identical problem of stuff getting installed.

I've just re-read your post, and I'm a bit puzzled: "allowed all popups"? Unless you're running some specific software, nothing should be prompting you to allow a popup to run. Either that: or your not running IE 5.5 or later.

Another thing: since this stuff travels in the popups: it could well be that you weren't given a popup that installed it. So, I can only suggest going back a few more times, and see what differant popups appear. I would suspect that sooner or later a window will come up asking if you want to install "CLOCKSYNC" or some other crap... (and clicking NO will not help)

Dang: I only keep a 1 day history, so I can't tell you the IP address of the popup that got me. It was www.fortunecity.com/something/something/something/horrible long string of letters.

Rat
3rd June 2004, 01:10 PM
I just mean that I disabled the pop-up blocker (the Google bar one, I don't normally use IE, but I have that in there anyway) for the duration of my exploration. Nothing attempted to launch or open that wasn't allowed to.

I certainly believe that it happens to people. I just want to know what they're doing differently. I have most security settings at normal levels. Unsigned ActiveX is disabled. Most other ActiveX is either enable or prompt. Apart from that, and third-party cookies being set to prompt, the settings are all normal.

I don't mind running this on my home box. I consider this machine a constant work-in-progress, as bits of it come and go all the time. Important data should be backed up, and if it isn't, it obviously isn't that important.

I see the popups are different every time, so I'll try a few more times and see what happens.

Cheers,
Rat.

bignickel
3rd June 2004, 01:11 PM
Ratcomp, check out this page which deals with horrible CWS hijacker:

http://www.spywareinfo.com/~merijn/cwschronicles.html

As you can see, most of the variants use security flaws in Java.

Rat
3rd June 2004, 01:26 PM
But these seem to use the MS Java VM. Which Microsoft hasn't distributed or supported in a very long time. Surely everyone uses the Sun machine?

Cheers,
Rat.

bignickel
3rd June 2004, 01:45 PM
Originally posted by ratcomp1974
But these seem to use the MS Java VM. Which Microsoft hasn't distributed or supported in a very long time. Surely everyone uses the Sun machine?


Unfortunately, due to the lack of social cues in the impersonal context of internet communication, I couldn't tell if you were being sarcastic there.

:)

Rat
3rd June 2004, 01:50 PM
Well, I'm usually being sarcastic without even realizing it. What I mean is that people should be running the Sun VM rather than the MS VM. XP SP1a should remove the MS VM altogether, though if you have SP1, you'll never be prompted to install 1a, as that's the only difference.

Cheers,
Rat.

bignickel
3rd June 2004, 02:28 PM
Ah. But how many people in homes and countries all over the world have gone to Windows XP and beyond? ;)

evildave
3rd June 2004, 05:34 PM
As I (and others) keep saying: Switch to Mozilla (http://www.mozilla.org/) or Opera (http://www.opera.com/) for your browsing, and virtually all of this Internet Explorer security hole crap just 'goes away'. Use the Mozilla mail client, and your Outlook based woes are gone, as well.

I have the Sun VM installed, mainly because of http://OpenOffice.org, whose scripting uses it.

One incredibly annoying thing that I get repeated to me a lot: "Can you get me Microsoft Office?" I ask them for $500, and they say, "NO! For free!" I tell them I can install OpenOffice, it's the same thing, except it's LEGAL to copy it and install it for free. Invariably, it comes back to "Well, I want 'Office'." Usually because they use it at work.

"Well, too bad your boss thinks it's 'smart' to pay $500~$1,000 a seat, and upgrade every couple of years for bugs and security exploits, for something he can have absolutely for free and update whenever he likes." Then the point comes about "Microsoft Support". Has anyone ever actually tried to use that? Do they get 100 computers' worth of support for the 100 licenses that cost $50,000~$100,000 to buy and upgrade? What do they really need that support for? Microsoft BUGS. Microsoft INSTALL problems. Microsoft licensing authorization problems. Microsoft security holes. That's what you need their 'support' for. When you use up your allotment of 'support', how much does that cost, then? And how much easier is it to just find out for yourself than to 'bother' that guy in Pakistan with the script it will cost you $1.90 a minute to wade through for half the day? You could always buy an unlimited Sun support license for StarOffice (the same thing, but branded) for next to nothing, and have lots of hand-holding and cuddling (and some extra clipart and goodies), if you need that sort of thing.

Got a newbie or setup problem with OpenOffice? Post to their forum, and typically several people will pounce on the problem. Not that I ever have any problems.

TwoShanks
4th June 2004, 04:30 AM
Originally posted by Beerina

I set default to blank (only Microsoft would require "about:blank" as blank, rather than nothingness), but later on, possibly on shutdown or startup, it gets set to a new thing.

Have you tried Spybot S&D? I've had similar things happen in the past, Spybot advanced features might help with this.

Rob Lister
4th June 2004, 05:23 AM
Problems with spyware have haunted me constantly. Especially since I installed XP. I finally solved the majority of the problems by making my account the only account that could download and install programs. Both of my kid's computers are absolutly infested with the junk. I've taken to refusing to help them anymore. I tell them to fix it on their own, live with it, or wipe the drive and start over.

You buy them books, you send them to school, and what do they do? They eat the chalk.

gnome
5th June 2004, 06:13 AM
Originally posted by evildave
As I (and others) keep saying: Switch to Mozilla (http://www.mozilla.org/) or Opera (http://www.opera.com/) for your browsing, and virtually all of this Internet Explorer security hole crap just 'goes away'. Use the Mozilla mail client, and your Outlook based woes are gone, as well.

I have the Sun VM installed, mainly because of http://OpenOffice.org, whose scripting uses it.

One incredibly annoying thing that I get repeated to me a lot: "Can you get me Microsoft Office?" I ask them for $500, and they say, "NO! For free!" I tell them I can install OpenOffice, it's the same thing, except it's LEGAL to copy it and install it for free. Invariably, it comes back to "Well, I want 'Office'." Usually because they use it at work.

"Well, too bad your boss thinks it's 'smart' to pay $500~$1,000 a seat, and upgrade every couple of years for bugs and security exploits, for something he can have absolutely for free and update whenever he likes." Then the point comes about "Microsoft Support". Has anyone ever actually tried to use that? Do they get 100 computers' worth of support for the 100 licenses that cost $50,000~$100,000 to buy and upgrade? What do they really need that support for? Microsoft BUGS. Microsoft INSTALL problems. Microsoft licensing authorization problems. Microsoft security holes. That's what you need their 'support' for. When you use up your allotment of 'support', how much does that cost, then? And how much easier is it to just find out for yourself than to 'bother' that guy in Pakistan with the script it will cost you $1.90 a minute to wade through for half the day? You could always buy an unlimited Sun support license for StarOffice (the same thing, but branded) for next to nothing, and have lots of hand-holding and cuddling (and some extra clipart and goodies), if you need that sort of thing.

Got a newbie or setup problem with OpenOffice? Post to their forum, and typically several people will pounce on the problem. Not that I ever have any problems.

I tried OpenOffice for a bit--it is an excellent substitute for some purposes. I missed MS Access though, and noticed that some graphs did not convert from MS Excel properly. Not a big deal if you're working only with documents you create yourself. Word documents translated very well.

evildave
5th June 2004, 11:56 AM
People tend to steer you towards MySQL for database stuff, OpenOffice will talk to that, and MySQL can import MS Access as well.

I usually have the "bad font" problem with conversions, myself. Someone types up a long document, and they just space pages out with 'enter' or similar things, and then the font I have on my computer doesn't *quite* match up with what they had on theirs, so the document sort of comes unglued. This would happen with two seperate M$ Word installations, with different fonts, as well. I've also found if two or more people work on an office document, they tend to format things differently, and the document comes out as a hodge-podge.

Anything I type up seems to be perfectly 'fine' for them. Especially since 1.1.0, where they added the Acrobat export.

gnome
5th June 2004, 04:30 PM
Originally posted by evildave
People tend to steer you towards MySQL for database stuff, OpenOffice will talk to that, and MySQL can import MS Access as well.

MySQL is something I'm likely to get into soon. But though I can probably struggle through SQL queries with some practice, I wonder if anything will quite replace for me the QBE view of MS Access--the easy but powerful functionality of the design not only caused me to get into MS Access as a database program, but was what led me to finally take the plunge and move to Windows from DOS.

evildave
5th June 2004, 08:57 PM
I moved to Windows 95 development because of the increasing demand for high resolution video, and the ever-increasing babel of audio, video and controller drivers that was developing at the time in the game industry. Ever more computers were beginning to be sold with PCI audio solutions and bizarre video conventions with no VESA support. Miles audio didn't keep up. Nothing kept up. Microsoft was driving the horror marketing their "Do what you want, just make a M$ driver!" hype. DirectX was somewhat of a ray of hope.

a_unique_person
8th June 2004, 04:25 PM
Originally posted by gnome


MySQL is something I'm likely to get into soon. But though I can probably struggle through SQL queries with some practice, I wonder if anything will quite replace for me the QBE view of MS Access--the easy but powerful functionality of the design not only caused me to get into MS Access as a database program, but was what led me to finally take the plunge and move to Windows from DOS.

Forget MySQL, it is a hack. (Look at the reliability of this BB, for example).

MySQL, did, however, get the rights, to MaxDB, which really is an industrial strength relational DB. It was formerly SAPDB, and before that a mainframe database, whose name escapes me. But it has many years of solid, mainframe and commercial proving and development behind it.

a_unique_person
8th June 2004, 04:27 PM
This is an obvious one, the slash goes like this '/' in Unix but like this '\' in Windows. (or is it the other way around, no, I think I got it right.)

evildave
8th June 2004, 06:14 PM
Even worse, the '\' in linux is an escape sequence, so you can type things into the command line without the OS mistaking them for pieces of the path. Windows STILL doesn't parse any kind of escape characters right, so 'sed' is very difficult to use in Windows.

SOME Windows tools take either '/' or '\' as a path argument. It's up the the application to make sense of the command line instead of the OS parsing it out uniformly. So sometimes you can type "ls /config/blah" and see a listing, but "dir /config/blah" is an error BECAUSE '/' is used for switches in DOS tools.

dir /b \blah
ls /blah

Nasarius
8th June 2004, 09:53 PM
Originally posted by a_unique_person
Forget MySQL, it is a hack. (Look at the reliability of this BB, for example).

I wouldn't call it a "hack", but sure, it's not for big, mission-critical applications.
For more serious stuff, use PostgreSQL (http://www.postgresql.org/).

Nasarius
8th June 2004, 10:11 PM
Slightly off-topic, but I just saw another Microsoft anti-Linux ad.

I'm sure I'm not the only one who finds it amusing and somewhat gratifying that Microsoft is spending money (http://www.microsoft.com/mscorp/facts/default.asp) in a lame attempt to discredit one specific OS, when they wouldn't have said a word about Linux a year ago. If anything, MS's campaign seems to acknowledge Linux as a serious competitor. Very interesting :)

a_unique_person
9th June 2004, 05:51 AM
Originally posted by Nasarius


I wouldn't call it a "hack", but sure, it's not for big, mission-critical applications.
For more serious stuff, use PostgreSQL (http://www.postgresql.org/).

MaxDB, formerly SAPDB, formerly ADABAS. Not well known, but for my money, the best of the free databases.

jema
12th June 2004, 03:42 AM
Well what I find bogus, is the fact that raw PC speed has increased a 100 fold in time honoured fashion, but due to increasing bloat and inefficient programming perceived speed has done nothing like the same.

It harks back to the discussions in this thread on MFC. I do not think MFC is especially bad, but I have been doing some benchmarking with some interesting results:

MFC/stl benchmarks (http://www.marsjupiter.com/mambo/content/Resources/C-%99-C%2B%2B-Code-Optimisation/Benchmarking-the-standard-template-library-STL/)


The main problem i think with MFC is really not MFC at all, but the C++ class system, whilst I don't really think we should all be programming in carefully crafted assembler, I just do not like the way we get away from having the faintest idea as to what is happening under the bonnet :(

jema

evildave
12th June 2004, 12:12 PM
Another little peeve:

Many corporations have discovered that selling software (and hardware) with fundamental flaws is good for business.

As a crude and unrealistic, but demonstrative example, you can sell a watch with no hour hand, and sell the hour hand as an accessory.

After all, you can provide quality "customer support" that runs out long before the most insidious problems happen, and can charge a dollar a minute to "help" people with what you did to them. While the support lasts, you can have prompt and courteous operators who speak with your native accent almost instantly solve problems because they know exactly what's wrong. When it runs out, you can pay a dollar a minute to have people with heavy, difficult to understand accents insist on following a script that starts with "Toorn own yoouour compooter... It's own? Trn ith owrff. Haz ith frrrnished brrrting yeeat? Lez weet rntl t doos..... Ohtay, stip tuhwoo orf 6,421...." (six days later) "Sschtip 6,421: Upgreeade Windozs to leetast Vrrshun!"

Then there are the 'complimentary' products you can ship to 'solve' problems. Complimentaty not in that they're 'free'. They just compliment the ruined garbage you shipped to them.

DrMatt
28th June 2004, 10:44 AM
Just one thing.

TYPE URL's? With your fingers? One character at a time?

Click on 'em, copy/paste 'em, write PHP that redirects 'em on the fly, okay. But TYPE 'em?

Huh?

bignickel
1st July 2004, 09:53 AM
http://story.news.yahoo.com/news?tmpl=story&ncid=1212&e=10&u=/afp/20040630/tc_afp/us_internet_virus&sid=96001018

"NEW YORK (AFP) - Hackers have found a way to intercept passwords for banking websites by infecting pop-up ads with a program that can install itself on computers and record user keystrokes, security experts said. "

The badness continues... KEYSTROKE CAPTURE programs installed without your permission, via IE.

That can't be good.

I just downloaded Firefox last night. Install this weekend.

RayG
1st July 2004, 10:24 AM
'Free' software that ain't free.

Ok, I admit it's not horrifying, but it IS annoying.

AOL recently tried to offer me some 'free' family history software, that, after the trial period, would cost me $99 per year. Nothing free about that.

RayG

LW
1st July 2004, 12:23 PM
Why hasn't anyone invented yet the single "do what I want you to do and nothing more" button that does all what you want to do and nothing more.

Or a system that would read my thoughs and subtly hint me that I might not want to overwrite my last four hours work by leaving out the filename while tarring the directory with the main latex file as the first argument.

Not that I did anything that stupid half an hour ago, no sire. I wouldn't do that, now would I?

Vitnir
2nd July 2004, 02:35 AM
Originally posted by bignickel
http://story.news.yahoo.com/news?tmpl=story&ncid=1212&e=10&u=/afp/20040630/tc_afp/us_internet_virus&sid=96001018

"NEW YORK (AFP) - Hackers have found a way to intercept passwords for banking websites by infecting pop-up ads with a program that can install itself on computers and record user keystrokes, security experts said. "

The badness continues... KEYSTROKE CAPTURE programs installed without your permission, via IE.

That can't be good.

I just downloaded Firefox last night. Install this weekend.
For some reason I don't seem to stumble on to sites that infect me with this crap. The adware I have got I got it knowingly by installing gnutella or a wheather service.

Rat
2nd July 2004, 03:41 AM
Originally posted by Vitnir
For some reason I don't seem to stumble on to sites that infect me with this crap. The adware I have got I got it knowingly by installing gnutella or a wheather service.
You're not alone. See the previous page. I have been unable to deliberately find sites that do this, let alone stumble upon them.

I suppose I shouldn't expect people to keep their machines up to date and secure. But I'm not sure why not. I certainly know that you're expected to keep your car and your driving skills up to a standard that isn't a danger to you or others. OK, cars kill people, computer crap just annoys people. But still, one can't really complain if one's own wilful lack of awareness of security issues leaves one open to security problems. The number of people I hear happily and proudly tell me how they know nothing about computers drives me up the wall.

Cheers,
Rat.

Vitnir
2nd July 2004, 04:18 AM
I consider myself to be on a pretty advanced level of computer security awareness although certainly not on the proffessional level. On the computers I have personally there has never been any virus infection. Partly because I don't have many friends that sent me virus through email I guess. I do know that there is a lot of people out there that doesn't have this security awareness and if a popup windows says "Do you want to ..." they just click OK to get rid of the popup to get on with the surfing. And voila a month later comes a bill for hundreds of dollars because they permitted their modem to connect to a satelite phone to an island in the pacific.
It's been awhile now but when I surfed warez sites and the like there could be an popup asking to install Gator. I also checked out a known site a few years ago that hijack modems, it was quite insidious how they printed the cost in light grey letter on white background to make it legal.