docu update

Ivan puoti at
Sat Jun 19 18:02:36 CDT 2004

> Anyway, Wine doesn't have any menu
> integration.
And why shouldn't we have the wine programs in the menu?

> Compiling it as i586 or i686 should be fine, very few people use
> processors old enough to barf on it

> That's what apbuild solves. It lets you compile for glibc 2.2 on a 2.3
> system, amongst other things.
And what if the user wants a glibc 2.3 build?

> Yes, we still do that, but most people use the Loki installer - in fact
> I'm pretty sure it's the most popular by a long way.
Maybe, but for example Mandrake users won't get wine listed in the "remove
software" utility, and that will be confusing

> 1.0 implies API stability, not that it's suddenly good enough that
> people won't want to upgrade.
I presume by then wine won't change so quickly. And the average user (the
average pc user, not the average linux geek)
is lazy and often doesn't upgrade if he doesn't have to

> That's entirely wrong, it works fine. What did you think the recent
> high-gig mmap patches were for?
they won't help wine-20040615 any more.

> Also some distros are built for i386, others for i586 and others for i686, how
can you
> have one binary for all, force them to all use i386 (That will be about 30%
> slower that a i586 build)?

> Just build them for i586 or i686, like I said, that should work just
> fine. I really doubt anybody is running Wine on a system that can't cope
> with an i586 compiled binary. 30% sounds extremely high anyway, I'd want
> to see hard figures on that.
That was a benchmark done by comparing Red Hat and Mandrake, it was a few months

> Sure, it may be possible to build one binary and run
> it anywhere, but in most cases it wouldn't run as well (and as fast) as a build
> done natively on the distro.

Actually, yes it is. Go read the docs on to find out
> would be somewhat suboptimal as we sacrifice speed for flexibility and distro
Do we NEED to sacrifice such things? Also we can't use it until version 1.0, it
will be reasonable to look at this then.


More information about the wine-devel mailing list