Re: Hmmm & Karl Lattimer
To be clear I do not contribute directly to wine, some of my contributers also contribute to wine. I develop an on the top solution for wine which takes the pain and anguish out of meandering through the rough and ready world of native,builtin dll hell. It also has desktop integration which is nice... ok end plug.
In response to your question though (I suppose I'm still qualified for that), apple would most likely follow the route of taking the code from codeweavers which is bad for open source and baby deer or contributing upstream changes to WINE which is good (bambi is safe). Apple have helped out existing FOSS projects before (Webkit/KHTML, Apache, Samba to name a few), and in some cases purchased the projects soon after (CUPS).
It isn't unlikely that apple will assign developers or contribute funds to help the wine project the the boost it deserves. As long as they comply with the LGPL and don't start acting shark like I'd welcome the introduction of Apple into the wine community, more users means better wine after all (this cannot be said for all wine, i.e. Lambrusco).
I'm still tilted toward the notion that its part of a virtualisation plan, WINE offers all of the PE/DLL stuff as part of the launcher binary, all you'd really be doing is shifting ALL of that into kernel space and putting on top of it a bunch of DLL files which might not be ahem... secure.
PE/DLL in the kernel is a bad idea IMHO, I remember the WINE project discussed a kernel module to perform some of the loading for them but they were very apprehensive about it at the time, with a walled garden kind of approach.