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
On Thu, Dec 26, 2002 at 09:56:01PM -0500, ATMRD@aol.com wrote:
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:
I fixed the Linux/PowerPC port. So any PowerPC processor related issue is ok.
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?)
Is ok.
-> Exception handling, Signal handling code
Depends on MacOS X.
-> Memory alignment issues
Should not be a problem.
-> 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".
WINE needs a different kind of threading, this might be problematic.
-> 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(?)
Err, we support audio drivers and have several others non-OSS already. No problem here, just implement a MacOS X sound driver.
-> Must ensure that behaviour of lower level UNIX resources like sockets, threads, files are the way WINE expects it.
This might be more difficult. Especially the memory management.
-> 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)
Is done already, for the normal PPC32 ABI.
Good luck.
Ciao, Marcus
-> 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)
that'd be an issue if you need those features... Some folks (R Lunnon for example) face similar issues on Solaris
-> Debugger seems tied completely to Intel architecture. (Since we will be using WineLib, we probably don't need winedbg, can use gdb?)
you can use gdb. regarding winedbg, there are (at least two ways) of using it: - either as a real debugger. porting this to an non Intel arch may require quite some work - using winedbg as a remote nub for gdb (winedbg -- -gdb). in this case, porting it to a non Intel processor should be pretty much more easy (there are a couple of #ifdef to implement in winedbg/gdbproxy.c to implement)
A+
-
ATMRD＠aol.com -
Eric Pouech -
Marcus Meissner