Darwine, Parallels, BootCamp, when will it END?
I've been thinking a lot lately about this whole "Windows on Macintosh Hardware" thing lately.
Really I guess I've been thinking about how terrible the current solutions are.
I think I have a better solution but I have no idea how one would go about implementing it, or even if it would be legal. But I think it's doable, at any rate.
Right now there a few things going on in this space:
Apple's got a neat solution of providing a neat dynamic disk partition tool, and a fancy bootloader. Neat as in 'intersting', not neat as in "tidy". Anyone who really needs to use a Windows app will quickly tire of rebooting, and being stuck using a crappy FAT32 partition in order to share files between the two OSes (not to mention the indiosyncracies that have already been reported with respect to the partition tool and the bootloader). While it's probably a good move for Apple, it's probably not the best long term solution for users. Again, I think Apple's really just testing the water with this one, and it will be interesting to see exactly where they're willing to take this in the future, but for now we can file this away in the "good, but not quite right category".
Virtualization is also a pretty nifty solution, and I think there will always be a market for real machine virtualization technology - it's been employed by many an enterprise for years to do server virtualization, for example. (Beneficial, as when the VM goes down, but the hardware stays up, and can even safely restart VMs for you, plus it runs in its own address space like any other process, and can't mess other things on the machine up).
Still, for regular users who don't need to have virtual machines for this type of enterprise separation and protection, the idea of having Mac OS X, all your own apps, PLUS a full Windows install, PLUS whatever app you're running in windows, seems terribly inefficient to me. There is no need to have ALL of windows running, hogging disk space and memory and sweet sweet processor cycles and precious little video card resources. (PS, if you think XP is a hog in this regard, just wait till you see what Vista can do to a machine's resources). Not to mention that issue of dealing with partitioning hard drives, filesystems' respective pros and cons, space limitations, security, etc)
Which nicely brings us to Wine/Darwine, and Mono. This is also a neat idea - probably the best idea we've looked at yet - and I give both projects' founders and contributers the hugest props both for taking this on and for being unbelievably successful at it. This approach achieves much better performance than VM style stuff, allows for neat applications-sharing-resources stuff to work that couldn't possibly with the bootloader approach Apple has taken so far, and can probably overcome most of the ease-of-use stuff with a nifty installer and some diligence.
The problem I have with the re-implementors (Wine/Mono) is that they are re-implementing. They're redoing something that's already done. And this approach doesn't stand a chance at keeping up with what Microsoft is doing with Windows and it's APIs.
I really don't understand why, from a technical standpoint, it isn't possible to simply create an environment for applications to run, that actually USE the DLLs from the Win32 API and the .NET runtime, right off the Windows CD. Rather than re-implement it, why not actually use THE reference architecture, and just get on with it.
I'm suggesting something along the lines of an application that could find all the files it needs on the Windows install CD, and pull them out, and place them somewhere sane in the host OS, which could then allow apps to call directly into the Windows DLLs, and either provide some kind of abstraction layer between the Windows DLLs and the hardware, or allow the DLLs to run in some type of sandbox that would grant them direct hardware access. This approach would be very fast as it could run directly on the new Intel hardware, and it would be a reliable implementation as it would be using the reference architecture that the apps were created for/with.
This is essentially what Apple did with the Carbon API, to allow 'classic' applications to run (in a slightly retooled fashion) directly in Mac OS X. It was a little slower due to the abstraction, but it was fine for most things. And it was MUCH faster than running something using the "Classic" virtual machine environment.
Now, admittedly, from a technical standpoint it may be doable, but I really have no idea how this would be accomplished. I, personally, wouldn't have a clue where to start.
Legally, I think there could be a number of pitfalls to this idea, and that is perhaps why it hasn't been attempted (to my knowledge). Apple would never be able to take this on. The open source community could probably take this on though.
Wil Shipley did a piece a while ago about how Darwine is the future for this stuff, attempting to incite young developers who feel like they have something to prove (*ahem!*) to get on board and help out. And I think I'm there. I would like to have a discussion about this with someone knowledgeable about all of this first though.
UPDATE: Some reading on the WINE site revealed to me that they CAN in fact use the Windows DLLs directly, though I haven't found the prescription for actually getting this done yet.
All of this ignores that fact that people don't buy Macs to run Windows programs, nor should they. It's a bonus for some people, but it won't make a difference to many users.
I for one wouldn't want Windows apps, with all their bizzare registry expectations, individual file management conventions, individual UI behaviour, completely path based file access, user permissions model, etc, etc, etc, to get in and bugger up my nice Mac OS X install.
Really I guess I've been thinking about how terrible the current solutions are.
I think I have a better solution but I have no idea how one would go about implementing it, or even if it would be legal. But I think it's doable, at any rate.
Right now there a few things going on in this space:
- Apple is obviously thinking about people who want to use Windows software on their Mac hardware. BootCamp, I think, is only one piece of Apple's game plan. Lots of people have been discussing Apple's possible moves in this regard, so I won't go through everything. Here's some pointers though: Cringely;Shute;Gartenberg;Daring Fireball-#1;Daring Fireball-#2;among many others.
- Parallels has released their products to allow virtualization, specifically aimed at Mac users that want to use Windows on their machine.
- There are other virtualization options, like QEmu and VirtualPC - maybe VMWare will get into the fray as well.
- Darwine has been gaining steam - attempting to utilize the Wine project's attempt to re-implement the entire Win32 API (in a portable way so that any OS can run applications that rely upon it), adding some Mac OS X specific stuff to make it look better and work better/more cleanly.
- Mono has also had some great advances over the past few years, attempting to re-implement the .NET runtime in a more portable way, so that any OS can run applications that rely upon it.
Apple's got a neat solution of providing a neat dynamic disk partition tool, and a fancy bootloader. Neat as in 'intersting', not neat as in "tidy". Anyone who really needs to use a Windows app will quickly tire of rebooting, and being stuck using a crappy FAT32 partition in order to share files between the two OSes (not to mention the indiosyncracies that have already been reported with respect to the partition tool and the bootloader). While it's probably a good move for Apple, it's probably not the best long term solution for users. Again, I think Apple's really just testing the water with this one, and it will be interesting to see exactly where they're willing to take this in the future, but for now we can file this away in the "good, but not quite right category".
Virtualization is also a pretty nifty solution, and I think there will always be a market for real machine virtualization technology - it's been employed by many an enterprise for years to do server virtualization, for example. (Beneficial, as when the VM goes down, but the hardware stays up, and can even safely restart VMs for you, plus it runs in its own address space like any other process, and can't mess other things on the machine up).
Still, for regular users who don't need to have virtual machines for this type of enterprise separation and protection, the idea of having Mac OS X, all your own apps, PLUS a full Windows install, PLUS whatever app you're running in windows, seems terribly inefficient to me. There is no need to have ALL of windows running, hogging disk space and memory and sweet sweet processor cycles and precious little video card resources. (PS, if you think XP is a hog in this regard, just wait till you see what Vista can do to a machine's resources). Not to mention that issue of dealing with partitioning hard drives, filesystems' respective pros and cons, space limitations, security, etc)
Which nicely brings us to Wine/Darwine, and Mono. This is also a neat idea - probably the best idea we've looked at yet - and I give both projects' founders and contributers the hugest props both for taking this on and for being unbelievably successful at it. This approach achieves much better performance than VM style stuff, allows for neat applications-sharing-resources stuff to work that couldn't possibly with the bootloader approach Apple has taken so far, and can probably overcome most of the ease-of-use stuff with a nifty installer and some diligence.
The problem I have with the re-implementors (Wine/Mono) is that they are re-implementing. They're redoing something that's already done. And this approach doesn't stand a chance at keeping up with what Microsoft is doing with Windows and it's APIs.
I really don't understand why, from a technical standpoint, it isn't possible to simply create an environment for applications to run, that actually USE the DLLs from the Win32 API and the .NET runtime, right off the Windows CD. Rather than re-implement it, why not actually use THE reference architecture, and just get on with it.
I'm suggesting something along the lines of an application that could find all the files it needs on the Windows install CD, and pull them out, and place them somewhere sane in the host OS, which could then allow apps to call directly into the Windows DLLs, and either provide some kind of abstraction layer between the Windows DLLs and the hardware, or allow the DLLs to run in some type of sandbox that would grant them direct hardware access. This approach would be very fast as it could run directly on the new Intel hardware, and it would be a reliable implementation as it would be using the reference architecture that the apps were created for/with.
This is essentially what Apple did with the Carbon API, to allow 'classic' applications to run (in a slightly retooled fashion) directly in Mac OS X. It was a little slower due to the abstraction, but it was fine for most things. And it was MUCH faster than running something using the "Classic" virtual machine environment.
Now, admittedly, from a technical standpoint it may be doable, but I really have no idea how this would be accomplished. I, personally, wouldn't have a clue where to start.
Legally, I think there could be a number of pitfalls to this idea, and that is perhaps why it hasn't been attempted (to my knowledge). Apple would never be able to take this on. The open source community could probably take this on though.
Wil Shipley did a piece a while ago about how Darwine is the future for this stuff, attempting to incite young developers who feel like they have something to prove (*ahem!*) to get on board and help out. And I think I'm there. I would like to have a discussion about this with someone knowledgeable about all of this first though.
UPDATE: Some reading on the WINE site revealed to me that they CAN in fact use the Windows DLLs directly, though I haven't found the prescription for actually getting this done yet.
All of this ignores that fact that people don't buy Macs to run Windows programs, nor should they. It's a bonus for some people, but it won't make a difference to many users.
I for one wouldn't want Windows apps, with all their bizzare registry expectations, individual file management conventions, individual UI behaviour, completely path based file access, user permissions model, etc, etc, etc, to get in and bugger up my nice Mac OS X install.
posted by JD @ 11:51 a.m.
0 Comments:
Post a Comment
<< Home