On Sat, Apr 17, 2010 at 8:40 AM, Rob Landley <[email protected]> wrote: > On Tuesday 13 April 2010 15:01:24 Nguyen Thai Ngoc Duy wrote: >> Hi, >> >> I started the port about three years ago, on 1.6.1. Currently I'm >> rebasing my work on master, but it will take some time before I could >> submit anything. The old version based on 1.6.1 is on >> http://github.com/pclouds/busybox-w32. Anyway I would like to discuss >> about possibilities of merging this upstream. If it is accepted, >> great! If not, maybe I could convince you to accept certain parts (see >> changes below) and let other parts maintained separately. >> >> Motivation >> >> If you have ever been forced to use Windows, you would understand how >> much you miss little Unix tools. > > Which is why mingw exists. (Minimal Gnu for Windows.)
I think you meant MSYS (mingw plus unix like environment) >> Status >> >> Except network and tty-related commands, others (sort of) work. wget >> and vi work, although limited. Linux-specific commands won't work, >> obviously. >> >> Changes to make it happen can be grouped as follows. >> >> 1. implemenatation for missing functions or workaround for bad ones. >> It's ~8000 line of code. However fnmatch.c and regex.c (imported) >> already take about 6000 lines. > > What's your build environment? Mingw cross compiler on Linux. > Extensively working around libc is in general not part of busybox's mandate. > I'm aware that Windows is special, but MacOS X is special too. That's a can > of worms I'd love to avoid opening if at all possible... Windows is even more special than Mac, I think, because Mac was based on FreeBSD. Never used Mac though. >> 2. changes inside busybox to support Windows specific things, e.g. >> drive letter, line ending, .exe... > > We'd need that regardless of build environment, if windows was an interesting > target. > > Being able to hide it in platform.h would be great. Dunno how feasible that > is in this case, but I haven't seen the code yet... Not everything can be hidden there. For example check for root "if (*path == '/')" can be hard coded in applets, which is not enough for Windows port. >> 3. changes to support common used features that do not exist on >> Windows, say "dd if=/dev/zero" or redirection to /dev/null >> About 250 lines, more than 150 changed lines are inside libbb > > We may need a "platform" subdirectory with .c files. (If we add significant > platform specific code, it would be nice to keep it isolated rather than > scattered around the codebase.) I put that in win32 subdirectory, currently. It's quite a few missing functions to make busybox run. Putting them all in platform.c can be messy in long run. >> 4. ash >> ~1000 lines, half of them to work around fork(). Not everything works, >> and not really stable. I'm thinking about a thread-based ash so that >> it would work faster, but stability first. > > A) That makes my brain hurt. > > B) Hush, not ash. > > C) Fix the general problem in some kind of platform/windows.c and then teach > ash to call it. Well, the thing is Windows does not have fork() equivalent. Cygwin emulates it (and FWIW, MSYS forked cygwin1.dll), but I don't want to depend on a satellite cygwin1.dll or such. Ash changes make about 1/3 total, in terms of patches. I'll look at hush. I think the reason I targeted ash was because it's recommended in "make menuconfig" (not sure, it was too long ago). Do you have a brief comparison between ash and hush? Both from user point of view and developer one. -- Duy _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
