On 02/08/2011 06:45 PM, Rich Felker wrote: >> >> 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.
It's called "Cygwin". >> >> 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. Cygwin provides something vaguely like posix semantics for Windows, by essentially sticking an ENTIRE NEW OPERATING SYSTEM in between your application and Windows. The result isn't actually very good, but to even approach Posix on windows, your transaltion layer really does need to be that thick. Mingw provides no translation layer, it just rehosts the tools and lets you program to the Win32 API with them. Minimal Gnu for Windows. If you program for Posix and build with Mingw, it won't work. People keep wanting something between the two, because they don't understand the problem. They don't really _believe_ that providing Posix semantics for Windows is a horrible crawling nightmare from the depths of R'yleh come to devour the innocent, and they want somebody to magically make Windows work like Unix by waving a wand without actually adding any code or complexity ot the result. If this was easy to do, somebody would have done it by now. If it was HARD to do, the result would look a lot like Cygwin. Suggesting that you can just tweak a couple of lines and make uClibc run on Windows when it hasn't even been ported to MacOS X or FreeBSD... Laugh. It's funny. Suggesting Porting uClibc to work within the context of Cygwin might be technically possible, but would be a horribly bad idea utterly at odds with the "micro" part of uClibc. (The cygwin developers had to hack up glibc until it was unrecognizable.) Doing so would defeat the purpose of using (or developing) uClibc, and by complicating the uClibc code and making it harder for the Linux developers to understand and maintain the Linux version would make it a worse thing to use on Linux. Executive summary: bad idea, killit with fire. Rob _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
