How to port uclibc to Windows CE

Rob Landley rob at landley.net
Tue Feb 8 22:11:45 UTC 2011


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


More information about the uClibc mailing list