On Tue, Apr 13, 2010 at 1:01 PM, Nguyen Thai Ngoc Duy <pclo...@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 _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox