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

Rob Landley rob at landley.net
Sat Apr 24 22:48:56 UTC 2010


And this one too...

On Monday 19 April 2010 00:43:18 Nguyen Thai Ngoc Duy wrote:
> >> If you read the patch, you would see that it only refuses to build you
> >> you do use MinGW compiler and not have TARGET_WIN32 set.
> >
> > I mean the approach of annotating magic knowledge of build environments
> > in kconfig is a neverending battle that will bit rot every single release
> > of OTHER people's code.
> >
> > For example, future versions of mingw may have these headers you need
> > included in their build environment.  So your workaround becomes
> > irrelevant but busybox development has no way of knowing that.
> >
> > Did you even _try_ to submit these headers upstream to mingw and say "I
> > need this to build busybox"?
>
> I doubt they will accept.

Then why should we?

> Mingw is a compiler with mvscrt.dll as
> runtime C library, not POSIX environment. MS follows "ANSI standard"
> (don't ask me what it is).

That's the C language specification.  It's for a programming language, not an 
operating system.

The current version (C99) is this:

  http://busybox.net/~landley/c99-draft.html

Last I checked Microsoft mostly still followed the older one from 1989, and we 
use the one thats only a decade old at this point.

By the way, for the whole 64 bit transition thing the relevant standard is 
LP64:

The LP64 standard:
  http://www.unix.org/whitepapers/64bit.html

The LP64 rationale:
  http://www.unix.org/version2/whatsnew/lp64_wp.html

That guarantees that "long" and "pointer" are always the same size on both 32 
and 64 bit systems.  (Hence LP64.)  Int remains 32 bits on both platforms, 
short is 16 bits, char is 8 bits.

This standard is adhered to by Linux, all the BSDs, MacOS X, pretty much every 
OS out there...

Except Windows:
  http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx

They kept long and int the same size always, and use "long long" even on 64 
bit systems to specify 64 bits.  They did so because their binary ABI 
definitions sprinkled "long" in all over the place and they wanted them to stay 
32 bits without rewriting their headers because they're lazy and hilariouusly 
bad at programming.

So what you're saying is you want to crap 32-bit windows compatability code 
all over bsybox, but never have any hope of supporting 64 bit windows without 
a massive rewrite of busybox that makes it harder for us to work on MacOS X 
and Linux and BSD and basically everywhere else.

Why is this interesting again?

> Adding headers does not solve the problem,
> they will have to implement missing functions too, and they are
> compiler guys.

If your build environment is broken, fix your build environment.

> >> >> Very basic stuff just enough to make a succesful build. You
> >> >> will have a nice 52K busybox.exe, with no applets.
> >> >
> >> > On Linux, or allnoconfig is 10k.  (I'm not sure _why_ it's 10k, I
> >> > thought it used to be more like 5k, but oh well...)
> >>
> >> Well, size does not matter that much to me,
> >
> > THEN WHY THE HELL ARE YOU USING BUSYBOX?
>
> Source code size matters, not binary size. Busybox source is more
> compact, and features can be tweaked in/out easily. That would help
> the port (even isolate features that won't work).

Our source code is small EXACTLY because we haven't polluted it with this kind 
of stuff over the years.

That's the reason.  We think through the minimum we can get away with, rip OUT 
existing stuff that's already working but which we don't need.

> >> at least for now. Who
> >> knows, I might do size optimization someday if its functionality is
> >> good enough.
> >
> > *whimper*
> >
> > It...  The goal of busybox...  Small, simple, and self-contained.  That's
> > the whole point.  You've managed to violate all three of those design
> > goals in this message.  I'm in _awe_...
>
> It's still simple (I hope)

Beign "simpler than anything else on windows" is like being the most agile 
quadraplegic.  I really, really, really, really don't want to get any of 
Windows on code I have to look at.

> and self-contained (unique feature that
> separates busybox from cygwin/msys).

I can't test your changes.  I will break your changes if I ever modify busybox 
again.  This your code will bit-rot unless you sit there and baby-sit it 
forever.

You're also imposing rules on my future changes.  "Don't do X or it'll break 
windows".  This is something about which I WILL NEVER CARE unless paid to do 
so.

> And if you care about size,

If?

Dude.  You're on the busybox list.  You're implying that we don't care about 
size.  How clueless do you get?

I think what you're trying to implying is that if we don't care about 
supporting windows, obviously we don't care about small code size, which is 
false and insulting.

> busybox is much smaller than MSYS or Cygwin base install.

That's like saying castor oil is tastier than motor oil.  Obviously castor oil 
is the ultimate beverage then.

> Not "small"
> by Linux standard, you know it's Windows.

That's not an excuse.

We trade off size, simplicity, features, and speed.  We're trying to optimize 
for all four, but we tend to weight the first two more heavily becase there's 
lots of others out there that weight the last two more heavily.  (That's what 
distinguishes us from them.)

Yo're promising to make busybox bigger and more complicated.  In exchange, 
you're promising the "feature" of limited windows support.  Except Cygwin 
already built most of busybox last I checked (2006), so the value of this 
feature has multiple levels of "dubious" built-in.

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




More information about the busybox mailing list