Jim White wrote:
> I think they were only converting the syscalls but I don't really
> remember Gav told me various stories of their Mac porting efforts
> at WineConf.
It would be interesting to chat with those folks indeed. I take it that
given that their product is dependent on Wine, wh
Your knowledge of porting is evidently limited. The folks at the Fink
project would be surprised to learn that what they're doing is simple.
It's trivial compared to porting an app from a proprietary OS - I think
the existance of Winelib spells that out. Porting an app from Linux to
FreeBSD, So
Mike Hearn wrote:
This is the more general project that has emerged from my initial idea
for Darwine, namely X86/Linux binary compatibility for OS X.
Hmm, what is that useful for? Nearly all software for Linux is open
source and can be ported or sometimes simply recompiled for any given
platfo
This is the more general project that has emerged from my initial idea
for Darwine, namely X86/Linux binary compatibility for OS X.
Hmm, what is that useful for? Nearly all software for Linux is open
source and can be ported or sometimes simply recompiled for any given
platform. Do you have an
Mike Hearn wrote:
...
As for swapping functions, the preceding discussion reiterates my
belief that we should confine such fussy business to the relatively
small bit of code that calls into OS X, will be relatively stable over
the long haul, and over which we have full control. And as for the
>> b) TransGamings Cedega forked from Wine several years ago, back when
it was under the X11 license which allowed that. So they don't have to
contribute their code back.
c) That fork was what motivated the switch to LGPL.
Well that makes sense. I couldn't make heads or tails of their
licensin
Le 26 août 04, à 00:58, Jim White a écrit :
Of course if you're planning on compiling Wine as PPC then we're on
different pages architecturally.
I still believe it is the *best* way for us to go. But I agree that as
a first step we can go for qemu-darwin-i386-user, that's why I am now
working a
On 25 août 04, at 18:48, Alexandre Julliard wrote:
"Pierre d'Herbemont" <[EMAIL PROTECTED]> writes:
As a conclusion, would accept that we swap (using the regular way) the
headers in order to load exe on a Big Endian host? (since the exe
headers are Little Endian for each NT implementation)
Pierre
P
Alexandre,
As a conclusion, would accept that we swap (using the regular way) the
headers in order to load exe on a Big Endian host? (since the exe
headers are Little Endian for each NT implementation)
Pierre
PS : the exe header is Little Endian even on a PowerPC NT exe, since
the PowerPC NT im
Le 25 août 04, à 23:01, Jim White a écrit :
I would really like to get away from having to write all the little
wrappers to deal with the namespace problem. I believe we can solve
that with a suitable naming convention as we began to do with the
winegcc patch.
I think we can forget this solutio
On 24 août 04, at 22:50, Alexandre Julliard wrote:
"Pierre d'Herbemont" <[EMAIL PROTECTED]> writes:
Hi Alexandre,
This patch allows to load a PE exe to memory. You may notice that
there is no "mass" byte swapping. The technics used here is a bit
developer here:
http://stegefin.free.fr/wine/
You mig
From the limited experience I have the problem is that if a portion of
code expect to have a certain type of endianness, it would make some
special assumption, we won't be able to track out (See [1]). And it
will be even harder to track the issues for the x86 already compiled
code, in Wine we c
Pierre d'Herbemont wrote:
Le 25 août 04, à 23:01, Jim White a écrit :
I would really like to get away from having to write all the little
wrappers to deal with the namespace problem. I believe we can solve
that with a suitable naming convention as we began to do with the
winegcc patch.
I think
Jim White <[EMAIL PROTECTED]> writes:
> Mike Hearn wrote:
>
>> Please do some basic research, otherwise you just come off sounding
>> ignorant:
>
> Of course I'm ignorant of the most everything regarding Wine
> history. How is that germane to anything?
>
> Your hostile attitude is why I try to lim
N.B. The only substantive paragraph here is the last one, so folks
interested in the X86/PPC linking problem should just jump down there.
Mike Hearn wrote:
I agree that flipping the syscalls is a much more promising approach
than the WIN32 API. I'm also thinking that there is bound to be some
Jim White wrote:
Mike Hearn wrote:
I think you are going in the wrong direction with this; the right way
IMO is to compile Wine for x86 and run the whole Wine+app under the
CPU emulator. Otherwise you'll have to write wrappers for each of the
15,000 APIs.
Certainly dealing with the syscalls alone
"Pierre d'Herbemont" <[EMAIL PROTECTED]> writes:
> As a conclusion, would accept that we swap (using the regular way) the
> headers in order to load exe on a Big Endian host? (since the exe
> headers are Little Endian for each NT implementation)
>
> Pierre
>
> PS : the exe header is Little Endian
I agree that flipping the syscalls is a much more promising approach
than the WIN32 API. I'm also thinking that there is bound to be some
relevant code around aleady (perhaps even in QEMU).
Yes QEMU can do syscall conversion iirc, at least in some modes.
While the current phase of the Darwine ef
Not sure if what I'm thinking would even work, but let's mention it.
Could we add the swapping to qemu? We would end up with a x86
emulation that used big endian instead of little endian.
This way, all memory accesses (from the wine api) would end up
unswapped, while the method calls from the .exe
Mike Hearn wrote:
I think you are going in the wrong direction with this; the right way
IMO is to compile Wine for x86 and run the whole Wine+app under the
CPU emulator. Otherwise you'll have to write wrappers for each of the
15,000 APIs.
Certainly dealing with the syscalls alone is a lot easier th
I think you are going in the wrong direction with this; the right way
IMO is to compile Wine for x86 and run the whole Wine+app under the
CPU emulator. Otherwise you'll have to write wrappers for each of the
15,000 APIs.
Certainly dealing with the syscalls alone is a lot easier than flipping
on ev
"Pierre d'Herbemont" <[EMAIL PROTECTED]> writes:
> Hi Alexandre,
>
> This patch allows to load a PE exe to memory. You may notice that
> there is no "mass" byte swapping. The technics used here is a bit
> developer here:
> http://stegefin.free.fr/wine/
> You might prefer a more conventional way of
22 matches
Mail list logo
