I know it’s cruel to mock people who don’t know better, but is it still cruel to mock people who ought to know better? Anyway, this project has caused much mirth and merriment in our office this afternoon. Basically, some 18 year old kid in California reckons he can parse Windows .EXEs using a python script, turn them into Mach-O binaries, munge all the DLL calls into Mac equivalents and bing Oblivion magically runs on a Mac!
Quite apart from the fact that the source suggests that he’s basically just downloaded the Win32 SDK, stripped the headers and run a script to replace them all with STUB() functions except for the 10 or so that are needed to get Oblivion to display an “It’s all gone a bit shit-shaped” dialogue box and that he’s effectively given himself the job of reimplementing the whole of Win32, he basically has no chance of succeeding with his current method. For a start, he’s assuming that the code will run as written – quite an assumption, given that they’ve been compiled for different operating systems with different memory models, different process models, different, well, everything really. He’s also only replacing DLL calls – so statically linked binaries are presumably out, as is anything that uses COM (whoops, there goes all of DirectX), int calls (whoops, there goes all the syscalls) and a whole bunch of other stuff.
I’ll be following the project with interest, needless to say. But I won’t be holding my breath.
I thought strictly speaking the Win32 API ended at the API boundary; how the calls were implemented by KERNEL32.DLL were none of the application’s business?
Certainly, WINE runs a lot of stuff on that basis.
*Is* there such a thing as a statically-linked Win32 binary?
Have a look at this. I don’t believe there’s any way he could succesfully translate that.
I won’t pretend that I understood a single word of that post, but you have convinced me that he certainly does not know what he’s doing.
Does he know the company you work for exist?
Is it April the 1st already?! 🙂 Someone needs to have a word with that guy (and find him an easier tree to bark up).
Hi Chris,
I’m Cody Brocious, founder of the Alky project. I think you’ve greatly overestimated the issues involved with such a project. You say that different memory models, process models, etc will be issues. But you forget that the differences in memory models only comes into play when calling into our libraries in general (unless it tramples over other code, etc, but that’s certainly an edge case) and can be mapped as needed there. You also mention that you believe statically linked binaries would be out, when these will simply be calling the lower level APIs as needed, generally. COM will be a pain in the ass to actually do, but we can hack around it in many cases, such as we’ve done for Direct3D. We nearly have a very simple Direct3D9 application (simply drawing a quad and a triangle, but it’s a start) executing fully under Mac OS X, only delayed so far by the fact that I’m finishing up Linux support at the moment. Syscalls, where they’re used from userspace, a rarity in itself, will be a pain in the ass honestly. One method I’ve thought of to solve it is to catch the SIGSEGV generated from throwing a bad interrupt (I can’t recall what a sysenter outside of kernel mode will do, though, if it’s not handled) and then handle it and jump back into code, but that’s not wholly desirable.
All in all, I believe Alky is a solid project and although our success is limited so far, it shows promise for the future.
If you’d like to discuss this further, you can email me directly at cody.brocious@gmail.com or contact me at our forums or IRC channel, referenced from the Contact Us page on our wiki.
Thank you for at least making note of us, even if it wasn’t in the most positive of lights 😉
Take care,
– Cody Brocious