[PATCH 00/39] Windows port, base and archival/

[Nguyen Thai Ngoc Duy]

On Fri, May 21, 2010 at 7:51 PM, Rob Landley <rob at landley.net> wrote:
[snip]
> I don't believe the "too big" problem is entirely cygnus, I believe that the
> fundamental problem is that Win32 and Posix are very dissimilar and making one
> look like the other is a big job.  (Wine, going the other way, isn't a trivial
> project either.  They spent something like eight years in alpha test.)

I never dreamt of making a full posix compatible layer (that would be
cygnus/cygwin's job). I realized (though I could be wrong) that many
busybox applets do not need that level of layer to be functional.
That's why I started this. The only big thing, in terms of Posix, is
the shell. And I agree that ash for Windows is a big job.

> There is a case to be made that cygwin is bigger than it needs to be becuase
> it's full of gnu bloatware.  So of course your suggestion was to suck in gnu
> code to fashion a busybox-to-windows glue layer out of.  And you see no
> problem with this.

The bloatness of cygwin is only one of the user inconvenience:
 - too many things to do (cygwin setup and stuff) in order to make busybox work
 - does not understand Windows concepts, like Windows drives.
 - sometimes Cygwin conflicts with yet another Posix emulated layer.

The last two won't be solved easily with Cygwin solution.

> There's also the "oh, but we'll only solve _part_ of this problem and leave
> the rest unsolved, and be small by doing a half-assed job which nobody will
> ever try to use as precedent to push more of the same into the project in
> future".  The phrase Peter Salus used for this was "the camel's nose under the
> tent flap".  It tends to be followed by the rest of the camel.  If you cross a
> boundary, where is the next boundary?  Nobody seemed to have a clear answer to
> that one.
>
> If you want to slim down cygwin, do it.  If you want to extend mingw, do that.
> If you want to split the difference and try to write a thin glue layer on top
> of mingw that's good enough to build things like busybox but smaller than
> cygwin, go for it.  My point is, this is not busybox's job.

Even with a thin glue layer on top of mingw, busybox needs to be
adapted a little bit on Windows environment, for user convenience
(otherwise you just grab cygwin or better linux-in-virtualbox). And
even users need to be adapted a little bit to the Posix thing (like
forward slash). It's a compromise. Something in between the
Posix/cygwin and the powerful-enough-mingw, as you put it.

Some applets/features clearly won't work. Some should work fine, given
enough effort. Some might or might not. There is no clear cut. I guess
this port will live as a side project for a few years. If it proves
good enough, i.e drawing clear lines between "those some(s)", then
maybe someday it will be proposed here again.

In other words, the windows port discussion could be stopped here.
Other non-Posix attempts are still welcome, I hope.
-- 
Duy