James Hatheway wrote:
>
> I have just started to look into making a list of all of
> the issues that would have to be resolved to port an
> application to MacOS X using WineLib.
I briefly started on a MacOS X port at MacHack, but stopped after being
annoyed at how many header files for important stuff MacOS X seemed to
be missing.
I have a tarball of an old hacky winelib port to LinuxPPC around. At
MacHack I switched to updating it for then-current WineLib, but got
stuck on the issue of thread local storage. The solution there is
to apply a patch that makes wine use pthreads for Windows threads
(I know that Andrew Lewycky did this for Corel for the cprof profiler,
and I think that CodeWeavers may also have something).
> Current list of possible issues:
> ================================
> -> Endianness. Since we are using WineLib, could
> have resources written in native (big) endian format
> with wrc. Any external data files such as cursors, bitmaps, sound
> would have to be converted. The PUT_WORD/GET_WORD macros
> need byte swapping turned off. (Did I miss anything?)
There was some argument between Bertho and I on this point, as I
recall: Should resources always be in little endian format, and
converted to big endian at load time, or should they be written in
big endian format from wrc? The solution I used in my hacky port
a year ago was that wrc writes out big-endian data. This means that
there has to be some conversion for the external formats you
mentioned.
I think it's best to do the conversion once in wrc, not every time a
resource is loaded.
When we did MacPort at Corel, we went further than that: things like
bitmaps and cursors were converted into something closer to the format
that was used in the underlying OS. IE: Windows cursor resources were
converted into Mac cursor resources, etc.
Actually, speaking of MacPort, if your project is MFC based, you might
want to talk to Corel about using MacPort instead of WINE. Last I heard
they were working on Carbonizing it for MacOS X.
> -> Memory alignment issues
These are more of a performance issue than anything else. You have two
choices: either pack structures the same way they're packed in Windows,
or pack things the way the native compiler wants to pack them. In either
case you're going to need data conversion for data that gets loaded
from disk, whether that conversion is just byte-swapping or also moves the
data into structures with slightly different alignment is the question.
> -> Presence of Assembly language in code will have to be written
> in C or translated to PowerPC assembly. (assembly is generated
> in spec.c files, as well as other places like in the server)
My hacky port from last year has the necessary PPC asm generation.
> -> Debugger seems tied completely to Intel architecture.
> (Since we will be using WineLib, we probably don't need
> winedbg, can use gdb?)
gdb worked just fine in my hacky PPC port last year.
> -> Need a X11 server or need to make a x11drv replacement that
> is Quartz specific. (There is a XFree86 port to MacOS X, but
> it only runs seperately from Quartz at this time. Making the
> X server a rootless client of Quartz is on the TODO list of
> Darwin but there is no mention of its current status.
> There is a commercial server, at:
> http://www.tenon.com/products/xtools/ which already implements
> this)
Mmmm - new backend driver. This would be a good thing, IMHO. It'll
be a major pain to do, but would be a huge boost to taking WINE truly
cross-platform. The GDI side should be fairly straightforwards, but
the window/event management will be nasty.
> -> Need to be able to build Windows app using gcc (might be issues
> such as using MS specific keywords/language constructs, etc.)
> Does ATL build properly with gcc?
Don't know about ATL building with gcc, but it should certainly built
with CodeWarrior, since Metrowerks has to support it on Windows and the
compiler uses a common front end. Metrowerks is likely to be better in
general at compiling code from Windows.
-Gav
--
Gavriel State
CEO
TransGaming Technologies Inc.
[EMAIL PROTECTED]
