How to port uclibc to Windows CE

Rich Felker dalias at aerifal.cx
Wed Feb 9 00:45:53 UTC 2011


On Tue, Feb 08, 2011 at 02:33:11PM -0500, David Lynch Jr. wrote:
> > 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. 

Unless you're prepared to write 2 versions of any code that deals with
the filesystem, your Windows program will be buggy in that it will
fail to open any file whose name doesn't conform to the current "ANSI
codepage". I don't call this "possible to write portable code".

> 	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. In general I encourage

And the most-broken part on Windows is the most-commonly-used part:
file descriptors, sockets, select, ...

I'm not talking about obscure things that historically are full of
bugs and deviations from the standard, like signal handling details,
thread cancellation, etc. I'm talking about the most basic interfaces
necessary to write an application that performs non-trivial IO.

> 	But if you are trying to develop applications that you expect to build
> and work on many platforms, and you have control over the coding
> standards, portability is not that hard to achieve. 

I still think it's a lot of work. If nothing else, you'll end up
re-inventing half of POSIX, and doing things in suboptimal ways
because you're working with a crippled subset of the usual system
facilities.

> 	The Cygwin developers deserve credit for an enormous amount of hard
> work, but their solution has sufficient complexity that you might as
> well switch to Linux. 

I would really like to see a stripped-down cygwin (or
massively-improved mingw) with no global configuration that can break
your apps, and no attempt to make Windows look/work like Linux, just
fixing the important library functions to conform to C99 and
halfway-conform to POSIX, and providing a UTF-8 view of the filesystem
and command line so that programs can use "fopen" or "open" without
resorting to Windows-specific alternatives.

Rich


More information about the uClibc mailing list