Linked by Thom Holwerda on Wed 18th May 2011 21:50 UTC, submitted by fran
Windows The ARM version of Windows 8 might have just become the most desired version of Windows in our hearts and minds. After us talking about legacy code and backwards compatibility in Windows for years now, an Intel senior vice president, Renee James, has just stated that Windows 8 on ARM will not have any form of compatibility for legacy applications whatsoever. Update: Microsoft has responded to Intel's claims. "Intel's statements during yesterday's Intel Investor Meeting about Microsoft's plans for the next version of Windows were factually inaccurate and unfortunately misleading," the company said, "From the first demonstrations of Windows on SoC, we have been clear about our goals and have emphasized that we are at the technology demonstration stage. As such, we have no further details or information at this time."
Thread beginning with comment 473702
To view parent comment, click here.
To read all comments associated with this story, please click here.
henderson101
Member since:
2006-05-30

If I understand it correctly it will be similar to the OSX switch.


Given what you say below, you don't understand the OS9 to OS X Switch, so I'm doubtful...

OS9 Apps did not run on OSX.


Wrong. There were two ways in which OS9 apps ran on OS X:

1) Carbon. A Carbon app was built with a subset of the "Classic" Mac OS API (called, um, Carbon or Carbonlib if you are pedantic) and was compatible with *both* OS9 *and* OS X. The same exe. No "fat" involved. In OS9 it ran in a slightly more restricted way (like, no protection and co-operative multitasking.)

2) "Classic" which was based on the earlier BlueBox technologoy found in Rhapsody. Mac OS9.x ran in a VM as a process and the apps ran in that VM instance fullscreen in a way that appeared enough like OS X to make it feel sort of "okay".

There were some carbon (fatt)


There were no such apps. A FAT app is from an even earlier transition. Fat Apps were apps with both 68000 and PowerPC code forks. They came about when Apple transitioned to PowerPC in the early 1990's. They are nothing to do with Carbon. Carbon was a common subsystem that ran the same PEF (Portable Executable Format - the standard PowerPC exe format used for Mac OS classic apps, aka CFM with IIRC stands for "Code Fragment Manager") executables on both Mac Classic OS 8.6 and up (with varying degrees of success with the earlier versions of Carbonlib) and Mac OS X up till 10.5 on PowerPC (and I guess on Intel through Rosetta.)

apps that were compiled to run on both but these tended to not be able to take advantage of functionality a native (cocoa) application could in OSX. CoreAudio for example.


Yes and no. Carbon apps were not meant to dip outside of their sandbox without verifying the API existed. I also seem to recall that if you compile a Carbon app that uses the OS X API I think you will end up with a non PEF/CFM exe (as all OS X native Cocoa apps and "libs" (frameworks) are in Mach-o format), and that won't run on OS9 anyway. This bit I'm a little hazy on.

Reply Parent Score: 4