On Tue, 2003-06-03 at 07:28, Shachar Shemesh wrote: > Gilboa Davara wrote: > > >Actually 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) > > > And also wrote > > >In short, the Win32API is impressive... but the OSs that use it are > >*not*. (Again being polite and all) > > > > > OK, I think it's time to bring on some Windows education into this list. > > 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.
I disagree... ACL support is one of the most missed features in Linux. But we digress. > > >*However*, the implementation is lacking (and I'm being polite here) at > >best. The software is bloated, buggy, unstable and, well, bloated again. > > > > > Yes, but an implementation can be fixed over time. Interfaces are forever. > > 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. Actually, Win16API share little root with the Win32 API. Most of the Thread/Process/Security Win32 APIs were stolen (err, ported) from the OS/2 API. (OK, loosely based upon) > > 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. For the sake of my sanity, we'll ignore Windows 9x/Me OSs. I still claim with all my heart, that Windows 9x/Me is not an Operating System. But again, I digress. Let me make myself clear, I'm talking about Windows NT/2K/XP/2K3 based kernels. Not that Windows 3.11 on steroid ones. Actually I can help you. At least half of the Unicode function within, say, Windows NT 3.51/4, are broken. They are nothing more then stubs. I guess I was talking more about the native NT API(s). Security functions, thread, fibers, processes, files. (And the internal ones NtXXXXXX) *However*, long time ago I was designing a security sub system that was supposed to work above the Security API. Again, the ability to give different set of security ACLs to a certain thread, memory page or file, all within a single server was very appealing. The project was dumped after the third bug I found, within the Windows NT 4.0 implementation of the security API, that crashed (BSOD) the OS. We just couldn't get the damn thing to work properly. (Heck, to get it to stay stable...) Again, I moved to Linux and doing my best to move my company to Linux, so one must assume that I truly believe in this platform. As much as I think that Windows NT/2K/XP/2K3 original design is impressive, the implementation is sourly lacking and MS has an annoying tendency to push all of their development resources on ways to screw their clients instead of trying to get the damn thing to work right. The best set of ACLs can do little good, if a stupid user can crash your main server, by viewing a web page... Oh. And the Registry is simply the dumbest idea *ever* imagined. It's a security hole by design. It's a stability problem by itself. It rivals a certain decision by a certain French army general to carry the army's food in tin cans, cause, well, tin may rust, but the winter is pretty nice and warm, here, at *Moscow*! > > 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 Take care, Gilboa Davara XML - Systems Israel. mailto:[EMAIL PROTECTED] ================================================================= 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]
