And also wroteActually you are correct (here I get myself crucified) but hear me out. I spent years of work on NT internal APIs (The the IBM OS2 APIs that share the same design) and the design itself is *very* impressive. Even with the 2.6 NPTL (The Native Posix Thread Library, already out with the RedHat 9), the Windows NT/2K/XP/2K3 has better security and scheduling (Though performance is impressive)
In short, the Win32API is impressive... but the OSs that use it areOK, I think it's time to bring on some Windows education into this list.
*not*. (Again being polite and all)
I believe the beutiful API you are talking about is NOT the WIN32 API. Saying about the Win32 API "Beutiful" is a gross crime against progrematic esthetics. I believe you were talking about the native NT API, which is something completely, and I do mean completely, different.
I also disagree about the security model being superior. It is more granular, I'll grant you that. This extra control the admin has over the system, however, usually results in total inability by the admin to make sure that all files on the system have the permissions they need, and no more. The system is impossible to audit, and contains too much neuances (deny before accept, containers before/after elements) for it to be practical to secure.
For those reasons I am, personally, against adding ACL support to Linux. Shame on me, for I am opposing B based on my experience with A, while I have not looked at B. That's why I'm mostly silent about this.
*However*, the implementation is lacking (and I'm being polite here) atYes, but an implementation can be fixed over time. Interfaces are forever.
best. The software is bloated, buggy, unstable and, well, bloated again.
Let's have a quick look at the sources of each API.
Win32 -
This is an API I can say I'm very familiar with. This is what Wine is aiming at reimplementing, as this is what almost all apps use. It leans back on Windows 3.0 days (the basic constructs are older). That API was later renamed "Win16", of course. The API is rather poorly designed. That statement is plain false, of course. The API was extremely well patched together over the years.
We call it an API, but in fact, it is no such thing. For something to be called an "Interface", it has to be well defined. Win32 has new additions and changes of behaviours every time a new version, and occasionally a SP, is released. Some random examples, based on pitfalls I have stumbled into over the years: DuplicateHandle will duplicate a registry handle on NT, but will not on Windows 98. Windows 2000 supports all Unicode functions. Windows 95 supports almost none. Windows 98 supports some, will link with others (which will then proceed to fail at runtime), and doesn't export others. The libraries you link with in order to get certain functionality don't carry as much internal logic as one would expect. If you want a program to be security aware on NT, but work on Windows 95, you have to runtime dynamic link the Registry functions, because they reside in the same DLL (advapi.dll) as the ACL management functions. "GetCharacterPlacement" is touted (to this very day) as the way a program can cache the language metrics, and then call ExtTextOut in a fastpath way. However, ExtTextOut can be told that the string should be interpreted as a Hebrew paragraph string. GetCharacterPlacement cannot. The list goes on and on and on and on.
Add to that the fact that documentation is poor. When DuplicateHandle consistantly failed to work in my program, I contacted MS support. They pointed me at msdn online where it clearly said the function doesn't work on 9x. My MSDN, dated three months before that, neglected to mention the fact. Each and every Win32 program must handle, as a bare minimum, at lesat these three window message to function properly. WM_PAINT, WM_DESTROY (or any other mechanism to make sure the program exits after all it's windows are closed), and WM_ENDSESSION to make sure the program exists when you shut down your computer or try to log off. That last message is not mentioned in any of the basic docs, or implemented in any of the training programs for Win32 programming. I had to fly to Japan for an urgent debugging session in order to find out that on logoff, neither WM_CLOSE nor any other message is sent to my window. Next time the system tells you "Windows is waiting for XXX to shut down", know who to blame.
In short - the Win32 is not a beutifully engineered API. It does not look like it was engineered at all, in fact. It is a change on change heap of patches, resulting in a huge and cubersome API. The incompatibilities I mentioned seem to suprise the MS programmers just as they suprise you.
NT API -
Not intimately familiar with that one. What I tell you should be treated as accepted truths, rather than a personal account.
NT API is what Windows NT is really running. This is the OS. Anything else (including Win32) is a compatibility layer. The origins of this API are another system altogether. If my memory serves me right, that was VAX. At some point MS loaned some designs. The undeniable truths are that the APIs were, at least for NT 3.11, very similar, that many of the VAX developers moved to Redmond, and that some of the error messages had the same spelling mistakes. Of course, Microsoft being the intellectual property purist it is, these can be easilly explained without once hinting that MS stole code from Digital.
I have heard from people that, over the years, the bloat problem found it's way into that API as well. The original was a spry thing. I cannot state how it is today, as I don't know it myself.
Several years ago, at the urging of a friend, I tried installing NT 3.51 on the oldest computer I had around (P166). Installation took 20 minutes, including the time it took me to find drivers for all of my hardware. Much though I hate the Windows 3.1 UI, I was willing to swallow that for a computer that boots in less than 20 seconds, and works so fast it's amazing. Sadly, non of the modern development tools I needed for my job would work on it.
Shachar
-- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
