Hi everyone,
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 realize that this topic has already been approached
a couple of times in the past on this mailing list,
and I have made note of the issues raised in those discussions.
I have listed below a preliminary list of some of the issues
I have found so far. I am just starting to dig through all of
WINE's source to see if I can find any other
obvious trouble-spots. I was hoping that people who are more
knowledgable about certain areas of WINE could help me out
and let me know if I am missing any issues.
Thanks.
-James
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?)
-> Exception handling, Signal handling code
-> Memory alignment issues
-> 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.
-> 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)
-> 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(?)
-> Must ensure that behaviour of lower level UNIX resources
like sockets, threads, files are the way WINE expects 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)
-> Debugger seems tied completely to Intel architecture.
(Since we will be using WineLib, we probably don't need
winedbg, can use gdb?)
-> 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)
-> 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?
--
James Hatheway
Software Designer - Macadamian Technologies, Inc.
[EMAIL PROTECTED] ~ http://www.macadamian.com
"Nothing is a problem once you debug the code."
