We found out that the Rosetta kernel uses TCPA/TPM DRM.
Currently their are no ways known to get the GUI working on non-Apple hardware, with this protected kernel.
Even with a SSE3 enabled cpu you will never get the GUI.
Read more about TCPA here: http://www.againsttcpa.com/tcpa-faq-en.html

Yuck, that's sad :-(. How did you find out?

It's on the wiki and they confirmed it in the IRC channel.

Post edited due to implied violation of the DMCA.

Posting that in anyway implies a violation of the DCMA will not be permitted in this forum.

See Forum Rules for more information.

So what you are saying is that original Apple commercial in 1984 is about the customer trying to overcome Big Brother Apple in the future?

I truly have mixed emotions about this... A bad emotion because you guys can't run Mac OS X on a normal X86 computer (so I would like because Mac hardware is quite too expensive for me) but maybe also a good emotion that Apple's future will be safe and sound.

Notice that people buy Macs just because of the OS. The computers are well durable, but they do not compare to the average people who go and grab a Dell for a few hundred.

But TCPA truly is deceiving. The future doens't seem open. And with quirky laws such as "The Patriot Act", maybe we are becomming like communists.

I would say the community are communist and Apple is now fascists. The exact opposite of what they seemed to want in 1984.

Was just going to point out that it was more like Fascism than Communism...

Pardon me. I didin't study all these classes.

Post edited due to implied violation of the DMCA.

Posting that in anyway implies a violation of the DCMA will not be permitted in this forum.

See Forum Rules for more information.

Post edited due to implied violation of the DMCA.

Posting that in anyway implies a violation of the DCMA will not be permitted in this forum.

See Forum Rules for more information.

What's this about the "Rosetta" kernel using TPM? What's the "Rosetta" kernel?

Isn't Rosetta Apple's binary translation solution to allow PPC OSX apps to run on OSX x86?

What does Rosetta have to do with OSX x86 as far as booting up and running with the GUI?

Is Rosetta now some integral part of OSX x86?

Or has the original poster confused OSX x86 with Rosetta?

Or is Rosetta functionality the only thing locked out through some sort of TPM?

The mach kernel in the Developer Kits automatically launches Rosetta when trying to run PPC-only binaries instead of showing that "Can't execute binary file" error message. The latest open source versions of Darwin (8.1, 8.2) don't have such a functionality, it seems like you can still launch Rosetta manually (./oah750 binaryfile) but we can't be sure about that as Rosetta isn't currently running because of the TPM issue.



Yes, it is.



An essential service for running the GUI like ATSServer is not ported to the x86 architecture, so it runs emulated by Rosetta in the Developer Kits. No Rosetta, no text rendering, no GUI.



At the moment, it is. Perhaps Apple will port ATSServer in the future, but we can't currently run the GUI without Rosetta.



I don't know, i haven't found more binaries asking for the TPM, only oah750d, but maybe there are or there will be more ones. Another thing that seems related to the TPM chip is that a lot of binaries are signed in some way probably during the installation procedure as they don't match the checksums in the bom files and they're different between kits. And the different bytes between two copies of the same signed binary from different kits are the same in each case for every signed file, so if the signature corresponding to a devkit is 0xAABBCC, it will be the same for every signed file in that devkit. We're trying to identify a pattern in the signature's location as it is not at the same offset in every files. It seems to be found in the LINKEDIT section (only Mach-O executables and libraries are signed).

Regards, blex0r

Thanks for the answer.

Does that mean that on the development machines, the OSX GUI is not running natively, and presumably has compromised performance?

If so, that implies (to me) that the OSX GUI will eventually be native to the x86. But, if that's the case, how might this current limitation impact developers currently using the Mac Dev kit as it runs now? Or are all applications developed for OSX (PPC or x86) totally independent of the GUI's acceleration, and the fact that the OSX x86 GUI is running through Rosetta is of no consequence, either for performance or application development? And if that's the case, is there no benefit to be had from removing the Rosetta pathway for the GUI?

In other words, is Rosetta going to be one of the the keys to Apple's attempts at locking out generic hardware, or is there too much of a penalty running the GUI through Rosetta for production Macs?

I think that currrently, in these dev machines, Apple implemented TC in Rosetta to make sure that people won't succeed in what we are doing right now, trying to run the GUI on non-Apple hardware.
And of course there would be performance penalty in the GUI so the performance of the current Tiger intel is still a bit far from the real Mactels we will see next year(if the first releases are projected next year). The performance of the dev machines are not so important since they are for developers to develop mactel enabled programs beforehand, and Apple strictly announced that no performance report should be done using these machines. I believe that real mactels will have native implementations of the GUI, and maybe a more strict TCPA lock on some other crucial programs to prevent the retail version of Mac OS X for mactel to be run on non-Apple hardware.

These are my own opinions of course.

This seems like a very odd scenario considering the historical development of OS X for x86. I mean, Apple should have already had ATSServer "ported" in my mind. In fact, I do not think that porting per se would even be necessary at this point as we know that OS X has been co-developed to run on x86 from the beginning.

Has anyone else independently verified that the OS X86 is actually running PPC ATSServer? It be nice if someone with access to an Apple Transition Kit system could actually verify that Rosetta is indeed running the GUI.

Or maybe they're never going to convert it and this is how they've managed to stop us from running it on any straight off the market Dell Computer. Good way to do it but if we manage to get a hold of a Dev Kit then we should be able to emulate it....

Personally, I believe that the more people running OS X the better and that projects like this (or PearPC) actually help Apple gain market share. At this point, it seems unclear how serious Apple will be about preventing OS X86 from being run on generic hardware. This is the first word of anything being done to specifically prevent it, other than the expected technical barriers with drivers and hardware requirements.

If Apple does actually want to use some sophisticated TC to tie OS X86 to it's own hardware, why not do it directly? The idea of tying it down via Rosetta seems overcomplicated and besides, the entire GUI should be native for speed and over all system performance that is expected to be burdened by running non-native apps.

As far as an ATSServer "port" goes, on a cursory web search, I can not tell for sure if ATSServer was orginally part of NextStep, OpenStep or Rhapsody. But there is some evidence which suggests that is was and which would mean that it existed for x86. So, with the exception of the report being made in this thread, we have many good reasons to expect that ATTServer for x86 already exists.

However, it certainly is possilbe that Apple is running PPC ATSServer in the Transition Kit OS X86 for some unknown reason. Perhaps the current x86 ATSServer has some bugs that are still be worked out or even that Rosseta works better with PPC ATSServer. I mean, I think we know that Rosseta only works with code that is entirely PPC and not PPC-x86 hybrids. So, if the PPC code is linked to x86 ATSServer, maybe Rosetta would consider that hybrid code thus necessitating a PPC version of the ATSServer. But that should not preclude an x86 ATSServer for use with native applications and OS X86 itself.

Edit: Spelling of "Rosetta"

I guess it means that the leaked hard drive image, plus the necessary OSX GUI files from OSX Tiger PPC version, plus a working Rosetta ought to be a theoretically complete developer system.

Is Rosetta built upon an open source project? If it were, then I suppose the best pathway to running OSX x86 on generic hardware would be substituting Rosetta with a non proprietary version.

ATSServer is a lightweight part of the OS X GUI and although it's run emulated I don't think it to be compromising the performance at all. Remember that it has been reported that some programs like Firefox run faster emulated on the Developer Kits than native on a Powermac G5 (I'm talking about the ppc version of Firefox, not about the universal binary that came out later).



It should not have any impact in the development as applications are not aware of ATSServer being run emulated or native.



We're not talking about the entire GUI but the Type Server. WindowServer is native, Quartz is native, key GUI apps like loginwindow or the Finder are native. ATSServer is the only component of the GUI that we have found being not native.



They aren't likely to need nothing more than clicking a checkbox in Xcode to generate an ATSServer universal binary. They're talking about much larger and complicated apps being ported to x86 by changing no more than 20 or 30 lines of code. I don't think porting ATSServer to be a problem at all.



ATSServer is not a library but a daemon. Processes communicate with it via IPC mechanisms. Rosetta emulated processes shouldn't have problems to communicate with native ones at all.



It is not. There's an open source project called SoftPear that aims to create a ppc to x86 recompiler and a compatibility layer between OS X/ppc and Linux, FreeBSD and Darwin x86, in a similar way to wine's. However it's still in its very early stages of development and it can't run many more ppc executables than gzip, ls... I don't think it to be capable of running ATSServer and doing it well enough. I couldn't even compile it in Darwin/x86.

Regards, blex0r

We've now tested the "signature" on files from 3 different machines, and they are all different.

Incorrect.
As stated in the x86 programming guidelines PDF, you can force a Universal binary to use Rosetta. IIRC, this can be set from the Get Info box in the finder.

Mashugly,

Thanks for keeping us informed! Could you clarify your last statement? I'm not sure I'm following you. Do you mean the "signature" is a watermark from Apple or that the "signature" is used with the DRM Intel chip?

Thanks,
P

Great information! But then why would Apple be screwing with PPC ATSServer on OS X86?

As far as we know, is the ATSServer server the ONLY thing missing to get the GUI running?

To the extent that you are suggesting that ATSServer is relatively simple, is it possible for a replacement to be created? I mean do we know enough about its interface and function to even consider such an approach? Is there something comparable in Linux?

Alternatively, would it be possible to run PPC ATSServer as a PearPC process (instead of Rosetta) inside of OS X86?

I did not mean switching between the PPC and x86 codebases of a Universal binary for an application as a whole, but rather a composite application that has unique x86 and PPC parts. I believe that Rosetta will not work to emulate (or translate) a block of PPC code in a native x86 process.

It doesn't. And about universal binaries, they're nothing but archives containing two or more versions of a binary for various architectures. You can even extract those binaries from the universal one (see man ditto). That can be useful for disassembling those binaries with tools that don't support universal binaries but are able to disassemble Mach-O files for both ppc and x86 like IDA.

Regards, blex0r

Pentad - see my post here: http://osx86.classicbeta.com/forum/viewtopic.php?t=75

Check out our TPM Resource Page on the wiki - http://www.osx86.classicbeta.com/wiki/index.php/TPM

Would it be reasonable to set up a PearPC process to run PPC ATSServer in OS X86?

Post edited due to implied violation of the DMCA.

Posting that in anyway implies a violation of the DCMA will not be permitted in this forum.

See Forum Rules for more information.

Just so everyone is clear, PearPC and SoftPear are different projects. PearPC is a working PPC emulator for x86 that has been used for over a year to run OS X on generic PC hardware (very slowly). PearPC information is available here: http://pearpc.net/

With respect to the Mach Override idea describe on the Wiki main page, I found a paper that might be useful:

"Intercepting Arbitrary Functions on Windows, UNIX, and Macintosh OS X Platforms" http://lattice.umiacs.umd.edu/files/functions_tr.pdf

I wonder if it'd be possible to hack qemu to support mach-o, then run ATSServer with that? The trickier part would probably be bridging the objc runtime... anyone know enough to know if this is feasible?

forgive my ignorance but would any of the work over on the gnustep project[/ objc framework with openstep implementation ] environment useful?

Unfortunately, probably not. Openstep, while aiming to be funtionally equivallent to a subset of Mac OS X's Cocoa API, it doesn't share any of the same source and even if it did, it isn't particularly relivant here.

GNUStep is a high level application programming kit. It has nothing to do with this low level, kernal related TPM issue.

The applicable open source resources that should be considered here are things like the Darwin project: http://www.opendarwin.org/ and IBM Linux "TCPA" Driver: http://www.research.ibm.com/gsal/tcpa/. This site has excellent page of TPM resources that should be studied: http://www.osx86.classicbeta.com/wiki/index.php/TPM

A clear understanding of the TPM mechanism that is operating between Apple's TPM kernel extension to Darwin and Rosetta are need to solve this problem. For any PearPC (an open source PPC emulator for x86) solution to work, elements of PearPC would probably have to be integrated in to the Darwin kernel.

Post edited due to implied violation of the DMCA.

Posting that in anyway implies a violation of the DCMA will not be permitted in this forum.

See Forum Rules for more information.

Sorry, but this IBM driver is completely outdated and surpassed by http://tpmdd.sourceforge.net

Since Linux 2.6.12 the latest IBM driver is included in the mainstream kernel. So just look at the Linux kernel source if you want to see how to talk to a TPM.

Anyway, Apple is using an Infineon TPM and the IBM driver only supports Atmel and National Semiconductors. For an Infineon TPM device driver, look at http://www.prosec.rub.de/tpm/

Transitive's quicktransit (the real name of 'rosetta') claims around 80% of native speed (with full opengl compatability).

Is there anyway to get a copy of that Transitive software? The non-Rosetta version?

I've been trying for 6 months (thats how long its existed), but theres no way (other then by force). Transitives software is also used on SGI's new x86 machines for backwards compatabilty for there old platforms. I've tried emailing/calling such to try and get me a demo (even calling from my 'anonymous OEM') But they refuse all requests. The only way to get a copy would be to rob them (718 university avenue suite 200 los gatos ca 95302 or 2nd floor maybrook house 40 blackfriers street Manchester m32eg), or hack them... and I don't think anyones going to do that. Besides the fact that Transitive uses a hosting company so attacks on their webserver would be useless as if they were sucessfull they would not help you get the software. However several months ago (through google groups) I discover the IPs used by transitive for their real work... 212.23.25.136 - 212.23.25.143. 212.23.25.143 seems to be a router of some kind with telnet being the only available port with password only authentication. All the other hosts are 100% firewalled from the outside except their mail server 212.23.25.140... they run an exim smtp daemon which was the last time I checked version 3.35. On this server they also run apache (only on 443) for the sole purpose of providing webmail through squirrelmail (apache/1.3.26 ben-ssl/1.48 squirrelmail/1.2.6). They also run a few secure mail daemons imaps and pop3s as well as rsync2.6.

WOW did I get offtopic... I guess thats a short answer no... long answer you tell me, of course I'm just rambling on about some stuff I read in a whois report a couple months ago... I'm not advocating anything...