- #Is it illegal to run mac os x emulator on vmware pro
- #Is it illegal to run mac os x emulator on vmware windows
In Linux terms - take a look at XGL - it does a similar thing in terms of putting hardware accleration under X11 - and has been denounced by some for breaking the Unix architecture.
#Is it illegal to run mac os x emulator on vmware windows
In Windows terms, it's like having the desktop built on top of Direct X.
#Is it illegal to run mac os x emulator on vmware pro
a lot of Apple's software - from the desktop to the Pro apps - depends on the performance of Quartz (the graphics layer), which in turn uses hardware acceleration where available. However, where you'd start getting problems is that Cocoa is designed to run directly on top of the kernel and hardware, not on top of X11 - i.e. whether you could persuade the system to send your messages to a set of non-Apple objects. I don't know whether Obj-C would work in your favour or against - i.e. The new APIs also seem well documented, especially as Apple is keen for languages like Ruby, etc, to provide bindings. Again, as a positive, GnuStep has tracked SOME of Apple's extensions to OpenStep in Cocoa.
In other areas, you'd have problems - consider that OS/X is a nominally more 'advanced' system that the Win32 APIs that WINE has had to reverse engineer - it's going to be somewhere between Win32 and Vista in terms of complexity - which suggests it's a bigger job that Wine. In some areas you would have a head start - the NextStep Foundation and AppKit already exist on Linux as part of GnuStep, and other APIs, such as WebKit (branched from KHTML) are open source. I'm sure it's within the bounds of feasibility, but it's worth understanding what would be required, and what the end result, if run on TOP of X11, would be like. At some point you need some basic infrastructure to build on, but with BSD being so close you might be able to get Linux to just load native, low-level BSD libc and friends and build on that. First, bootstrap the binaries and set up a loader to load native MacOS libraries. There's some concern this has hurt Wine, but it's worth thinking about. You'd probably want to approach this with a loader-first-native-later attitude like Wine. Translating MacOS things like threading might be easier than Win32, but windowing will be a bitch. It's hard enough to find people who know Linux & Win32. You need people who are comfortable programming in both Linux/Unix API's and MacOS API's. Sure, not everything is on there, nor is what they have complete or correct, but it helps immensely to begin figuring out libraries.
I'm not sure what Apple's is like, but Microsoft has MSDN and a lot of documentation. Here's some very tough obstacles you'd have to overcome: 1. *I stand corrected (see the comments), both are virtualizers.Īs part of the Wine project, I can assure you this type of development is REALLY HARD. This approach would have top-notch speed and wouldn't need a copy of OS X to work.) (And for those who are confused, this is approach is totally different from that of Mac-on-Linux or VMWare, which are both emulators*. Granted, it would definitely need an enormous effort, but it would be absolutely incredible if Linux could run both Windows and OS X apps. Can anyone think of any real reasons why this shouldn't be possible now? (Again, I might be wrong, but some of the GNUStep APIs might be re-usable in a project like this.) Sure, OS X applications are in a different non-ELF (non-Linux) binary format, but neither are Windows apps. I might be wrong, but I believe it should now be possible to implement an OS X API on top of UNIX, exactly like what WINE did to the Windows API. After reading about this many times, a thought occurred to me: x86 executables (programs) instead of PowerPC (the old processor type) executables means that if one wanted to hypothetically try to run OS X applications on Linux, it would no longer require an emulator. With the release of Apple's OS X for Intel x86-based processors, OS X applications are being released in a different "format" to run on these new processors.
In my personal opinion, I would say this project is a wild success, especially with the advancements made to it in the last year. In layman's terms, it means it lets you run Windows programs on Linux. The WINE project is an "Open Source implementation of the Windows API on top of X and UNIX".
0 kommentar(er)
