Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Oliver Tappe <zooey-3S8xsmjlUPt7rKnHJAcXLw <at> public.gmane.org>
Subject: Re: Wine port and upstream feedback
Newsgroups: gmane.os.haiku.ports.user
Date: Friday 22nd July 2011 17:43:06 UTC (over 5 years ago)
Hi Damjan,

On 2011-07-22 at 18:39:43 [+0200], Damjan Jovanovic
 
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---
>  julliard: libpthread/libm/libc aren't mandated in ANSI or
> POSIX, do you mean they're just de-facto *nix standards?
>  yes
>  julliard: haiku's policy seems to be that's an upstream bug
>  that must save haiku a lot of work, that policy
>  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?

>  ok thank you
>  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...
>  what are all the changes they have to do?
>  address space layout, gdt/ldt support, kernel threading
>  probably a lot more
>  it took a lot of work for the freebsd guys to fix their
> kernel to support wine properly
>  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
 
CD: 3ms