Originally Posted by Carniphage
As a licensor, Apple can decide which manufacturers and which products it will issue a license for. It would only pick licensees which generated cash.
Can't be done without hardware restrictions built into the vendor's machines. This means new lineups have to be made to accommodate Apple's OS. If they don't, people will simply get hold of the copy of OS X that loads without hardware checks and share it online with the world and people will just use it on all sorts of hardware.
This is what happened years ago. Apple licensed their product to 3rd party vendors and they just didn't pay up and it nearly took Apple 'down the shitter' to quote Jobs so they abandoned the program. Unless they have some smart way of protecting themselves, there's no way they are going there again.
On the subject of the Windows APIs again, this stuff has been going round for years:http://www.speedofcreativity.org/200...ndows-license/http://www.marco.org/269
Something in that last site caught my attention though:
"The PE loader in Leopard is a pretty clear sign that Apple has at least experimented with this idea in the labs."
The portable executable loader seems to be for loading Windows binaries:http://www.cultdeadcow.com/tools/pewrap.html
I hadn't heard of there being evidence of such a thing in Leopard. Surely if this was the case then it's pretty firm evidence for this to be the case. Why would Apple even have this in their OS is it wasn't for a Windows compatibility layer?http://www.winehq.org/pipermail/wine...er/060846.html
"Upon further research I found that the Mac loader seems to have its own undocumented PE loader built in. So this leads to the question. Whats going on? Is this a hold over from EFI which is PE by default? Why would the OS need to load the EFI files? Maybe just for easy of development and testing? Or is something else going on? Is Apple going to be adding a win32 compatibility layer to OS X? Is having a native PE loader of any use to us?"
"This is new to Leopard. On Tiger, dlopen rejects PE files as expected. PE Files were rejected on Tiger, which is interesting to me because I don't think that this is just a hold over from EFI support. I think it may be a sign of future addition of a Win32 subsystem to OS X."
# local symbols to suppress
The project file references ImageLoaderPE.cpp, but that isn't included
in the source...
all the other files are here, so yes it really looks like they are
trying to hide support for
PE. Why would they go to all this trouble to hide Windows Binary support?"
The security issues that could arise from such a compatibility layer could of course be gotten around by sand-boxing, which they introduced in Leopard too.
It's a much more likely scenario than OS X licensing because it means that people who buy or have bought Mac hardware benefit from it, not Apple's hardware rivals. It also scores some points against Microsoft as people don't have to pay licenses for Windows. It could of course mean that people will be less inclined to develop for the Mac in some cases but it could also be the ultimate tool in persuading developers over to the Mac platform as they can develop and test everything easily from one machine for both Mac and Windows users.
They might even jazz it up a bit so that Windows apps run inside semi-aqua (or whatever SL will have) instead of their usual uglified interface.