I don't want this thread to turn into another "my OS is better then yours" this is just an idea i had and thought i would share. with the mac universal binary programs structured in a "somename.APP" folder and being self contained as such. could someone write a framework that would take the API calls from the mac program and run the application now that they are compiled on x86 code? would make running windows look better to run applications from both companies then to use a virutalized windows or multiboot a mac to run windows apps. i guess it would work like the .NET frameworks, maybe call it the .MAC frameworks?
-
-
I'm not sure what you're asking for, but if you're suggesting to run a mac application on windows then the short answer is no.
The problem isn't the way a mac executable is build but the libraries the application uses. Most obvious is cocoa which I don't know any decent port of. So it's up to apple to provide these libraries for windows.
(there are some ports of cocoa but nothing usefull at the moment)
-
Refrax wrote:
I don't want this thread to turn into another "my OS is better then yours" this is just an idea i had and thought i would share. with the mac universal binary programs structured in a "somename.APP" folder and being self contained as such. could someone write a framework that would take the API calls from the mac program and run the application now that they are compiled on x86 code? would make running windows look better to run applications from both companies then to use a virutalized windows or multiboot a mac to run windows apps. i guess it would work like the .NET frameworks, maybe call it the .MAC frameworks?
It's theoretically possible, just like Wine is possible. It would take decades for it to catch up to Mac OS, though (just like Wine), except that Apple has a much faster release cycle than Microsoft, so it would be even harder to catch up.
Plus, there are Cocoa calls for random things like getting people's screen names from iChat or interacting with the address book, so several Apple applications would have to be reimplemented as well. -
For most OS apps, the majority of the code for the 'experience' is outside the app, yes cocoa is just part of it. OS X is built upon a set of frameworks (/System/Library/Frameworks), layered above a UNIX (Darwin) substrate. This is literally millions of lines of code with very intricate dependencies. Try reading Amit Singh's OS X Internals (1500+ pages), cover-to-cover, and you'll get an appreciation for what you're asking for.
The same is true vice-verse, i.e. using something like DarWINE to run Windows apps on OS X. Beyond the technical hurdles there's intellectual property (IP) entanglements that are difficult to overcome. You can avoid some of this with open-source with varying quality.
Finally you'd have to test and update against a perpetually moving target.
Good luck! -
I believe parrallels (spelling?) is letting you do this now with emulated OS substructure. So you're running minimized Microsoft Windows however the applications which can be launched via the dock and run "in parrellel" with OSX apps.
-
Nope...Parallels is running a copy of Windows that has a tool installed that can make the desktop shell invisible so all you see are application windows (including the task bar). As a result, all Windows windows (eep) have the same z-value within the Mac's desktop.
Once upon a time, NeXT had a version of their OpenStep frameworks running on top of Windows NT (3.51), but that was close to 10 years ago. This is in contrast to the intel-native version of NextStep/OpenStep that dates back to '93 or so and served as the basis for the current intel builds of Mac OS X. I was running NextStep on a 486/66 back in '94 and always assumed that Apple, when they bought NeXT, continued to build the OS for intel...which of course, turned out to be the case.
-
Someone would have to take OpenStep as a base, and update it to include all the newer APIs/Frameworks, Core Audio, Core Graphics, Core Data, Core etc etc. and overlay them on top of the equivelent Windows APIs
It would be nearly the equivelent amount of works as the Wine project, which has been attempting to reimplement all the Windows APIs and the ABI on top of L/unix for over 10 years.
Thread Closed
This thread is kinda stale and has been closed but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.