[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