Windows port?

Rob Landley rob at landley.net
Sat Apr 17 06:40:13 UTC 2010


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.)

> Yes, there are MSYS/Cygwin/MKS. They
> are great. They are also huge, and likely conflict each other if
> installed on the same system.

You can statically build a binary against mingw.  (I got it working under wine 
once to test a tinycc issue, there's a note at the end of the 
http://landley.net/notes-2008.html#19-01-2008 entry about it.)

> In work environment when I only want to
> get things done quickly, I don't really want to install them. Busybox
> in this regard would be beautiful: a single executable that has almost
> everything.
>
> A bit of background
>
> The port originally reused lots of code from Git compatibility layer.
> It was called "git-box" because I wanted something that makes Git
> shell scripts run on Windows. Nowadays the amount of Git code is
> reduced a lot (though remains). Git is GPL-2, I don't think we will
> have license conflict.

License should be fine, busybox is already GPLv2 only.

> 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?

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...

> 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...

> 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.)

> 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.

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds


More information about the busybox mailing list