> 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.
Cool.
As you perhaps know I tried unsuccessfully to port
Wine to BeOS so I might perhaps be of some help.
> 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?)
[The BeOS port was x86 so that didn't pose a problem.]
Nothing that I can think of but that is not
my area of expertize.
> -> Exception handling, Signal handling code
Probably isn't a large problem on MacOS X.
BeOS didn't pose any large problems in this respect IIRC.
> -> Memory alignment issues
[The BeOS port was x86 so that didn't pose a problem either.]
We just need to find them and fix them. Finding them might
be hard though, but fixing each problem will probably be
trivial.
> -> According to "Inside MacOS X: Kernel Environment"
>
(http://developer.apple.com/techpubs/macosx/Kernel/KernelEnvironment.pdf)
> pg. 34, Darwin supports Pthreads, "many of the POSIX APIs"
> I haven't been able to find any lists of incompatibilities yet,
> but I am afraid of the word "many".
:-)
> -> According to the "MacOS X Kernel Environment" book, pg. 37,
> Mac OSX does not support memory mapped devices through the mmap
> API. This would affects at least streaming sound playback.
But it supports mmap for files? Especially MAP_SHARED?
Speaking of mmap. Does MacOS X support sendmsg/recvmsg?
If not you can forget about porting Wine unless you can
convince Alexandre that the Wineserver should be redesigned.
> -> WSControl / WSAIoctl need to be adapted to MacOS X.
> (ioctl() calls can be platform dependent, /proc/net/dev
> on linux is probably different on OSX)
Can't imagine this will pose any problems.
> -> Sound Support. Currently done with WineOSS (ties into
> Linux OSS drivers) Doesn't seem to be a port of OSS
> to MacOSX. Maybe need to do another layer specific to the
> Mac(?)
Well. The Solaris port doesn't support sound yet so that
is not really nessary.
That said I don't imagine support MacOS X through a special
driver will pose any problems.
> -> Must ensure that behaviour of lower level UNIX resources
> like sockets, threads, files are the way WINE expects it.
Wine currently expects that the file API works on socket descriptors.
This is not the case on BeOS but I determined that this was a
fixable issue. I just never did it.
> -> 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)
Not a real problem just some work I think.
> -> Debugger seems tied completely to Intel architecture.
> (Since we will be using WineLib, we probably don't need
> winedbg, can use gdb?)
Probably.
> -> 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)
Writing a Quartz specific driver is probably not that hard.
<hint-to-Alexandre>
It will be even easier if Alexandre includes my translation layer
which evenable better sharing of code and avoid reiventing the
wheel for each driver.
</hint-to-Alexandre>
> -> Need to be able to build Windows app using gcc (might be issues
> such as using MS specific keywords/language constructs, etc.)
That isn't really a MacOS X specific problem is it?
> Does ATL build properly with gcc?
No idea.
> "Nothing is a problem once you debug the code."
:-)
