On 02/08/2011 01:33 PM, David Lynch Jr. wrote: > > > On Tue, 2011-02-08 at 14:18 -0500, Rich Felker wrote: >> On Tue, Feb 08, 2011 at 09:56:24AM -0500, David Lynch Jr. wrote: >>> I am not specifically familiar with Windows CE. But I have done lots of >>> cross platform work with windows. Ignoring tangents like the Windows >>> Posix subsystem and Cygwin, normal windows - microsoft's C libraries >>> provides a significant portion of POSIX support. The critical problem >>> is that windows developers almost univerally use the Windows specific >>> API's over the more portable POSIX API's. >> >> This is not true. The Microsoft libc (MSVCRT) does not even conform to >> ancient versions of the C standard, much less C99, and the degree to >> which the functions with names that mirror POSIX functions differ from >> the POSIX-specified behavior is laughable. (For instance, sockets and >> file descriptors are not the same and cannot be used interchangibly, >> and they're not allocated in lowest-available order.) >> > > I did not claim that Microsoft conformed to the POSIX spec, just that > with a small amount of care on the part of the developers, it was > possible to write portable code.
With a small amount of care, goldfish are drinkable. Many things are possible if you only care "a small amount" about the end result. Code can be ported back and forth between windows and sane operating systems, yes. From that perspective all code is "portable", in the same way that Howard Tayler remarked "Everything is air-droppable at least once". > I am not particularly enamored of the POSIX standards. Not that there > is something wrong with them, but I know very very few developers that > use more than a small fraction of the API. More than a small fraction of the posix API? I've used most of it at one point or another. I've even occasionally sent in bug reports and fixes on some weird corner case behavior to improve our compatability with it. (Both in busybox and in uClibc.) If you mean "Use more than a small fraction of the Windows API"? A personal point of pride is that I've never written a program for the Windows API. Programs that ran on windows because they were java or javascript or built under cygwin, sure. Programs for OS/2 API including the workplace shell that windows copied heavily from (although they did things like reverse the order of arguments in functions with the same name, to make sure the two were intentionally incompatible), sure. Kept track of Win32s vs Win32c to figure out what would run on WinOS2 and what wouldn't, including reading some programming books Charles Petzold wrote on the subject, sure. Posix isn't the only standard Windows doesn't conform to. In addition to C99, there's LP64, the standard specifying type sizes which Linux, MacOS X, BSD, and pretty much everything except Windows all conform to: Standard: http://www.unix.org/whitepapers/64bit.html Rationale: http://www.unix.org/version2/whatsnew/lp64_wp.html But Windows intentionally chose _not_ to do so, and instead did LLP64 because their developers used "long" and "int" interchangeably for years and rather than clean up their headers they bent their 64 bit API into a pretzel: http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx Which really has to do with Microsoft internal politics explained by an ex-microsoft employee here: http://www.joelonsoftware.com/articles/APIWar.html Did you know that Windows was written off as a loss by Microsoft until one guy (David Weiss) single-handedly resurrected it by inventing "Thunking" and turning their 16 bit toy into something that could access 4 gigs of ram without recompiling the applications? (Still segment/offset addressing, but the segments no longer had to overlap.) http://blogs.msdn.com/b/larryosterman/archive/2005/02/02/365635.aspx Did you know that the reason Windows XP was a technical regression from Windows 2000 (with regards to stability and the device model and such) had to do with Microsoft losing a class action lawsuit against its own employees and accidentally firing the build team responsible for COMPILING windows? Meaning they stopped being able to build Windows 2000, had to back up to the last thing they _could_ build (NT 4), retasked the dev team coming off of Windows Millenium to backport as much of Windows 2000 to the older codebase as they could and then "Make it pretty enough to sell as an upgrade." I collected links at the time, but they tend to go stale after a while if you don't mirror 'em: http://blog.valerieaurora.org/2009/03/12/parallel-file-system-worlds/#comment-802 I am fairly familiar with Windows. It is crap. When I say it's a point of pride that I've never written a windows program, I'm not speaking out of ignorance of the technology. Yes, it can be made to work, with the aid of billions of dollars of corporate funding and a complete disregard for technological advisability. So can cobol. Both survive for similar reasons, and experts in both command high prices because nobody with an ounce of sense, taste, or technical judgement wants to get any of it on them. But expecting Microsoft to be any good at programming is like expecting wal-mart to be good at manufacturing. It's not actually what they _do_. Rob _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
