Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Cross-Platform Universal Emulation?
- Thread starter MacRumors
- Start date
- Sort by reaction score
GeeYouEye said:
From a propagation standpoint, this is bad - from a local damage standpoint, the viruses may or may not be written to access the OS X system properly (e.g. a virus trying to write to c:\ won't have any effect on a Mac).
I'm also rather skeptical of this, if only because it's been promised so often in the past. The PowerPC consortium and Transmeta promised dynamically reconfigurable processor architecture, and dealing with hardware put them in a much better position to actually accomplish it.
By now (actually, by ten years ago) we weren't supposed to care which platform a piece of software was written for, because they would all run on the same chip with veritably native speed. But of course we never saw anything significant come of it.
I've come to suspect it's a pipe dream, which is why, like so many others here, I'm skeptical about any claim that a piece of software can accomplish this in a way that's faster than VPC-style emulation. It seems unlikely.
Put me in the "believe it when I see it" corner.
By now (actually, by ten years ago) we weren't supposed to care which platform a piece of software was written for, because they would all run on the same chip with veritably native speed. But of course we never saw anything significant come of it.
I've come to suspect it's a pipe dream, which is why, like so many others here, I'm skeptical about any claim that a piece of software can accomplish this in a way that's faster than VPC-style emulation. It seems unlikely.
Put me in the "believe it when I see it" corner.
[voice of grisled old gold miner] "I SEEN with my own eyes i tells'ya! Mac software running on Linux boxes, PC software on Macs, it was the Lost City of Code!! i drew me a schematic to where the encrypted treasure lies. it's two leagues due south of Null Set Gulch, lying under the shadow of Vaporware Peak..."
... and they called it OS X 10.4/XP.
I am going to go out on a limb here and say that Apple is one of the 6 companies in line. My prediction is that they will incorperate it into OS X, so that they never have to worry about Microsoft's commitment to the platform ever again -- I bet the boys over at the MacBU are soiling themselves at this very moment.
If this "hardware virtualisation" software is all its's cracked up to be, and they use it in Tiger, it would be the ultimate switch incentive to beleagered businesses who feel they are too heavily invested in software for an insecure windows environment. Of course other *nixes would benefit as well.
My copy of VPC is about to get KNOCKED THE #@!% OUT!
I am going to go out on a limb here and say that Apple is one of the 6 companies in line. My prediction is that they will incorperate it into OS X, so that they never have to worry about Microsoft's commitment to the platform ever again -- I bet the boys over at the MacBU are soiling themselves at this very moment.
If this "hardware virtualisation" software is all its's cracked up to be, and they use it in Tiger, it would be the ultimate switch incentive to beleagered businesses who feel they are too heavily invested in software for an insecure windows environment. Of course other *nixes would benefit as well.
My copy of VPC is about to get KNOCKED THE #@!% OUT!
A bit surprised this news is traveling everywhere so quickly.
But, I won't believe it till I see it. And I doubt I'll ever see it. I remember similar attempts like this where nothing ever got done.
However, the difference among the other tries and this one is, Transitive claims it has a product and a product that computer manufacturers will use!
I'm inclined to believe it. 80% computational performance is surprising.
Question is, how well will it do? I see one of two things happening if this is real: A) Apple can say good-bye. Buy a Wintel machine and run anything and everything. B) Apple can say hello. Buy a Mac machine and run anything and everything in a safe OS, but for a price.
Considering most PC users I know of are afraid of change, I think Apple will be the one to say good-bye. I only know of one person that's a hardcore gamer, but willing to switch if Macs could run all of the games well. However, this isn't a gaming rig issue. It may be more about price and quality than anything.
If this really exists, it will change the computer as we know it. I'm afraid.
But, I won't believe it till I see it. And I doubt I'll ever see it. I remember similar attempts like this where nothing ever got done.
However, the difference among the other tries and this one is, Transitive claims it has a product and a product that computer manufacturers will use!
I'm inclined to believe it. 80% computational performance is surprising.Question is, how well will it do? I see one of two things happening if this is real: A) Apple can say good-bye. Buy a Wintel machine and run anything and everything. B) Apple can say hello. Buy a Mac machine and run anything and everything in a safe OS, but for a price.
Considering most PC users I know of are afraid of change, I think Apple will be the one to say good-bye. I only know of one person that's a hardcore gamer, but willing to switch if Macs could run all of the games well. However, this isn't a gaming rig issue. It may be more about price and quality than anything.
If this really exists, it will change the computer as we know it. I'm afraid.
Hey egor,
I took a quick look at their site and this is my take on it.
For comparison we can look at VPC. It is slow as molasses in January. Why? Because the App you want to run (ie: MS Project) is running on Windows which in turn is running on another App (VPC), which in turn is running on another OS (OS 9 or X).
App>OS>App>OS>Hardware = SLOW.
What it seems like they have done is code to the standard set of APIs on the application side. On the Hardware side they coded right down to the PowerPC (or whatever given platform).
App>Hardware Virtualisation?OS>Hardware = NOT SO SLOW.
They have removed software layers added video support and moved the App as close to the hardware as they can. I can see a substantial increase there, but 80% is probably a theoretical max you would probably average around 60%.
Does anyone else have a different take on this?
I took a quick look at their site and this is my take on it.
For comparison we can look at VPC. It is slow as molasses in January. Why? Because the App you want to run (ie: MS Project) is running on Windows which in turn is running on another App (VPC), which in turn is running on another OS (OS 9 or X).
App>OS>App>OS>Hardware = SLOW.
What it seems like they have done is code to the standard set of APIs on the application side. On the Hardware side they coded right down to the PowerPC (or whatever given platform).
App>Hardware Virtualisation?OS>Hardware = NOT SO SLOW.
They have removed software layers added video support and moved the App as close to the hardware as they can. I can see a substantial increase there, but 80% is probably a theoretical max you would probably average around 60%.
Does anyone else have a different take on this?
It appears to be a JIT (just-in time) compiler that translates a supported platform's machine language to the host's machine language. This isn't the first emulator to use this approach (Java has done this for years, and I think MacOS's 68K emulator also does this), but this does appear to be the first that tries to combine multiple platforms and operating systems into one package.
Translating x86 to PPC (or whatever other translations it may support) isn't the big deal. The big deal is recognizing each operating system's system-call format so that OS API calls can be mapped and translated correctly. Tricky, but not impossible.
Supporting apps that use DLLs (shared libraries, dylibs, etc.) can be a particularly interesting challenge, because you have to dynamically load-and-translate new code while the app is running.
File system issues can be particularly nasty - MacOS and Linux have no concept of drive letters, for example.
If an app launches another process, it can really become fun. What happens if my Mac is running a Linux desktop utility that can launch Windows apps and Mac apps? And how do these processes inherit each others' file/network handles?
Another interesting question is one of the GUI - how do you define what is "correct". If I launch a Windows app on my Mac, should it have Windows-like window controls or Mac-like controls? Some users will complain either way.
I will be particularly interested if/when this becomes a real product and not just a demo and press release. If done well, it will give VPC a run for its money.
It will also be interesting to see if Microsoft and/or Apple sue them. You probably need to reverse engineer at least some of each system's APIs in order for the translator to recognize and replace the calls. This, at the very least, violates the shrink-wrap licenses (which are binding in MD and VA) and may violate some other intellectual property laws. If you don't, then you have to emulate the hardware and actually run the OS - what VPC does - which is a more difficult challenge.
Translating x86 to PPC (or whatever other translations it may support) isn't the big deal. The big deal is recognizing each operating system's system-call format so that OS API calls can be mapped and translated correctly. Tricky, but not impossible.
Supporting apps that use DLLs (shared libraries, dylibs, etc.) can be a particularly interesting challenge, because you have to dynamically load-and-translate new code while the app is running.
File system issues can be particularly nasty - MacOS and Linux have no concept of drive letters, for example.
If an app launches another process, it can really become fun. What happens if my Mac is running a Linux desktop utility that can launch Windows apps and Mac apps? And how do these processes inherit each others' file/network handles?
Another interesting question is one of the GUI - how do you define what is "correct". If I launch a Windows app on my Mac, should it have Windows-like window controls or Mac-like controls? Some users will complain either way.
I will be particularly interested if/when this becomes a real product and not just a demo and press release. If done well, it will give VPC a run for its money.
It will also be interesting to see if Microsoft and/or Apple sue them. You probably need to reverse engineer at least some of each system's APIs in order for the translator to recognize and replace the calls. This, at the very least, violates the shrink-wrap licenses (which are binding in MD and VA) and may violate some other intellectual property laws. If you don't, then you have to emulate the hardware and actually run the OS - what VPC does - which is a more difficult challenge.
To emulate the published APIs, all they need are the reference manuals. If their emulator can detect calls to each and every API and map them through to native code, then any well-written application should work fine.egor said:
Poorly-written apps that make use of undocumented API calls (which Microsoft's apps all do, even though they explicitly tell other developers not to) will be more difficult. They'll have to figure out what these APIs are in order to intercept and emulate them - some they can get from the internet, but some will require manual reverse-engineering. And MS can change them at any time, making matters worse (they don't have to worry about breaking Office, because they can simply include an Office patch with the system update or bundle the system update with an Office update.)
Apps written for specific device drivers (like those games that use nVidia- or ATI-proprietary interfaces) will be more difficult. But these apps usually include alternate code paths to handle customers that haven't purchased the matching hardware, so this kind of emulation is not strictly necessary.
this is why MS's strategy to absorb the browser...
If this is true, I welcome it with open arms - I would love to turf my Dell laptop for a PowerBook. I am still skeptical.
As well, it may not fix the problem. One of the critical applications for most software development going on these days is the browser. Many applications will check "is this a Windows machine, running IE", instead of "does this browser support a certain functionality. I am not sure what would happen if you were running the Windows version of IE on the Mac - it might work, if the sniffer thinks it is on a Windows platform. Long term, MS is protecting themselves anyway by absorbing the browser into Longhorn. They can be proprietary as they want, and developers that use the proprietary tools will still lock out any non-Longhorn user.
It is a wonderful idea (and I, for one, will use it), but it may be too late, unless it really works as well as they say, and Apple can obtain significant market share before Longhorn arrives. I would love to see it, but it is probably a pipedream. MS holds the developer community, by and large, and most IS departments in the palm of their hand. It is sad, but true.
If this is true, I welcome it with open arms - I would love to turf my Dell laptop for a PowerBook. I am still skeptical.
As well, it may not fix the problem. One of the critical applications for most software development going on these days is the browser. Many applications will check "is this a Windows machine, running IE", instead of "does this browser support a certain functionality. I am not sure what would happen if you were running the Windows version of IE on the Mac - it might work, if the sniffer thinks it is on a Windows platform. Long term, MS is protecting themselves anyway by absorbing the browser into Longhorn. They can be proprietary as they want, and developers that use the proprietary tools will still lock out any non-Longhorn user.
It is a wonderful idea (and I, for one, will use it), but it may be too late, unless it really works as well as they say, and Apple can obtain significant market share before Longhorn arrives. I would love to see it, but it is probably a pipedream. MS holds the developer community, by and large, and most IS departments in the palm of their hand. It is sad, but true.
The APIs are openly available to developers... or anyone for that matter. That is how Apps interact with the OS. So you look at those, and try and pass their reqests to the hardware.
By the looks of it, they will be selling platform specific versions of their software.
http://www.transitive.com/products.htm
If they made a product that ran Win Apps on the x86 platform without Windows -- they would probably get sued into the ground. But since they are making a product that runs on POWER/PowerPC for example and happens to run x86 Apps along with MIPS etc. It is not the same product. I am not saying someone won't sue them, but I will say it is a hard case which has gone sour in the past. Look at Sony vs. Connectix over the Virtual GameStation emulator, in the end Sony lost and ended up just buying it from Connectix for some astronomical amount of money.
By the looks of it, they will be selling platform specific versions of their software.
http://www.transitive.com/products.htm
If they made a product that ran Win Apps on the x86 platform without Windows -- they would probably get sued into the ground. But since they are making a product that runs on POWER/PowerPC for example and happens to run x86 Apps along with MIPS etc. It is not the same product. I am not saying someone won't sue them, but I will say it is a hard case which has gone sour in the past. Look at Sony vs. Connectix over the Virtual GameStation emulator, in the end Sony lost and ended up just buying it from Connectix for some astronomical amount of money.
What I want to know...
They demonstrated Linux-Quake running on a Mac and Linux-GIMP running on Windows.
That's great and wonderful. But how about running Microsoft Office apps (either the Windows or the MacOS version - I don't care which) on Linux?
Call me crazy, but it seems that this test is striking in its absence. If I was developing this product, I wouldn't want to issue any press releases until I could demonstrate MS Office running on a foreign platform, if for no reason other than publicity.
They demonstrated Linux-Quake running on a Mac and Linux-GIMP running on Windows.
That's great and wonderful. But how about running Microsoft Office apps (either the Windows or the MacOS version - I don't care which) on Linux?
Call me crazy, but it seems that this test is striking in its absence. If I was developing this product, I wouldn't want to issue any press releases until I could demonstrate MS Office running on a foreign platform, if for no reason other than publicity.
There's only grounds for a suit if they violated Microsoft's intellectual property. Building code to comply with MS's published APIs doesn't count.&RU said:
But I wonder if supporting the published API is enough. I'm pretty sure MS Office uses undocumented APIs.
It is worth noting that (so far), the WINE project has not been sued into the ground.
Which would be a win for Transitive, but a loss for the rest of us.&RU said:
No Windows, and other issues...
My take on it...
First of all this QuickTransit isn't a full emulator, because apart from the CPU nothing is emulated. This of course means that no operating systems can be run, just applications for other operating systems.
QuickTransit has an API-mapper, which basically translates API calls from foreign applications to system calls of the native operating system.
This also means that Windows applications will NOT run:
"QuickTransit supports operating system mapping between any two Unix/Linux-like operating systems, as well as mapping between mainframe and any Unix/Linux-like operating systems."
http://www.transitive.com/technology.htm
Yes, it would be possible to do the same for the Windows API, because it's already been done in WINE. But it remains to be seen if a firm actually wants to go that way, since it's not too good to deal with partly documented API and probably even get in the way of Microsoft.
Now some comments on the Wired News article...
"In demonstrations to press and analysts, the company has shown a graphically demanding game -- a Linux version of Quake III -- running on an Apple PowerBook."
Erm, it would be really interesting which Linux Q3 was compiled for and what operating system the Powerbook ran, because running a Linux/PPC version of Q3 on Linux/PPC would be hardly impressive...
"QuickTransit fully supports accelerated 3-D graphics"
Well, probably everything in OpenGL, because translating Direct3D to OpenGL would be quite a feat...
"and about 80 percent computational performance on the main processor."
Somehow I doubt that. Even if you manage to have an almost 1:1 ratio for computation instructions, memory accesses will kill that ratio big time. That's the reason why dynamic recompilers aren't not as fast as they might be.
"One of the key breakthroughs is an "intermediate representation," a kind of lingua franca that gives the software the flexibility to translate from one platform to another."
I'd be really interested in that one, because I once analysed basically dozens of processor architecture trying to come up with just such a thing. After several months I dropped the idea, because it's just not practical. Even some of the most basic stuff (eg. integer division) is so diverse that you either have to include every possible implementation or have it represented in very simple steps.
In the first case the intermediate representation becomes a real monster that no one is willing to write a backend for another architecture, and in the second case the code quality will be really bad.
"Unlike most other emulators, QuickTransit translates blocks of code rather than a line at a time. In addition, it identifies and stores the most commonly executed code."
Oh, maybe they should tell that to Eric Traut, who did the dynamic recompiler in Apple's 68K emulator, the one in Virtual PC, and in Virtual Gamestation for Mac and PC...
Frankly, I'll believe it when I see it.
API mapping isn't new, it has been done in lxrun and WINE. The new thing here is the dynamic binary translator that according to them is using a general intermediate representation. And with the little experience I have I'd guess the 80% performance aren't achievable, especially not with that approach.
It would be a nice surprise to be proven wrong, we'll see...
My take on it...
First of all this QuickTransit isn't a full emulator, because apart from the CPU nothing is emulated. This of course means that no operating systems can be run, just applications for other operating systems.
QuickTransit has an API-mapper, which basically translates API calls from foreign applications to system calls of the native operating system.
This also means that Windows applications will NOT run:
"QuickTransit supports operating system mapping between any two Unix/Linux-like operating systems, as well as mapping between mainframe and any Unix/Linux-like operating systems."
http://www.transitive.com/technology.htm
Yes, it would be possible to do the same for the Windows API, because it's already been done in WINE. But it remains to be seen if a firm actually wants to go that way, since it's not too good to deal with partly documented API and probably even get in the way of Microsoft.
Now some comments on the Wired News article...
"In demonstrations to press and analysts, the company has shown a graphically demanding game -- a Linux version of Quake III -- running on an Apple PowerBook."
Erm, it would be really interesting which Linux Q3 was compiled for and what operating system the Powerbook ran, because running a Linux/PPC version of Q3 on Linux/PPC would be hardly impressive...
"QuickTransit fully supports accelerated 3-D graphics"
Well, probably everything in OpenGL, because translating Direct3D to OpenGL would be quite a feat...
"and about 80 percent computational performance on the main processor."
Somehow I doubt that. Even if you manage to have an almost 1:1 ratio for computation instructions, memory accesses will kill that ratio big time. That's the reason why dynamic recompilers aren't not as fast as they might be.
"One of the key breakthroughs is an "intermediate representation," a kind of lingua franca that gives the software the flexibility to translate from one platform to another."
I'd be really interested in that one, because I once analysed basically dozens of processor architecture trying to come up with just such a thing. After several months I dropped the idea, because it's just not practical. Even some of the most basic stuff (eg. integer division) is so diverse that you either have to include every possible implementation or have it represented in very simple steps.
In the first case the intermediate representation becomes a real monster that no one is willing to write a backend for another architecture, and in the second case the code quality will be really bad.
"Unlike most other emulators, QuickTransit translates blocks of code rather than a line at a time. In addition, it identifies and stores the most commonly executed code."
Oh, maybe they should tell that to Eric Traut, who did the dynamic recompiler in Apple's 68K emulator, the one in Virtual PC, and in Virtual Gamestation for Mac and PC...
Frankly, I'll believe it when I see it.
API mapping isn't new, it has been done in lxrun and WINE. The new thing here is the dynamic binary translator that according to them is using a general intermediate representation. And with the little experience I have I'd guess the 80% performance aren't achievable, especially not with that approach.
It would be a nice surprise to be proven wrong, we'll see...
GeeYouEye said:
Not really. The viruses and worms will be able to execute, but they won't have a windows directory to infect, windows system files, or anything.
And even if it does (say, they have to add the core windows files to run windows programs), it'll still only mean that they can ONLY affect the Windows side of things.
A couple of thoughts after the initial rush. I have seen this posted EVERYWHERE on the net. It seems everyone is picking this story up. Its almost like hype to boost stock prices.
IF, however, its legitimate, I think that this could potentially be a very good thing. As someone noted, hardware and to some extent, OS becomes irrelevant. Its simply a user preference that can run anything that any other computer can run. I know that computer OSes are a preference now but you are limited by the software you can run. We all complain about the software offerings of the Mac. Apple could now offer a superior package of tight OS/hardware configuration with the unlimited software selection of the PC side. We no longer have to worry about developers jumping ship or only prducing progrs for the PC side. Software costs could conceivably go down. Apple could then highlight its strengths (very tight hardware/software integration, ease of use, reliability and stability.)
My other thought is that this doesn't sound like a program you go out and buy but is built deep into the system by the system integrators. Installing it would probably be a pretty intensive affair. I hope that Apple is one of the big 6 mentioned in the article.
Someone mentioned about how the program would appear on screen. (would it have a an aqua interface or Windows-like etc.) I imagine if its a windows-based program it would have the windows interface (X-button, nasy looking icons etc.) and vice-versa if an aqua prog.
IF, however, its legitimate, I think that this could potentially be a very good thing. As someone noted, hardware and to some extent, OS becomes irrelevant. Its simply a user preference that can run anything that any other computer can run. I know that computer OSes are a preference now but you are limited by the software you can run. We all complain about the software offerings of the Mac. Apple could now offer a superior package of tight OS/hardware configuration with the unlimited software selection of the PC side. We no longer have to worry about developers jumping ship or only prducing progrs for the PC side. Software costs could conceivably go down. Apple could then highlight its strengths (very tight hardware/software integration, ease of use, reliability and stability.)
My other thought is that this doesn't sound like a program you go out and buy but is built deep into the system by the system integrators. Installing it would probably be a pretty intensive affair. I hope that Apple is one of the big 6 mentioned in the article.
Someone mentioned about how the program would appear on screen. (would it have a an aqua interface or Windows-like etc.) I imagine if its a windows-based program it would have the windows interface (X-button, nasy looking icons etc.) and vice-versa if an aqua prog.
MM2270 said:
If you read the info on the Transitive web site carefully you would see that it will run applications for a unix/linux-like OS compiled for one chip (say x 86) on a unix/linx-like OS based on another chip (say PPC)
This does not mean that Mac OSX will run on X86 -- or that Windows will run on Mac, or that Windows apps will run on Mac or vice versa -- it means that linux/unix apps for x86 will run on darwin and darwin app will run on x86 -- note that it does not even address things such as carbon/cocoa apps running on linux-x86.
So what it means, for example, is that highly specialized scientific analysis software originally coded and compiled for an x86 box running linux will run on darwin-ppc without porting -- This will be very very good for apple because it means that the investments into software that certain markets have (H-Ed, research, enterprise) do not have to toss out their software investment by migrating to Macs or invest more time to port -- It will ease platform transition in these markets -- and believe me, platform transition is happening in a specific direction
. In the bigger picture it will make macs more attractive to some key markets.
