Run Windows Applications Natively in OS X?

mcho writes "Unlike other speculators, who get no spam, Robert X. Cringely offers an intriguing reason behind Apple's recent strategy of Boot Camp. From the article: 'I believe that Apple will offer Windows Vista as an option for those big customers who demand it, but I also believe that Apple will offer in OS X 10.5 the ability to run native Windows XP applications with no copy of XP installed on the machine at all. This will be accomplished not by using compatibility middleware like Wine, but rather by Apple implementing the Windows API directly in OS X 10.5.'

Comments

tap, tap, tap, .. there's no place like OS X...

[yagu]

He points out one of the difficulties WINE has had keeping applications healthy:

Wine is great, but it is also a moving target subject to Microsoft meddling. If Wine gets too good, Microsoft can "accidentally" break it at will. But Microsoft can't afford to do that with its own Windows API. The courts will no longer allow checking for a different underlying OS as Redmond did back in the days of DR-DOS. Besides, unless we are strictly talking about Microsoft apps, there isn't even much code involved here that Microsoft CAN meddle in.

I wonder that his assumption Microsoft can't break its own API in Windows is correct, and suspect (or fear) it isn't. Or, at best, writing to Microsoft's API is only a half truth and is at the core of one of the EU's complaints against Microsoft -- complete API documentation!

Cringely does confirm third party reports of this suite of software working at Apple, but I wonder for how long? And for what versions? A complete, robust, and current maintenance of what is available for a Windows API is a minefield, and in my opinion, likely to somehow "break" rather quickly.

I can imagine if Apple somehow has pulled this off and is ready to roll it out publicly they must be bracing for the Microsoft blitzkrieg, because they're going to get it.

As to whether or not this really is a realistic scenario (Microsoft and Windows Apps running transparently in OS X), please, please, please let it be true! (We can all hope, right?)

Re:tap, tap, tap, .. there's no place like OS X...

[jandrese]

The other thing I'd like to point out is that what he's proposing involves rewriting a massive portion of Windows itself, something Microsoft has spent decades working on. He expects Apples magical engineers to just whip out a feature complete copy of the Windows API in just a few months?

Re:tap, tap, tap, .. there's no place like OS X...

[Ohreally_factor]

You might have missed this bit in the article.

According to Cringely, Apple has had access to XP APIs under an tech sharing agreement between Apple and MS that was forged in 1997. (This was part of the agreement that let MS off the hook for appropriating quicktime technology into their own media products.)

Re:tap, tap, tap, .. there's no place like OS X...

[MCSEBear]

Running Windows programs on a Mac is already easy. Parallels makes a virtual machine that is winning praise while still in beta from publications like Businessweek and Computerworld. You can download it free while it's in beta, but the full retail version is only going to be fifty bucks. Definitely much more affordable than Connectix/Microsoft's VirtualPC. Since it takes advantage of Intel's Virtualization Technology, you can run your favorite 'other OS' inside MacOSX and not be grey before that other OS boots.

I doubt Apple is going to bother trying to reinvent Wine inside it's OS. There has been a plan to make a foreign set of API's a new part of an OS for many years, however.

Back in the days after Steve Job's Next bought Apple for -$400 million dollars, there was talk of Cocoa based programs running on top of Windows. Apple called this idea Yellow Box for Windows. Rumors have been spreading that Yellow Box for Windows is being discussed again.

"Apple's emphasis in the 10.5 era will be on resurrecting 'Yellow Box for Windows,' a set of Cocoa (and potentially also Carbon) API's for Windows that would allow Universal Binary applications to run on Windows with a mere 150MB software package installation. And best of all, there is no extra work to be done on the developer's part to get fully native, rock-solid stable performance from their Xcode-developed Universal applications on Windows!"

What is Cocoa?
What is Carbon?

Re:What's the incentive to write a program for OS

[unk1911]

This would be great, it will enable Apple users to play on websites such as WorldWinner.com, to compete for cash prizes. There's so much software (even web-based software) written out there that only supports Windows/ActiveX/etc, that something like this would really be helpful.

--
ahref=http://unk1911.blogspot.com/rel=url2html-926 9http://unk1911.blogspot.com/>

It's a nice idea...

[AKAImBatman]

...but it isn't going to happen. BootCamp is about advertising. Macs are generally known as Really Nice Hardware(TM). As a result, some people will buy Macs just to install Windows. They may even think, "Hey, I can even try out this Mac OS X thing so that I can *really* make fun of my Mac-lover friends!" Then the users purchase a Mac, try OS X, realize they don't actually NEED Windows, and never use BootCamp at all.

It's a stroke of genius, actually.

Something like that...

[a_nonamiss]

... would certaily push a lot of users like me over the edge to the Macintosh camp. If only I had bought that Apple stock 10 years ago...

Classic but for Windows.

[anlprb]

I bet it will be a classic like environment, but for windows. Once the data is on the HDD, it is trivial to start up a virtual machine and fool the win partition into thinking that it is booting natively. That is much more likely. That would be the final "Integrated" solution for running windows apps. They proved it could be done workably with OS 9. Now, they just have a separate partition to boot. But this again, is from another whack job on the innerwebinator thingie.

Could it be...

[MustardMan]

Could cringely be saying something that actually makes a bit of sense? I have no doubt that WINE will eventually be at least as good on os x as it is on linux today, which is not too shabby. Apple have shown with boot camp that, if the hackers get it working and people are excited about it, Apple is willing to release a more elegant solution to accomplish the same goals. With the mach microkernel setup they've got going now, it's not too hard to imagine a windows compatibility layer that could run tandem to the BSD layer they already use. IMO, this one is at least a possibility. I wouldn't say Apple is neccesarily planning to do this right now, but if people start getting really exited when darwine starts getting good, I wouldn't be suprised to see the ole man in the turtleneck upstaging them by releasing an Apple sanctioned implementation.

Really the most shocking part of this whole article is the fact the Cringely said something that actually kinda makes sense. I guess a stopped clock really can be right once in a while.

Re:Uhhh... hello.

[Anonymous Coward]

1) I thought the article said/implied that Apple had "better documentation" of the API from the time of their collaboration with MS.

2) I would think it QUITE interesting if Linux binaries (at least non-3D graphics ones) could be run natively under OS X. Does anybody have any idea whether this is being done?

I would think it straightforward - substitute .so's that call OSX routines when given Posix calls, etc.

Maybe

[99BottlesOfBeerInMyF]

...I also believe that Apple will offer in OS X 10.5 the ability to run native Windows XP applications with no copy of XP installed on the machine at all. This will be accomplished not by using compatibility middleware like Wine, but rather by Apple implementing the Windows API directly in OS X 10.5.

First, there is more than one API used in Windows. Second, WINE is an implementation of the Windows APIs. It is entirely possible Apple will reuse a lot of the WINE project and DarWINE in order to allow Windows Apps to run in OS X (hopefully sandboxed), but it is also entirely possible they won't. I rather suspect the latter for a number of reasons. First, Apple doesn't have to do this, there are a half dozen third parties clamoring to offer the same functionality. Second, by making it too easy to run Windows programs within OS X, they can reduce the incentive for developers to write programs to the current APIs. Third, since Windows is slowly strangling OpenGL on their platform and MS owns DirectX, Apple may have difficulty keeping graphics intensive applications behaving well if they go this route. Fourth, Windows APIs do not have all the functionality of OS X APIs and some of the most useful and advantageous features of OS X would be killed.

Only time will tell for sure.

Re:What's the incentive to write a program for OS

[non0score]

By your reasoning, then why bother writing OSX programs in the first place? The point is that people write programs for OSX because they want to, not because they're somehow stuck with a Mac and can't write something for the PC. This is giving people who use program Y that was never "ported" to the Mac platform (and thus can't switch over) a reason to switch over. Of course, this is also giving a lot of convenience to long-time Mac users who just can't seem to get any games.

Now, only if I can plug in any PCIE gfx card and be able to get the OSX drivers for them, I'll be all set....

Virtualization, Not This

[American AC in Paris]

I'd be a lot less surprised to see good, solid virtualization. Give users a high-speed sandbox where they can run Windows and Windows apps and they won't care whether or not the apps are integrated into the OS. Most users don't do much direct application-to-application integration in Windows, anyhow--generally, you're saving files to the disk, then importing or converting them in another app. Virtualization works quite well with this sort of thing.

Frankly, it's probably better not to go down Cringley's road, since Microsoft's flavor of application design and integration is so very, very different from the OS X model; running Windows Word "native" in OS X would be a constant headache for users used to the drag-and-drop-just-works world of Apple's flagship apps...

Windows in a VM

[Nate Fox]

Why bootcamp when you can run in a VM (aside from games)? Anandtech has a nice review of the macbook, and running windows in a window, as well as dual booting. Seems performance is quite good, even with the beta!

What's the incentive to write a program for OS X

[tourvil]

If it can just run X11 apps anyway?

The answer? Because X11 apps (and likely Windows apps, if they did implement Windows compatibility) look and behave like crap next to Cocoa and Carbon apps. They don't use the menu bar, all the shortcuts use control instead of the command key, etc. There's nothing wrong with those on an X11 system, but switching back and forth between Cocoa and X11 apps can be jarring.

I doubt Windows compatibility would cause existing Mac developers to drop support. And who knows, Windows-only developers might start considering a Mac port more seriously if a significant portion of their user base started running their apps on a Mac.

Re:What's the incentive to write a program for OS

[The Snowman]

Ideally this would be in a sandbox, similar to a virtual machine. That way all you have to do is kill the VM, and all that crud is gone. Since it's a VM, you can easily make backup copies of the file system -- similar to a restore partition on OEM machines. Set it up the way you want, and when ActiveX rips a hole in Windows or malware slows it to a crawl, it's easy. Kill the VM process, copy the backup partition over.

Of course some of us can run Windows without malware, viruses, and all that stereotypical garbage. Some of us do have a clue how to administer a Windows computer. I've worked with many operating systems -- DOS, DOS/Windows, Windows NT, Linux, FreeBSD, Solaris, HPUX, and even little Vax. In my experience, none are easier or more difficult to secure with the exception of DOS or DOS-based Windows (96/98/ME), which suck. All it takes is a little training on the security issues and the ability to be proactive with security.

did you forgot darwine??

[evandrofisico]

there have been a lot of work on that!!! It's called http://darwine.opendarwin.org/ and it's not yet stable...

That would actually be the major reason not to

[Sycraft-fu]

IBM had that problem with OS/2. It ran Windows apps just fine, there were very few that didn't work jsut as intended... Which lead to nobody making native OS/2 apps. I mean if you can write it once and it'll run on both OSes, why bother with a port? Sure it would work BETTER if it was a native app, but it worked well enough.

I think Apple would face a similar problem. Not all apps would stop porting, of course, apps that have a healthy market like Photoshop would keep porting, but I think many would. You'd never see another game port, and any app that wasn't really core-market kind of app for Apple would likely stop porting. You have to figure you aren't really going to lose any sales since it does run, and there are few people using it in the first place, so why bother?

Now maybe Apple decides they don't care. Maybe they want to implement the Windows APIs and just use those. Maybe they figure the other features of the OS are enough to keep epopel buying. However I gaurentee they are smart enough to know that if they implement the Windows API natively in OS-X, that most apps will just use that and not bother to port.

Re:That would actually be the major reason not to

[Sycraft-fu]

The reason OS/2 failed because of Win API support was because it chained them to a no-win cycle. They HAD to continue to support the Win API because there were almost no native apps. However supporting it was a bitch both in terms of time spent on implementation and in terms of design concessions. They finally decided to stop with Win32 and OS/2 dies shortly thereafter.

At this point, Apple has people porting to OS-X. Not a ton, but enough. If they add Win32 support, I think the number porting will fall significantly. The problem is they then become chained to the MS API. If MS releases a changed API, they have to scramble to implement it as well.

It also means that bugs and such come over. Thought your computer was protected against spyware? Sorry, no longer, it can execute Windows programs, and they don't bother to set the Evil Bit to allow you to ignore them, You get the good with the bad.

I think that would take away a major percieved advantage Macs have. The one thing that more people who claim to want to switch, or actually do switch, bitch about than any other in my experience is spyware and viruses. They see them as MS's fault and want them ot stop. They've been promised the Mac does not have those, which is true at this point.

Well, if all of a sudden all the Windows malware runs on a Mac, you are back to where you started. It is again incumbent on the user not to do stupid stuff, rather than having a protection because the bad code just won't execute.

CarbTime

[tepples]

Hell, make XCode a cross-compiler that builds Win32 apps from Win32 and Cocoa projects and give it away for free

Hades, the Windows version of QuickTime already implements 2/3 of Carbon itself.

Re:WINE is an OS component

[Qzukk]

WINE becomes an OS component as soon as one Linux distro vendor bundles WINE

So apache an OS component, because all of the distribution vendors bundle it with linux?

Does that mean AOL is a component of windows, because dell bundles a 6 month trial on most of their machines?

Re:What's the incentive to write a program for OS

[mycall]

Have you ever looked at Win32? menus are just messages and handles passed around, like WM_SYSCOMMAND, WM_MENUCOMMAND or special functions like AppendMenu() or MenuItemFromPoint(). I would think it would be easy to recreate OSX's menuing behavor even with native Win32 apps.

Re:As usual....

[confused one]

1) There is no way in hell Microsoft would document their API to the level necessary to allow Apple to duplicate it.

The API is documented -- how do you think programmers write apps that work in the OS. There are undocumented portions; but, as Cringley points out, Apple has had access to the full API via cross licensing since 1997.

2) It's blatantly obvious he doesn't understand precisely what Wine is. Remember: Wine Is Not an Emulator. It's a built-from-scratch implementation of the Windows API.

Your partially right... Wine is not an emulator. It's also sadly incomplete. Still beta 0.9.xx I believe. Without access and support it is never going to be complete because Microsoft keeps portions of the API a moving target; and, buries portions.

His idea actually has merit if you think about it; Microsoft might actually support such a move. They could drop support of the Apple specific version of Office, lowering development cost. They could increase sales of Office, Exchange, etc. And they could re-coup lost Windows revenue through licensing fees paid by Apple for continued access to the API and development support.

How this would work

[joshv]

I doubt Jobs is looking to support running every Win32 binary under the sun - for that you can dual boot. If something like what Cringely describes were to take place, OS X would implement only a subset of the win32 API, but with graphical widgets having an OS X look and feel and perhaps some win32'ish extensions that provide access to OS X specific functionality (spotlight, etc...) This 'subset' API would be different enough that there would be very little likelihood that an unmodified binary would run out of the box on top of this compatibility layer.

But with a recompile and some refactoring, I bet most windows programs could run quite will under this compatibity layer. What those would do is open up the Mac platform as a viable target for Windows software developers. Recompile under OS X, fix the few quirks, or work around the APIs that aren't present, and bingo, you've got a mac app. With a few IFDEFs you might even be able to support both Mac and Windows versions with the same code base. Software makers like Quicken might find this a very attractive option.

Re:Wine vs Windows API

[IntlHarvester]

I think it's true. Look at OS/2 v2/3 -- The icons were so fugly that even I could make better ones in MSPaint, and the fonts were big chunky and blocky.

Also, OS/2 came with a "power user" desktop that relied heavily on nested folders, drag-n-drop, right-drag-n-drop, "templates", and property windows. This was in an era when most PC users hadn't even touched a mouse. Confusing+Ugly=Problem.

Most of this was fixed with OS/2 v4 that copied the "Start Menu" idea and had some graphical treatment. But that came out in 1996 (8 years after the original OS/2 GUI), and was too-little, too-late.

My favourite parts

[Sentry21]

Quite simply, a monolithic kernel like the one used in Linux or most of the other Open Source Unix clones is inherently two to three times faster for integer calculations than the Mach microkernel presently used in OS X 10.4. ... Apple has evidently reached the point where they need to trade claimed performance, -- typically based on floating-point operations that aren't a part of much web or database service -- for real performance.

In this amusing quote, Cringely is asserting that the mostly-microkernel architecture of Xnu is responsible for poor integer performance, which wrecks web/db performance, but does fine with floating-point operations. Makes sense to me!

Speeding-up performance is great, but normally a system vendor won't want to do that for older hardware, which might encourage some users to keep their old box and just add a new OS. But in this case, Apple HAS NO installed base of Intel Macs to worry about having to compete with, so speeding up the OS becomes a no-brainer, especially if it simultaneously encourages PowerPC owners to upgrade so they can share in the fun.

Apple already does make their OS releases faster from one to another - I don't know about other Apple policies, but the WebKit team, for example has a strict 'no performance regressions' policy which is enforced pretty well. It wouldn't surprise me to find the same is true of the rest of the OS and components. Asserting that Apple is so intent on selling new hardware that they would intentionally ignore potential performance improvements is ludicrous to say the least.

re-writing the Windows API, eh?

[Anonymous Coward]

Apple reimplementing Windows API? That is too much work and very unlikely!

Here's what I think will happen:

Step 1: Develop a way to run Windows on a Mac in its own partition. Done. (via Bootcamp)

Step 2: Develop a way for OS X to "talk" to Windows machines (or virtual machines) efficiently. Done. (Apple just released Bonjour for Windows a few days ago)

Step 3: Virtualize and run Windows inside OS X with full drag and drop capabilities (via Bonjour), running at native (since Apple has all the tech specs on the hardware) speeds in its own partition (Bootcamp).

My fearless forecast? WWDC, Steve will announce this.

Re:What's the incentive to write a program for OS

[bsartist]

More importantly, if they could carry over their non-UI logic with just a recompile via some sort of Carbon-style XCode project mechanism (that would import, say, VC and VC++ projects) and then redo the UI via the Interface Builder (but be able to access NIB data via Win32 widget calls) then the barrier to porting to OS X would pretty much go away.

You can do most of that right now, if your model classes (assuming MVC design) are in C++. Just use controllers written in Objective-C++ to talk to your C++ models and Objective-C views. The only thing missing from what you're describing is importing VC projects, but that's just an inconvenience, not a show-stopper - it's not exactly rocket surgery to create a new project and add your model files to it.

Codeweavers will be out soon

[Danathar]

I had an apple rep show me a beta of Codeweavers Crossover Office working with OS X in a demo 3 weeks ago (Alpha version).

It does not need to run 100% of apps to REALLY be a hit. If the majority of vanilla apps run with little or no issues then I know of MANY People who would dump windows.

What if Apple bought codeweavers? With the Windows API in hand they could probably take their modified codebase and get it running even better than it is now.

Apple will do what is right for Apple

[gone.fishing]

I am not an Apple fan, I have never used an Apple computer but I have come to admire Apple for it's business savy. How many times has it been down for the count only to come back better, stronger, and smarter? I've lost count.

I don't know what Apple will do. I do not know any insiders and unlike Cringly, I do not have some sort of mystic ability to look into a crystal ball and predict the future.

What I do know is that Apple is currently operating from a position of financial strength, they are making quality products that have captured the public's imagination and, they have a great deal of real marketing talent on their side. At various times in their history, you could have said that Apple lacked focus but I don't think we can say that today -- I think they have a plan and are following it. I do not know what it is but I suspect that it is the right one for Apple.

Is Boot Camp a sign of something to come? I don't know and neither does anyone outside of the inside circle at Apple. Maybe it is a flag they are waving at Microsoft, telling them "Yea, we can run your O/S too" or maybe they just thought that they had to float it out there before hobbiests did something that Apple would find harder to control? Maybe by showing the public that they can run Windows, they can manipulate Microsoft into giving them a very attractive license agreement?

In the end, Apple will do what they know is the right thing for their product(s) and their plans for the future. That is what has always worked for them before. They know what they are doing. They are bright and savy technobusinessmen (hey, did I just invent a word?).

Re:Porting Windows API not that easy

[WhiteWolf666]

Yeah, but ....

Wine already works with many XP apps. Mono is can do some interesting things, as well, in terms of usage in combination with Wine.

Wine + Apple's pockets? And maybe IBM's pockets?

Booyah. Not to mention that the Wine project is getting pretty dang close to Win32. DirectX included.

MS can't make Win32 too much of a moving target, or they'll have to EOL XP. And they can't really make the API's too sophisticated, because then they'll turn off developers. The biggest problem the Wine project really has is lack of man hours, not lack of knowledge. $$ can buy man hours, and corporations with programmers familiar with Win32's internals can provide man hours in bulk.