

Windows 8 to support ARM, System on a chip, architectures - ajg1977
http://www.microsoft.com/presspass/press/2011/jan11/01-05SOCsupport.mspx

======
iuguy
I've noticed a lot of speculation about how they will translate code between
X86, X86_64 and ARM. Well, the simple answer is not to translate at all. MS
have been pushing managed code via things like Silverlight and .NET for some
time. My tuppence worth: Windows 8 on ARM won't support legacy x86 code, but
will run .NET, Silverlight and any other managed code shamalamadingdong it
needs to run. I can see Windows 8 on x86 supporting legacy code, but just as
16-bit support is gone completely in x86_64 Windows now, I'm expecting no
support for unmanaged x86 code in the ARM version.

Where all this gets interesting is with things like Mono and Moonlight. If MS
goes down this route, they could really be exposed as Mono and Moonlight
mature.

~~~
jallmann
> Windows 8 on ARM won't support legacy x86 code, but will run .NET. I can see
> Windows 8 on x86 supporting legacy code

Hmm, I don't believe so. That'd introduce fragmentation that Microsoft's
typical users (mom and pop) should not have to deal with.

Also that'd be a pretty drastic policy shift for Microsoft seeing the pains
they've gone to maintain compatibility with older software.

My guess is that, at the very least, Win8 apps running native code will be
packaged into a universal binary of some sort. I find that half-hearted
though, since it requires recompilation of the original software.

wtracy suggested the possibility of JITing x86 to ARM, that's ballsy and it'd
be awesome if Microsoft pulls that off.

~~~
iuguy
> wtracy suggested the possibility of JITing x86 to ARM, that's ballsy and
> it'd be awesome if Microsoft pulls that off.

JITing x86 - ARM might not even be fully necessary for most modern apps. It
might be possible to do some sort of interception and JIT-style translation
for certain parts of code but it might also be possible to provide a DLL level
compatibility layer as fallback. That way when DLL functions are called
they're called natively, and the main module executes via JIT.

I'm not suggesting that would be easy, it'll be balls to the wall hard, but
that's the only thing I that immediately springs to mind that wouldn't come
with a massive performance penalty.

The fragmentation argument is valid and an excellent point to make, however we
don't really know who this is being targeted at or the defined primary use
cases at this point. If Microsoft can f _ck up the user experience so badly
with Vista and Windows 7 Starter, they can f_ ck up the user experience with
ARM and not worry too much. It might also be worth bearing in mind that if a
recompile is needed, it's going to be in the next Visual Studio, which will
support a lot more managed code features through the CLR than unmanaged code
on x86_64 (by which I mean the CLR supports more languages and has fairly
tight integration - if you use C++ in Visual Studio you're probably using less
of Visual Studio overall than if you're writing ASPX in C#).

------
ssp
There is the idea that Windows is such a terrible system that the only reason
people are staying with it is that they need their legacy applications. It's
not _entirely_ without merit, but for a lot of people and businesses, Windows
actually works rather well.

The importance of x86 is overstated too. Many applications will be pretty
close to a recompile away. There is of course the usual chicken-and-egg issue
that all platforms have, but if Windows/ARM (WARM?) takes off, they _will_ be
recompiled.

~~~
kenjackson
Enterprise LOB is almost all .NET and web now. Native apps are increasingly
just consumer apps.

~~~
dmethvin
If Microsoft ported Office/SharePoint to native ARM I might be able to believe
this.

~~~
contextfree
They are porting Office to native ARM, it was mentioned in Sinofsky's
presentation.

~~~
kenjackson
From the CES demo it appears that they've already done the port. I was really
impressed they had IE9 with GPU acceleration on ARM working already too.

------
Hoff
Porting an OS onto a new box can be technically quite interesting, but is only
a fraction of the aggregate effort involved.

It's the business issues that matter. Whether you can recoup the costs, and
when.

Application availability, third-party support, hardware vendor support,
testing, and whether there's enough of a draw (coolness, compelling price
advantage, better battery efficiency, whatever) to pull your user bases to the
new platform, and pull in new customers.

There's the additional risk with whether and when key vendors will move. It
might well technically be a recompile and go for the applications, though the
vendors of key applications are probably going to need to see a sufficient
market, or they may want some funding for porting. Vendors tend to be
(reasonably) loathe to accept this porting and testing and support load
without some form of revenue plan.

Emulation and translation are technically possible, though that too can be
problematic; various vendors can tend not to support emulated or translated
code. For understandable reasons, more than a few vendors wouldn't support
their applications on Windows on Alpha via FX!32, for instance.

I'm also surprised that Microsoft is discussing this now; whether this is a
cudgel on some providers, a palliative for their partners considering adding
other OS platforms (Android, WebOS or otherwise), customers that are accepting
other OS platforms, or whether they're really (seriously?) talking about a
project and a potential product that's two years out.

Wondering what their particular motivation(s) here might be, still.

------
runjake
Interesting that Microsoft's answer to "Why?" seems to be "Because we can." by
journalists. Hopefully they have a better strategy than that.

That said, I'm all for more ARM support in the world.

It looks like it will run .NET apps with little or no reworking. They probably
borrowed a lot of the work of the .NET Compact Framework team for a reverse
port. Expect native SDKs later, after the initial launch.

~~~
wtracy
MS has learned from their experience with Windows on Alpha. Even when they
released XP for x86-64, they initially wouldn't sell it at retail for fear
that people would get confused and buy the wrong one.

I'm betting they have some compatibility magic cooked up that we haven't seen
yet.

Emulation has already been suggested. How about the possibility of having a
launch hook that recompiles x86 machine code to ARM machine code? MS is on the
short list of companies with the necessary resources to pull that sort of
trick.

~~~
runjake
Their "magic" is .NET and MSIL.They explicitly stated they aren't virtualizing
or emulating x86 code during the session.

~~~
brudgers
Right. They have ten years of .NET penetration into the corporate world, the
web, and 3rd party application developers - plus four years of .NET
integration right into their operating systems.

It is running on everything from embedded systems, to phones, to desktops, to
clusters. Throw in that all the hardware vendors who are interested in "the
Next Windows" and Microsoft has just laid out a roadmap for the next ten
years.

------
maguay
So how long will it take hackers to get Windows 8 running on an iPad? Will
definitely be interesting...

~~~
redthrowaway
Why? Putting Android on the iPhone I get, but I don't see too many hackers out
there wanting to flip off Apple by installing _Windows_ , of all things.

To put it another way, how many macbook pros are running Win7 solo, aka w/o
bootcamp or VMware?

~~~
scdlbx
Why? For the sole purpose of getting Win8 running on an iPad.

~~~
redthrowaway
Fair enough.

------
maximilianburke
I wonder how much effort will be required to port native applications to
Windows/ARM. I imagine it won't be too onerous since both x86/x64 and ARM are
little-endian. Excepting bits of inline assembly and use of compiler
intrinsics I don't think it would be too difficult. I also wonder if there
will be a FAT binary extension to PE/COFF, or if applications will have to
have separate builds per platform.

------
roc
So Microsoft sees a real threat in Chrome OS netbooks then?

That's the only place I see this being relevant. Windows in any form that can
meaningfully execute legacy x86 code is not going into a non-PC device.
(dashboard computers, pocket computers, pmps, phones, tablets, etc)

So the only thing left is netbooks. Is that really a relevant play in 2011? Do
they think this _isn't_ a feature Google can match and beat them to market on?
Do they think the legacy of Windows will be a compelling alternative to the
relative simplicity and security of Chrome OS in that market?

~~~
discreteevent
I know that the "news" in this announcement is about ARM. But Soc itself is
also about making existing PC software run faster. At the moment there is
little argument for purchasing new hardware because multiple cores are failing
to significantly improve actual performance of desktop apps for reasons with
which we are all familiar.

------
brianwillis
Can one of you clever people explain what is meant by the term "system on a
chip"? Is it just a marketing buzzword, or is there more to it than that?

I've tried wikipedia, but just got even more confused.

~~~
jdabney
A system on a chip is a single chip that integrates all or almost all other
chips on a motherboard into one chip. So this chip will have a cpu, graphics,
memory controller, network controller, io such as usb. That way you can have
basically one chip that is all or most of the computer. Sometime RAM and
normally storage is separate chips but you basically end up with just a few
chips on a very small, normally low power motherboard. It is great for system
integrators as they don't need to spend as much development time to build new
machines.

~~~
jmtulloss
It's also great for power and size constraints.

------
dmethvin
If this is true, then Windows 8 is not a true successor to Windows 7. Current
desktop/server apps assume binary compatibility with x86. This sounds much
more like a scaled-up version of Windows Phone.

~~~
bonzoesc
That's a crazy thing to say. The UI, the APIs, etc. will all be based on
Windows 7, and any all-CLR apps should run without change. On Windows 8
running on x86, current apps (and Windows 3.1 apps, and maybe DOS apps?) will
undoubtedly still run.

It's just like the Mac Intel transition, but without an emulator to fill in
the gaps.

~~~
kijinbear
Who knows? MS might be obsessed enough with backwards compatibility to pack an
emulator in there, like they did with WOW64 (though it would be more difficult
to write an x86 emulator for ARM).

~~~
rbanffy
> it would be more difficult to write an x86 emulator for ARM

Building an x86 emulator is easy. Building one that can run Windows 8 software
at speeds comparable to then current Intel or AMD x86 processors will probably
be impossible. There is no such performance gap between ARM and x86.

~~~
TeHCrAzY
Would the opposite be easier? It might make sense to offer comparability for
Windows|ARM executables on Windows|x86, so if you want to hit both platforms,
you'd be doing it in ARM.

I can see ARM being great for corporate desktops: .net LOB apps work, IE will
work, Office will work etc.

~~~
rbanffy
Sure, but one key advantage of Windows is that it has a huge legacy of
software that already targets x86 and that would have to be
recompiled/reoptimized to ARM.

The performance of a built-for-speed x86 is very forgiving. Eclipse runs well
enough on my Core i5, but I suspect it would have problems on an energy-
efficient ARM.

