Mac OS X Port of WineLib

Hi,
     I dont recall how I stumbled upon Wine and its existance, however I am 
intersted in recent, if any, devlopments with the porting of Wine to OS X.  I 
checked the Wine site and most of the articles are dated with the lastest 
date of Nov 2000.  A lot has changed in OS X since that time and it appears 
that a leats a couple of the main issues have been addressed during this 
time.  The main issues which seemed to be posted are as follows:

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"
   (<A HREF="http://developer.apple.com/techpubs/macosx/Kernel/KernelEnvironment.pdf">http://developer.apple.com/techpubs/macosx/Kernel/KernelEnvironment.pdf</A>)
   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:
  <A HREF="http://www.tenon.com/products/xtools/"> http://www.tenon.com/products/xtools/</A> which already implements
   this)

-- the XFree86 port to MacOS X now includes a rootless clinet of Quartz so 
this should be a big jump having the window manager avialable.

-> 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?

in addition  James Hatheway wrote on Nov 10 2000
"To test these concerns, I made four test apps and compiled and ran them
on Mac OS X.  I used the "Mac OS X Public Beta Developer Tools CD"
which is downloadable from<A HREF="http://connect.apple.com"> http://connect.apple.com

</A>
The first test app used mmap and MAP_SHARED option, the second sent
messages between two programs using sendto over a socket, the third
used file I/O functions (like read,write) to send messages over a
socket, the fourth sent an FD over a socket to another process
using sendmsg/recvmsg.

I have good news, each of these programs compiled without
modification on MacOS X with the standard cc, and ran perfectly!!

So, I don't think there are any show stoppers that would
keep us from being able to port WineLib to MacOS X.  
Of course there would be work to do, but at least it
is definitely possible.

"

I dont no what has happend to the  WineLib port to MacOSX if anything.  
However, I am willing with what time I have to begin a port, since it does 
seem like it can be done now, hopefully with a group of people.  In addition 
apple has posted some information regarding win32 porting that may be a 
little help at "http://developer.apple.com/macosx/win32porting/%22.%C2%A0 Hope you 
had the best of holidays.
Thanks

~Sanjay Connare