Nguyen Thai Ngoc Duy schrieb: > 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.
I admire your effort to make busybox run on Win but i wonder why there seems no compartibility lib for porting UNIX programs to Win. Surely this is not the first time it is done. regarding your regex problem there is libregex: http://de.sourceforge.jp/projects/sfnet_mingw/downloads/MSYS regex/regex-0.12-1/libregex-0.12-1-msys-1.0.11-dll-0.tar.lzma/ ntl i would stay away from ash in the first run and see what other problems may show up with the already ported utilities. re, wh _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
