Re: Wine port and upstream feedback

Hi Damjan,

On 2011-07-22 at 18:39:43 [+0200], Damjan Jovanovic
<damjan.jov@...> 
wrote:
> 
[ ... ]
> 
> Anyway those 3 patches were submitted for inclusion into the official
> version of Wine, but rejected a little later by Alexandre Julliard
> (Wine's maintainer) with this comment (in reply to
> http://source.winehq.org/patches/data/76781):
> 
> "I'd suggest to file bugs with Haiku, they should provide
> compatibility libraries, that stuff is very much standard."

Of course, Alexandre isn't referring to any actual standard here, he's just 
talking about the status quo of the most popular operating systems, which I 
find a bit unfortunate.

> I then went on IRC to get further details:
> 
> dacha = me
> julliard = Alexandre Julliard
> 
> ---BEGIN IRC SNIP---
> <dacha> julliard: libpthread/libm/libc aren't mandated in ANSI or
> POSIX, do you mean they're just de-facto *nix standards?
> <julliard> yes
> <dacha> julliard: haiku's policy seems to be that's an upstream bug
> <ohsix> that must save haiku a lot of work, that policy
> <julliard> i don't think it's unreasonable to ask that minority
> platforms conform to what the rest of the world is doing, instead of
> asking everybody else to change their ways

While that train of thought may come natural to someone involved in a project 
that's trying to emulate the API of the most popular OS, it doesn't make 
sense at all: as you've mentioned above, the libraries where the pthread API 
or the maths functions live are in no way standardized (at least I do not 
know of any such standard). If there would be such a standard, we could 
decide to follow it, but since there isn't, why should we have to shape our 
libraries just like some other OS? It's hard enough trying to follow the 
actual standards, so I'm personally not at all interested in following cargo 
cult.

The mere purpose of the autotools suite is to do away with needing fixed 
assumptions about where any specific function lives (and what its exact 
name/signature is), so I think your fixes are exactly on spot. I actually 
fail to see why they were rejected in the first place - i.e. are there any 
problems/regressions your patches would cause for Wine?

> <dacha> ok thank you
> <julliard> considering all the changes they are going to have to do to
> make wine run, if they don't even want to support -lm there isn't much
> hope...
> <dacha> what are all the changes they have to do?
> <julliard> address space layout, gdt/ldt support, kernel threading
> <julliard> probably a lot more
> <julliard> it took a lot of work for the freebsd guys to fix their
> kernel to support wine properly
> <julliard> i expect haiku will be even more work
> ---END IRC SNIP---
> 
> Ouch!

Indeed, none of that makes much sense to me. Alexandre obviously doesn't know 
much about Haiku and our community, so if I were him, I wouldn't take wild 
guesses as to which parts of Haiku need to be fixed in order to support Wine. 
That's *our* part - he should just be worried about giving proper reasons for 
why he doesn't accept improvements to Wine's autotools setup when someone 
else has done the work already. If there actually are reasons for not 
accepting your patches, I'd be interested to hear them ...

cheers,
	Oliver