Circumventing Windows RT’s Code Integrity Mechanism

Re:Circumventing Windows RT’s Code Integrity Mechanism by sjmulder on Sunday January 06, 2013 @08:17PM (#5018644)

It would, but Apple did the same thing when they switched to Intel and worked out pretty well. They even shipped all the PowerPC binaries for a while, together with an emulation layer, so you could run old apps on Intel (albeit slowly).

It's more of a backwards compatibility/marketing issue, I suppose. Apple could afford to have programs work 'more or less', Microsoft with its track record for backwards compatibility probably cannot.

[ Parent | on HN ]

Re:Circumventing Windows RT’s Code Integrity Mechanism by ams6110 on Sunday January 06, 2013 @10:56PM (#5019214)

Apple (and NeXT before them) was able to compile "fat" (multi-architecture) app binaries since the 1990s. The original NeXT machines had Motorola 68030 and later 68040 processors; OpenSTEP also ran on Sparc and Intel and I think PA-RISC also, of course then PPC, and then Intel again --- they've had architecture independence in their frameworks for a LONG time.

[ Parent | on HN ]

Re:Circumventing Windows RT’s Code Integrity Mechanism by wmf on Sunday January 06, 2013 @11:09PM (#5019258)

Emulation is fine when you're switching to a faster processor (68K -> PPC, PPC -> Intel). In this case, MS is introducing a slower processor so emulation would probably be painful.

[ Parent | on HN ]

Re:Circumventing Windows RT’s Code Integrity Mechanism by meaty on Monday January 07, 2013 @05:34AM (#5020371)

Well they shot themselves there. The CLR was supposed to be the portability layer i.e. IL code would be dynamically compiled. Unfortunately due to Microsoft's schizophrenia, it never became a first class part of the OS over say non-portable PE x86 specific binaries.

Technically they could use dynamic translation, but building a working translator for x86->arm would be an absolute bastard as x86 is such a non-orthagonal mess of an architecture.

[ Parent | on HN ]