Windows port?

[Denys Vlasenko]

On Tue, Apr 13, 2010 at 1:01 PM, Nguyen Thai Ngoc Duy <pclouds at gmail.com> 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. Yes, there are MSYS/Cygwin/MKS. They
> are great. They are also huge, and likely conflict each other if
> installed on the same system. 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.
>
> 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.
>
> 2. changes inside busybox to support Windows specific things, e.g.
> drive letter, line ending, .exe...
> 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
>
> 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.

hush may be a better shell to work with, it can avoid using fork()
(will use vfork+preparatory_work_in_the_same_process_image+exec
if built for NOMMU, which probably maps better to Win CreateProcess()
call or whatever)

>
> So, comments?

This is acceptable in general, if can be made localized enough.

Please send a patch or an URL to patch against one
of the released versions for more detailed review.
I went to your URL but didn't find
an obvious way to download a tarball or diff.
-- 
vda