Windows port?

Nguyen Thai Ngoc Duy pclouds at gmail.com
Sat Apr 17 10:42:02 UTC 2010


On Sat, Apr 17, 2010 at 8:40 AM, Rob Landley <rob at landley.net> 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


More information about the busybox mailing list