<strong>I remember reading that the ability to run Windows apps was one of the original goals of the Apple board under Amelio when they bought Next.</strong><hr></blockquote>
Aren't you thinking about Red Box, which was Cocoa on Windows?
That would make it possible to let Cocoa apps run on both Windows and Mac OS X.
Wow, a lot of people talking about stuff they really don't understand.
mach is the microkernel that NeXT chose as the basis of their original operating system. Avie brought it with him from CMU (EDIT: corrected thanks to Aphelion, below) when Jobs recruited him into NeXT oh those many years ago. From a design perspective mach has some nice advantages and is much cleaner than most other operating systems (like Win9x, WinNT/2K/XP, Linux). This kind of clean design typically carries a performance penalty with it, and mach is no exception. For that reason Apple has "dirtied" it up a little in Darwin, complicating it a little to try to address the main performance issues. I haven't looked into the performance differences myself, but my feeling is that these days the performance issues in MacOS X do not stem from the use of mach, they are simply a result of immature higher level code sitting on top of the kernel (i.e. the BSD layer and IOKit). Apple will address this over time. mach presents enough advantages to outweigh its slight performance cost.
WINE is a work-alike for the Win32 API, presenting the same API to the applications without using any Microsoft code. This means they can load Win32 applications and run them without the applications knowing which OS is actually running. This is like having the same controls in a car (steering wheel, gas, brake, etc) so that the driver just jumps in and starts driving. If the controls are different (right hand drive, for example) then there is a good chance that the driver will crash.
The idea of WINE on MacOS X is fine, but all of the applications you want to run are compiled into x86 machine code. If you're running on a PowerPC Macintosh, it can't execute that x86 code directly so you would need an emulator. To continue my analogy above it would be like the driver jumping into a car on Venus -- the controls are the same but he's not going to do very well in the atmosphere and will die quickly. If you give him a spacesuit (i.e. an atmosphere emulator) then he can function, but operating in a suit like that is very cumbersome and slows you down.
VirtualPC is an x86 emulator, but they emulate all of Windows as well... and all of the hardware. Using WINE with an x86 emulator would considerably speed up all of the operating system operations that a Win32 application does. If you had an app that spent most of its time in the OS (very GUI oriented apps, for example) then it would be very fast. For computationally intensive apps, however, it would be very slow since most of the time is spent emulating x86 code. Most games would fall into this category, as would things like Photoshop, modellers, renderers, etc.
I don't know if a WINE+x86 emulator would be a bad thing -- it would increase the amount of software that Mac owners could use, but some developers might wonder why they should bother porting to Apple's APIs if the WINE experience is "good enough". Developers that want to sell Mac users a good experience, however, would definitely still port because emulation sucks and WINE isn't perfect. Apple could probably license the VirtualPC engine and use it for such a project... I just don't really see any big advantages to doing so.
<strong>I just don't really see any big advantages to doing so.</strong><hr></blockquote>
I completely understand the implications of WINE, emulation for x86 binaries, etc and while it's of course not the "killer app" (like you said slow for stuff that actually uses the CPU) it might add to the out-of-the-box experience and especially help convincing "users" that they can switch to OSX. There is still a big barrier in the minds of Wintel users that by switching they will lose functionality (in fact many knowledgeable "users" questioned why I'd want to buy a PowerMac, wondering about compatibility), and even if there is one tiny little Win32 app they like to use they will unwillingly use it as the excuse for not switching.
Of course it may be too complicated to really implement the emulator+WINE in a reasonable time frame and without using too much of Apple's resources but it would likely put Apple in a "no excuses" position for many a user.
<strong>I completely understand the implications of WINE, emulation for x86 binaries, etc and while it's of course not the "killer app" (like you said slow for stuff that actually uses the CPU) it might add to the out-of-the-box experience and especially help convincing "users" that they can switch to OSX. There is still a big barrier in the minds of Wintel users that by switching they will lose functionality (in fact many knowledgeable "users" questioned why I'd want to buy a PowerMac, wondering about compatibility), and even if there is one tiny little Win32 app they like to use they will unwillingly use it as the excuse for not switching.
</strong><hr></blockquote>
Yeah, the explanation was aimed at some of the other members.
There are typically three barriers for switchers -- price, concern about not being able to use certain software, and performance. A WINE+emulator solution might address the software issue, but its gong to make the performance issue much worse. You win some and you lose some.
[quote]<strong>
Of course it may be too complicated to really implement the emulator+WINE in a reasonable time frame and without using too much of Apple's resources but it would likely put Apple in a "no excuses" position for many a user.
A bit of speculation doesn't hurt anyone, right? </strong><hr></blockquote>
Heh. Well I'm speculating too, its just "negative speculation".
"Most games would fall into this category, as would things like Photoshop, modellers, renderers, etc."
But most switchers wanting to switch...from the articles I've read seem to say, 'I couldn't switch until I 'X' program's functionality could be replaced...' They often sound like 'little' apps in the computational sense that you talk about. Afterall, the Mac has the main games and apps...so you wouldn't need Wine for that.
"I don't know if a WINE+x86 emulator would be a bad thing -- it would increase the amount of software that Mac owners could use, but some developers might wonder why they should bother porting to Apple's APIs if the WINE experience is "good enough". Developers that want to sell Mac users a good experience, however, would definitely still port because emulation sucks and WINE isn't perfect. Apple could probably license the VirtualPC engine and use it for such a project... I just don't really see any big advantages to doing so."
The rumours floating about many moons ago had the mysterious G5 (presumably the Moto G5 test boxes?) emulating a 1 gig Pentium 3. Now, that may be hot air.
But care to speculate what speeds we think we'll get from 970 emulating a Pentium? I'd have thought enough to run apps reasonably if not in terms of bleeding edge speed.
With the 970 class approaching, it will be worlds away from a 200mhz 604e emulating Pentiums. Which, with loads of ram, wasn't THAT bad then (for general apps...)
If 'emulation' sucks ie you'll never get true speed parity, then the Mac's application base need never worry?
Then there's X-serve. I'll make an educated (well, for me...) guess. If current PC servers are hovering at Pentium 3 speeds...if the 970s made their way into X-serves...couldn't X-serve emulate NT servers reasonably well? So couldn't Apple sell to PPC and x86 custmers? Or...IF Apple had a proprietary 'x86' board with a Win' layer on top of Mach'...couldn't they sell X-serve to bus' customers who are wary of PPC and want x86? Why would Apple do this? 97% of the market to aim at?
Lemon Bon Bon
"it might add to the out-of-the-box experience and especially help convincing "users" that they can switch to OSX. There is still a big barrier in the minds of Wintel users that by switching they will lose functionality (in fact many knowledgeable "users" questioned why I'd want to buy a PowerMac, wondering about compatibility), and even if there is one tiny little Win32 app they like to use they will unwillingly use it as the excuse for not switching."
Kinda what I was thinking. Remove the psychological barrier. If your general apps run reasonably...etc you could switch. In time, you could replace dependence on apps as Apple crushes all software opposition at their current rate of going...
"Of course it may be too complicated to really implement the emulator+WINE in a reasonable time frame and without using too much of Apple's resources but it would likely put Apple in a "no excuses" position for many a user."
Once again I am thankful that Programmer is here to set things straight. Mach functions at a very low level; it has nothing to do directly with the application environments. And doing away with OS 9 booting in no way affects the OS X environment. We're talking about two entirely different OSs here.
Finally, we shouldn't be looking toward emulation but rather growth of the native Mac application base. In order to facilitate that objective, growth in market share is the most important concern. Apple should also foster better developer relations (which it could do in a variety of ways), but market share growth is the key.
Programmer, you're saying that apps compiled for x86 won't run natively on PPC. Okay, that's true, of course.
Now, Windows NT has something called HAL, Hardware Abstraction layer. There were NT versions for the PPC, for Alpha, and so on. At the same time, there was Rhapsody, which had the Red Box, which as far as I know as an API to run Win32, but was only available on the x86 version of Rhapsody.
Back to the HAL. Supposing it's still available under 2000 (NT 5.0) and XP (NT 5.1), exactly at what point does it "abstract" the hardware? My guess is that it'll make mostly the same code run on any NT platform, right? Are there cases where *all* of the code runs independently of the hardware?
My idea is that there might be a way to (ab)use the HAL to run Win32 apps on PPC, through a modernized "Red Box".
<strong>Back to the HAL. Supposing it's still available under 2000 (NT 5.0) and XP (NT 5.1), exactly at what point does it "abstract" the hardware? My guess is that it'll make mostly the same code run on any NT platform, right? Are there cases where *all* of the code runs independently of the hardware?</strong><hr></blockquote>
I think the Windows NT HAL is basically to separate hardware-specific functionality of the OS from the OS logic. So when porting NT (Alpha, x86, PPC) you have to rewrite the HAL and recompile the rest and it should work. So the code compiled on x86 stays more or less unchanged when compiled for Alpha, but this is true for the code and not for the actual .exe and .dll files. It wouldn't allow you compiling something on x86 and running the same .exe on Alpha, though.
<strong>My idea is that there might be a way to (ab)use the HAL to run Win32 apps on PPC, through a modernized "Red Box".</strong><hr></blockquote>
This is a common misconception about the HAL. The Hardware Abstraction Layer doesn't abstract away the instruction set and user execution model, it instead abstracts away the rest of the hardware (i.e. processor supervisor mode, physical memory layout, peripheral hardware, I/O busses, etc). The basic instruction set and registers are fundamental to compiled software, and the HAL does not attempt to abstract those.
There are systems out there which abstract away the ISA and user execution model. The best known one is the Java Virtual Machine. There are numerous virtual machines out there, but they all suffer in terms of performance compared to native execution speed.
There is one other system that I am aware of, and that is used by the language & runtime system known as Oberon. In this scheme they basically stop compilation half-way and store the intermediate form of the program. At load time they run the back end of the compiler, which generates & optimizes code for the processor it is run on. Unfortunately this system hasn't received widespread attention (and it does have its own set of issues).
BTW: thanks to Aphelion, he is quite right that Avie and mach came out of Carnagie Mellon University (CMU), not MIT as I stated above.
I wish there was a bitch-slapping smilie for times like these...
-------------
The HAL seperates the hardware from software, so you don't need specific software for each model Macintosh/PC.
OpenGL, CoreAudio, BSD Sockets, all abstract the hardware.
Now, sure Microsoft could make Windows XP for Mac again, and use an IA-32 emulator to run those programs. But there is no money in it.
Mac users are particular about what interfaces they use. Like the Aqua Human Interface Guide says, Mac users won't buy programs with bad interfaces.
Developers catch on pretty quickly about stuff like that, or they don't become successful.
The safest way to run windows programs would be similar to Classic mode. A PC is emulated, and a windows installation is run on said PC.
Drivers would be installed on Windows for generic components, like a graphics card where instructions recieved no translation.
Using WineX would mean DirectX emulation on OpenGL, so games could run (slowly).
However, all this would be useful for is some tiny little app for which there is no Mac equivilent. Would it be worth Apple building a "Windows.app" just for that? After all, Virtual PC is pretty effective.
The licensing of WineX on Mac OS X already makes it a good possibility of a lot more games being made for Mac OS X.
As far as I know, Connectix developed (or helped develop) the 68k emulator for early PowerPC models running 7.1.2 through 9.x, so it looks like Apple used Connectix's technologies before.
Programmer, thanks for the explanation on the HAL.
<strong>As far as I know, Connectix developed (or helped develop) the 68k emulator for early PowerPC models running 7.1.2 through 9.x, so it looks like Apple used Connectix's technologies before.
Programmer, thanks for the explanation on the HAL.</strong><hr></blockquote>
Back then, Connectix was famous for its little camera and for memory management. Mode32 allowed Macs without 32-bit clean addressing to address more than 8 MB of RAM. Apple replaced its own manager with the Connectix version.
Prior to the introduction of the Power Mac, Insignia Solutions was the king of the emulators with its SoftPC emulator. With the advent of the Power Mac, Insignia introduced SoftWindows. Apple bundled SoftWindows with some of its machines. At the time Connectix's major product was the little spherical web cam. Connectix introduced Virtual PC sometime later. However, Virtual PC soon overtook SoftWindows.
IIRC, the 68k emulator used in Apple's Power Macs is an Apple creation. The 68k emulator was incorportated into the ToolBox ROM. It now resides in the ROM file. Apple contracts out ports of its software to other platforms. I am not aware of the company's doing that for its own.
1) Didn't IBM have a license of some sort for Windows code which they used in OS2? Has that expired, or does anybody know more details?
2) One of the other interesting tricks of the 68k-to-ppc transition was the static code converter. Reports were that more than 80% of a 68k app was usably converted after running through one of these.
If the "API" code is native ppc (as in the case of a WINE-like widget written for ppc), and 80% of the remaining code can be recompiled & stored _once_, that leaves only a teeny bit of fully emulated code.
As another (pure speculation) sort of thing - Apple would be in control of the appearance of the widgets - so the random x86 app running under this hyothetical tool would _look_ like a regular aqua app if they wanted it to. Except for widgets that were hand coded I guess, so it might look, um, odd
Hmmm. A year ago the guy I who sold me my cell phone saw my Apple tshirt and started going on about how his brother worked at Apple. I asked him what he did, and he said the brother was working on some top secret program that allowed you to open programs written for Windows on OS X and they would work just like regular Aqua programs. He said he had seen it and it was much faster than VPC. To me it still sounds like BS but it is almost exactly what you guys are talking about.
Guys, you almost drove me crazy. Thank you, Programmer, for stopping it.
[quote]Originally posted by ast3r3x:
<strong>so if apple were to get rid of mach, would OS X run faster?</strong><hr></blockquote>
It doesn't take a computer scientist to notice Apple boasting about their mach kernel implementation on every page of <a href="http://developer.apple.com."; target="_blank">http://developer.apple.com.</a>; Could you imagine it's just conspiracy to cloak Marklar or 'Cocoa on Windows' or 'Windows on AltiVec' or 'we-choose-win32-api' projects?
which would mean that we were wrong in presuming Marklar is OSX on x86 but rather win32 on ppc. which would make MS angry. quite angry.</strong><hr></blockquote>
iSPREAD ?!!! :cool:
The general American public would find that unacceptable, methinks....
As for the win32-on-Mach, I believe it used to be called Red Box?
Comments
<strong>I remember reading that the ability to run Windows apps was one of the original goals of the Apple board under Amelio when they bought Next.</strong><hr></blockquote>
Aren't you thinking about Red Box, which was Cocoa on Windows?
That would make it possible to let Cocoa apps run on both Windows and Mac OS X.
mach is the microkernel that NeXT chose as the basis of their original operating system. Avie brought it with him from CMU (EDIT: corrected thanks to Aphelion, below) when Jobs recruited him into NeXT oh those many years ago. From a design perspective mach has some nice advantages and is much cleaner than most other operating systems (like Win9x, WinNT/2K/XP, Linux). This kind of clean design typically carries a performance penalty with it, and mach is no exception. For that reason Apple has "dirtied" it up a little in Darwin, complicating it a little to try to address the main performance issues. I haven't looked into the performance differences myself, but my feeling is that these days the performance issues in MacOS X do not stem from the use of mach, they are simply a result of immature higher level code sitting on top of the kernel (i.e. the BSD layer and IOKit). Apple will address this over time. mach presents enough advantages to outweigh its slight performance cost.
WINE is a work-alike for the Win32 API, presenting the same API to the applications without using any Microsoft code. This means they can load Win32 applications and run them without the applications knowing which OS is actually running. This is like having the same controls in a car (steering wheel, gas, brake, etc) so that the driver just jumps in and starts driving. If the controls are different (right hand drive, for example) then there is a good chance that the driver will crash.
The idea of WINE on MacOS X is fine, but all of the applications you want to run are compiled into x86 machine code. If you're running on a PowerPC Macintosh, it can't execute that x86 code directly so you would need an emulator. To continue my analogy above it would be like the driver jumping into a car on Venus -- the controls are the same but he's not going to do very well in the atmosphere and will die quickly. If you give him a spacesuit (i.e. an atmosphere emulator) then he can function, but operating in a suit like that is very cumbersome and slows you down.
VirtualPC is an x86 emulator, but they emulate all of Windows as well... and all of the hardware. Using WINE with an x86 emulator would considerably speed up all of the operating system operations that a Win32 application does. If you had an app that spent most of its time in the OS (very GUI oriented apps, for example) then it would be very fast. For computationally intensive apps, however, it would be very slow since most of the time is spent emulating x86 code. Most games would fall into this category, as would things like Photoshop, modellers, renderers, etc.
I don't know if a WINE+x86 emulator would be a bad thing -- it would increase the amount of software that Mac owners could use, but some developers might wonder why they should bother porting to Apple's APIs if the WINE experience is "good enough". Developers that want to sell Mac users a good experience, however, would definitely still port because emulation sucks and WINE isn't perfect. Apple could probably license the VirtualPC engine and use it for such a project... I just don't really see any big advantages to doing so.
[ 01-12-2003: Message edited by: Programmer ]</p>
<strong>I just don't really see any big advantages to doing so.</strong><hr></blockquote>
I completely understand the implications of WINE, emulation for x86 binaries, etc and while it's of course not the "killer app" (like you said slow for stuff that actually uses the CPU) it might add to the out-of-the-box experience and especially help convincing "users" that they can switch to OSX. There is still a big barrier in the minds of Wintel users that by switching they will lose functionality (in fact many knowledgeable "users" questioned why I'd want to buy a PowerMac, wondering about compatibility), and even if there is one tiny little Win32 app they like to use they will unwillingly use it as the excuse for not switching.
Of course it may be too complicated to really implement the emulator+WINE in a reasonable time frame and without using too much of Apple's resources but it would likely put Apple in a "no excuses" position for many a user.
A bit of speculation doesn't hurt anyone, right?
C'mon, give points for trying...
Lemon Bon Bon
[ 01-12-2003: Message edited by: Lemon Bon Bon ]</p>
<strong>I completely understand the implications of WINE, emulation for x86 binaries, etc and while it's of course not the "killer app" (like you said slow for stuff that actually uses the CPU) it might add to the out-of-the-box experience and especially help convincing "users" that they can switch to OSX. There is still a big barrier in the minds of Wintel users that by switching they will lose functionality (in fact many knowledgeable "users" questioned why I'd want to buy a PowerMac, wondering about compatibility), and even if there is one tiny little Win32 app they like to use they will unwillingly use it as the excuse for not switching.
</strong><hr></blockquote>
Yeah, the explanation was aimed at some of the other members.
There are typically three barriers for switchers -- price, concern about not being able to use certain software, and performance. A WINE+emulator solution might address the software issue, but its gong to make the performance issue much worse. You win some and you lose some.
[quote]<strong>
Of course it may be too complicated to really implement the emulator+WINE in a reasonable time frame and without using too much of Apple's resources but it would likely put Apple in a "no excuses" position for many a user.
A bit of speculation doesn't hurt anyone, right?
Heh. Well I'm speculating too, its just "negative speculation".
Er, didn't Avie come from CMU?
But most switchers wanting to switch...from the articles I've read seem to say, 'I couldn't switch until I 'X' program's functionality could be replaced...' They often sound like 'little' apps in the computational sense that you talk about. Afterall, the Mac has the main games and apps...so you wouldn't need Wine for that.
"I don't know if a WINE+x86 emulator would be a bad thing -- it would increase the amount of software that Mac owners could use, but some developers might wonder why they should bother porting to Apple's APIs if the WINE experience is "good enough". Developers that want to sell Mac users a good experience, however, would definitely still port because emulation sucks and WINE isn't perfect. Apple could probably license the VirtualPC engine and use it for such a project... I just don't really see any big advantages to doing so."
The rumours floating about many moons ago had the mysterious G5 (presumably the Moto G5 test boxes?) emulating a 1 gig Pentium 3. Now, that may be hot air.
But care to speculate what speeds we think we'll get from 970 emulating a Pentium? I'd have thought enough to run apps reasonably if not in terms of bleeding edge speed.
With the 970 class approaching, it will be worlds away from a 200mhz 604e emulating Pentiums. Which, with loads of ram, wasn't THAT bad then (for general apps...)
If 'emulation' sucks ie you'll never get true speed parity, then the Mac's application base need never worry?
Then there's X-serve. I'll make an educated (well, for me...) guess. If current PC servers are hovering at Pentium 3 speeds...if the 970s made their way into X-serves...couldn't X-serve emulate NT servers reasonably well? So couldn't Apple sell to PPC and x86 custmers? Or...IF Apple had a proprietary 'x86' board with a Win' layer on top of Mach'...couldn't they sell X-serve to bus' customers who are wary of PPC and want x86? Why would Apple do this? 97% of the market to aim at?
Lemon Bon Bon
"it might add to the out-of-the-box experience and especially help convincing "users" that they can switch to OSX. There is still a big barrier in the minds of Wintel users that by switching they will lose functionality (in fact many knowledgeable "users" questioned why I'd want to buy a PowerMac, wondering about compatibility), and even if there is one tiny little Win32 app they like to use they will unwillingly use it as the excuse for not switching."
Kinda what I was thinking. Remove the psychological barrier. If your general apps run reasonably...etc you could switch. In time, you could replace dependence on apps as Apple crushes all software opposition at their current rate of going...
"Of course it may be too complicated to really implement the emulator+WINE in a reasonable time frame and without using too much of Apple's resources but it would likely put Apple in a "no excuses" position for many a user."
We'll see. Will Marklar reveal its true face?
[ 01-12-2003: Message edited by: Lemon Bon Bon ]</p>
Finally, we shouldn't be looking toward emulation but rather growth of the native Mac application base. In order to facilitate that objective, growth in market share is the most important concern. Apple should also foster better developer relations (which it could do in a variety of ways), but market share growth is the key.
I was never keen on the all black Performer...
Lemon Bon Bon
Now, Windows NT has something called HAL, Hardware Abstraction layer. There were NT versions for the PPC, for Alpha, and so on. At the same time, there was Rhapsody, which had the Red Box, which as far as I know as an API to run Win32, but was only available on the x86 version of Rhapsody.
Back to the HAL. Supposing it's still available under 2000 (NT 5.0) and XP (NT 5.1), exactly at what point does it "abstract" the hardware? My guess is that it'll make mostly the same code run on any NT platform, right? Are there cases where *all* of the code runs independently of the hardware?
My idea is that there might be a way to (ab)use the HAL to run Win32 apps on PPC, through a modernized "Red Box".
<strong>Back to the HAL. Supposing it's still available under 2000 (NT 5.0) and XP (NT 5.1), exactly at what point does it "abstract" the hardware? My guess is that it'll make mostly the same code run on any NT platform, right? Are there cases where *all* of the code runs independently of the hardware?</strong><hr></blockquote>
I think the Windows NT HAL is basically to separate hardware-specific functionality of the OS from the OS logic. So when porting NT (Alpha, x86, PPC) you have to rewrite the HAL and recompile the rest and it should work. So the code compiled on x86 stays more or less unchanged when compiled for Alpha, but this is true for the code and not for the actual .exe and .dll files. It wouldn't allow you compiling something on x86 and running the same .exe on Alpha, though.
<strong>My idea is that there might be a way to (ab)use the HAL to run Win32 apps on PPC, through a modernized "Red Box".</strong><hr></blockquote>
This is a common misconception about the HAL. The Hardware Abstraction Layer doesn't abstract away the instruction set and user execution model, it instead abstracts away the rest of the hardware (i.e. processor supervisor mode, physical memory layout, peripheral hardware, I/O busses, etc). The basic instruction set and registers are fundamental to compiled software, and the HAL does not attempt to abstract those.
There are systems out there which abstract away the ISA and user execution model. The best known one is the Java Virtual Machine. There are numerous virtual machines out there, but they all suffer in terms of performance compared to native execution speed.
There is one other system that I am aware of, and that is used by the language & runtime system known as Oberon. In this scheme they basically stop compilation half-way and store the intermediate form of the program. At load time they run the back end of the compiler, which generates & optimizes code for the processor it is run on. Unfortunately this system hasn't received widespread attention (and it does have its own set of issues).
BTW: thanks to Aphelion, he is quite right that Avie and mach came out of Carnagie Mellon University (CMU), not MIT as I stated above.
<strong>
I was never keen on the all black Performer...
</strong><hr></blockquote>
I wish there was a bitch-slapping smilie for times like these...
-------------
The HAL seperates the hardware from software, so you don't need specific software for each model Macintosh/PC.
OpenGL, CoreAudio, BSD Sockets, all abstract the hardware.
Now, sure Microsoft could make Windows XP for Mac again, and use an IA-32 emulator to run those programs. But there is no money in it.
Mac users are particular about what interfaces they use. Like the Aqua Human Interface Guide says, Mac users won't buy programs with bad interfaces.
Developers catch on pretty quickly about stuff like that, or they don't become successful.
The safest way to run windows programs would be similar to Classic mode. A PC is emulated, and a windows installation is run on said PC.
Drivers would be installed on Windows for generic components, like a graphics card where instructions recieved no translation.
Using WineX would mean DirectX emulation on OpenGL, so games could run (slowly).
However, all this would be useful for is some tiny little app for which there is no Mac equivilent. Would it be worth Apple building a "Windows.app" just for that? After all, Virtual PC is pretty effective.
The licensing of WineX on Mac OS X already makes it a good possibility of a lot more games being made for Mac OS X.
Barto
Programmer, thanks for the explanation on the HAL.
<strong>As far as I know, Connectix developed (or helped develop) the 68k emulator for early PowerPC models running 7.1.2 through 9.x, so it looks like Apple used Connectix's technologies before.
Programmer, thanks for the explanation on the HAL.</strong><hr></blockquote>
Back then, Connectix was famous for its little camera and for memory management. Mode32 allowed Macs without 32-bit clean addressing to address more than 8 MB of RAM. Apple replaced its own manager with the Connectix version.
Prior to the introduction of the Power Mac, Insignia Solutions was the king of the emulators with its SoftPC emulator. With the advent of the Power Mac, Insignia introduced SoftWindows. Apple bundled SoftWindows with some of its machines. At the time Connectix's major product was the little spherical web cam. Connectix introduced Virtual PC sometime later. However, Virtual PC soon overtook SoftWindows.
IIRC, the 68k emulator used in Apple's Power Macs is an Apple creation. The 68k emulator was incorportated into the ToolBox ROM. It now resides in the ROM file. Apple contracts out ports of its software to other platforms. I am not aware of the company's doing that for its own.
2) One of the other interesting tricks of the 68k-to-ppc transition was the static code converter. Reports were that more than 80% of a 68k app was usably converted after running through one of these.
If the "API" code is native ppc (as in the case of a WINE-like widget written for ppc), and 80% of the remaining code can be recompiled & stored _once_, that leaves only a teeny bit of fully emulated code.
As another (pure speculation) sort of thing - Apple would be in control of the appearance of the widgets - so the random x86 app running under this hyothetical tool would _look_ like a regular aqua app if they wanted it to. Except for widgets that were hand coded I guess, so it might look, um, odd
<strong>To me it still sounds like BS but it is almost exactly what you guys are talking about.</strong><hr></blockquote>
In the unlikely event of something like that ever being released it would probably be a huge boost for my ego
[quote]Originally posted by ast3r3x:
<strong>so if apple were to get rid of mach, would OS X run faster?</strong><hr></blockquote>
It doesn't take a computer scientist to notice Apple boasting about their mach kernel implementation on every page of <a href="http://developer.apple.com."; target="_blank">http://developer.apple.com.</a>; Could you imagine it's just conspiracy to cloak Marklar or 'Cocoa on Windows' or 'Windows on AltiVec' or 'we-choose-win32-api' projects?
<strong>
which would mean that we were wrong in presuming Marklar is OSX on x86 but rather win32 on ppc. which would make MS angry. quite angry.</strong><hr></blockquote>
iSPREAD ?!!! :cool:
The general American public would find that unacceptable, methinks....
As for the win32-on-Mach, I believe it used to be called Red Box?
engpjp