W
White Spirit
Guest
There are profound technical reasons why Windows is crap. This is just
one of them:
Let's look at the WinMain function called by every Windows program. It
has the following prototype:
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpCmdLine, int nCmdShow);
hPrevInstance is a legacy from 16-bit days. If there was an existing
instance of the program running, the new instance needed to know about
it because programs running under 16-bit Windows shared the same address
space. Consequently, the programmer had to take measures to ensure that
the two instances didn't conflict. Most programmers simply limited the
application to one instance.
Microsoft fixed this with Windows 95 - at which time it was over
twenty-five years behind Unix in this regard(*)! Windows NT was also
over twenty-five years behind Unix by being multiuser for the first time
and finally allowing multiple permissions for the file system. Of
course, the filesystem still became severely fragmented after a short
amount of normal use - something that still happens with Windows XP,
over thirty years behind Unix filesystems.
* Perhaps claiming twenty-five years is unfair given that x86
architecture was originally unable to offer multitasking, which was only
truly available with 32-bit x86. The i368 was first released in 1985,
so it's certainly fair to say that Windows 95 was ten years behind the
techonology. At least it didn't take MS that long to release 64-bit
versions of Windows. It's a shame that they're buggy, slow, have poor
driver support and come at an exorbitant price.
one of them:
Let's look at the WinMain function called by every Windows program. It
has the following prototype:
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpCmdLine, int nCmdShow);
hPrevInstance is a legacy from 16-bit days. If there was an existing
instance of the program running, the new instance needed to know about
it because programs running under 16-bit Windows shared the same address
space. Consequently, the programmer had to take measures to ensure that
the two instances didn't conflict. Most programmers simply limited the
application to one instance.
Microsoft fixed this with Windows 95 - at which time it was over
twenty-five years behind Unix in this regard(*)! Windows NT was also
over twenty-five years behind Unix by being multiuser for the first time
and finally allowing multiple permissions for the file system. Of
course, the filesystem still became severely fragmented after a short
amount of normal use - something that still happens with Windows XP,
over thirty years behind Unix filesystems.
* Perhaps claiming twenty-five years is unfair given that x86
architecture was originally unable to offer multitasking, which was only
truly available with 32-bit x86. The i368 was first released in 1985,
so it's certainly fair to say that Windows 95 was ten years behind the
techonology. At least it didn't take MS that long to release 64-bit
versions of Windows. It's a shame that they're buggy, slow, have poor
driver support and come at an exorbitant price.