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.'
He points out one of the difficulties WINE has had keeping applications healthy:
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?)
Wow, Cringely obviously has a clue.
"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."
Wine *is* an implementation of the Windows API.
Cringeworthy is more like it
Cringely is out of his mind.
1) There is no way in hell Microsoft would document their API to the level necessary to allow Apple to duplicate it.
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.
Idiot.
Damn, I whish I could mod this story +5, Funny
The Wine guys worked a decade on cloning the Windows API, and there are still more than enough problems. There is no way Apple can do this. Maybe for specific applications, but implementing Win32 with all the required libraries on top? Never.
...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.
Javascript + Nintendo DSi = DSiCade
Cringely and Dvorak must be making humongous ad-revenue trolling Mac Fans lately. They're eating it up!
It's understandable because Apple has made some radical moves lately (Intel, Windows), so the Mac Zealot's universe must seem like it's in total flux. No longer can they confidently predict Apple's next move using their supposed expertise in everything-apple. If Apple will put Windows on Macs, pretty much anything goes!
Obviously these columnists sense the uncertainly and are having fun stirring things up a bit. Anyway, before you fire off your 1000 word point-by-point response denouncing Cringely, keep in mind he probably wrote this column in 15 minutes while high on cough medicine.
Whenever I hear the word 'Innovation', I reach for my pistol.
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.
One Token Ring to Rule them All, One Search Engine to Find Them, One WAN to bring them in, and TCP/IP Bind them...
Cool! All of the spyware and viruses can run in OS X too. That would be great.
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....
Because Mac users will treat any Windows apps running on OS X like second class citizens. They'll stomach it, but not for long.
People credit Apple for how apps are consistently Mac-like and interoperate with each other, but the users are the ultimate enforcers. Any developer who steps out of line is crucified.
I can not wait to run Bonzai Buddy, not to mention all the _GREAT_ screen savers that are available for download (for free!) off the web!
yea!
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.
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.
24 beers in a case, 24 hours in a day. Coincidence? I think not!
there have been a lot of work on that!!! It's called http://darwine.opendarwin.org/ and it's not yet stable...
...because Apple might just have their own implementation of a Windows API ready to go before Vista actually ever ships.
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.
There have been at least three projects that I know of (Wine, OS/2 Warp 4, and ReactOS) that have tried to do implementations of the Win32 API. OS/2s implementation never truly got off the ground (and was neither able to run native Win32 code, nor was it even reasonably complete). Wine and ReactOS have both been fighting a Sisyphean battle with Microsoft throughout the life of their projects.
Then, you need to add in the fact that Apple has historically been very jealous of their user experience. I don't expect that Apple would ever release something like this unless and until it was impossible to distinguish a Win32 application from a native app.
Don't get me wrong: I'd love to see it (it would provide justification that I could use on the spouse for upgrading our G4 MiniMac). I just think that Cringely needs to put down crack pipe and slowly back away.
Karma: Chameleon - mostly influenced by bad '80s New Wave music
WHat we need is a multi-billion dollar organization with knowledge of the Windows API and developers on staff...oh. wait.
The Kruger Dunning explains most post on
Sounds like Cringely has been sleeping with Dvorak too long. You know how when couples are with each other for a long time they begin to sound and act like each other...
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?
If I have been able to see further than others, it is because I bought a pair of binoculars.
A lot of comment so far correctly point out that WINE is is an implementation of the Windows API, but they miss Cringely's point that Apple licensed the Windows API. The whole shebang. So unlike the WINE development team, OSX-XP project team doesn't have to reverse engineer undocumented and cryptic API's. Anyone who remembers IBM's OS2 knows that IBM licensed the Windows API, and included it into OS2, and could run all Windows programs. OS2 failed because of lack of consumer appeal (eye-candy), not because of lack of compatibility.
I imagine Apple could pull a better OS2 than IBM. Security, stability plus consumer appeal plus Windows compatibility.
Even if all this is speculation, it probably gives Messrs Dell and Gates nightmares.
In Soviet Russia, articles before post read *you*!
Microsoft has an ongoing issue with the EU where Microsoft is unable (unwilling) to produce documentation on their APIs to a standard that anyone can sensibly write code that interfaces with it. If the state of affairs are as shoddy as Microsoft gives the impression of, even Steve Jobs's RDS cannot reliably help Apple engineers re-implement the full Windows API.
The EU is treathening to fine Microsoft $2,7 mill a day for the inability to produce said documentation.
The future is in beta
- Switch browsers from IE to Firefox
- Switch Operating Systems from Windows to Mac
- Switch Preferences from Women to Men
That leaves you in one of the smallest possible target audiences for... well... just about anythingI 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.
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.
Lost: Sig, white with black letters. No collar. Reward if found!
Back when QuickTime for Windows was first introduced, Apple found that it was less effort to port the subset of the Mac Toolbox that QT depends on, than it would be to port QT to the Win32 API. That "subset" was so large that they had to actively discourage developers from using it as a porting tool to get their non-QT apps running on Windows.
Fast-forward some years. When Apple needed an updated and portable version of the classic Toolbox, they started with the portable Toolbox subset that they'd already ported to Windows to support QT.
Lost: Sig, white with black letters. No collar. Reward if found!
- Windows 3.0 - compatible with MSDOS (earlier versions had some compatability too but it wasn't as solid
- Windows 95 - compatible with Windows 3.x and DOS
- Windows XP - compatible with Windows 95, 3.x, and DOS
- Mac OS X - compatible with Mac OS 9. Also able to run many X11/Unix apps with just a recompile
Other people can probably come up with other examples of operating systems that, in their time, were successful, and had substantial back-compatibility with platforms that you generally wanted to obsolete, not support.Anyone thinking "Hey, Windows is Windows right?" should note that Windows 3.x and Windows 95 couldn't have had more different looks and feels, and their APIs were only superficially similar. Win32, 95's base API, was 32-bit, worked with flat, 32 bit, addressing, and provided access to something resembling a sane file system. "Win16", the pseudonym of the Windows 1/2/3.x APIs, by comparison required programs be written to use segmented memory. Filenames were UPPERCASE and had eight characters, a period, and three more after that. The GUIs were marginally similar in terms of widget layout, indeed a Win16 application was grating when you saw it up against native 32 bit applications.
The real question is: Is Apple prepared to get this operating system out to the mass market, should they consider including Red Box in Leopard? If they don't, then with a 3-5% marketshare, there's a serious risk that programmers will rely upon Red Box to get their critical, we're-the-only-people-who-do-this, applications to OS X users, and not care too much about complaints from Mac OS X users about the ugliness of the GUIs. Native Mac programs will still exist, especially if Apple re-releases an updated version of their OpenStep/WebObjects for Windows development tools, incorporating the software into Xcode. But they'll remain the minority, and the divide between Mac apps and Windows apps will, if anything intensify.
You are not alone. This is not normal. None of this is normal.
That would suck. Apple has pretty good interface guidlines. "Preferences" is 3rd option in App menu. It's not Tools->Prefs, View->Options, File->Properties, View->Customize, Edit->Configuration, etc.
DarWINE is fine, but I don't want Windows app and their (un)usability officialy made "native" for OS X.
The big thing about Crossover office is....Office. Apple already has office for OS X. Look at the supported apps page http://www.codeweavers.com/products/cxoffice/suppo rted_apps/ 50 whole apps are supported. Many of them only work partially. You know what? Most of those already have versions for OS X that work 100%. Photoshop. itunes, Quicken, Notes, etc the list goes on. Maybe there is some special win32 only app that would really help if it was ported to OS X, but going by that list I just don't see it.
.005% of Windows apps. In fact they are falling behind. How does that possibly help Apple? It doesn't.
Here is the deal, codeweavers have been working their asses off to get win32 apps to run on linux. Thus far they have barely scratched the surface and can only run like
The only thing Codeweavers brings to the table for Apple is possibly the ability to help devs port apps to OS X X86. My guess is that if most vendors are not making their apps available on OS X it sure as hell isn't due to difficulty in porting but rather has more to do with the limited ROI of making apps for OS X in the firstplace.
If you wanna get rich, you know that payback is a bitch