Microsoft Ready To Talk Windows On ARM

An anonymous reader writes "After many months of working in secret, Microsoft is nearly ready to start talking about its plans to bring Windows to ARM-based processors. However, while the company is set to discuss the effort at next month's Consumer Electronics Show, there is still a lot that must be done before such products can hit the market. Among the steps needed is for hardware makers to create ARM-compatible drivers, a time-consuming effort that explains in part why Microsoft is talking about the initiative well ahead of any products being ready. Meanwhile, Ubuntu is already starting to ship on some ARM devices and running on many others."

Comments

No surprise

[MightyMartian]

It's not exactly a surprise. Don't produce something for ARM, and it's likely that Microsoft will be left in the dust in the few years on a major platform. I wonder if the NT guts of newer versions of Windows are still as portable as they were a decade ago.

Re:No surprise

[symbolset]

They can just trot down to the Azure lab and ask Dave Cutler how he got it to work last time.

Re:No surprise

[gbjbaanb]

The NT Kernel might be, even after all this time slapping whatever each release thinks is a useful feature into it, but who cares about that. I think I can guarantee Office will not run on ARM, so its pretty much dead already.

Then there's the reason to run Windows at all - the 3rd party apps that are x86 only (many are not even x86_64 yet) and they won't run either. So all in all, this is just fluff. If you want a low-energy server farm full of ARM CPUs (and who wouldn't!) then you might as well run Linux there - many, many server apps run Linux anyway. If you want ARM on the desktop, don't hold your breath, and if you want ARM mobile .. you already have it, even for WinPhone 7.

So, I'm confused. The ARM share price has done well from the rumour, but we'll see what astounding piece of underwhelm-dent gets revealed at CES.

Re:No surprise

[MightyMartian]

Who said Office has to run on it? Or at least the full-blown Office. They've got pretty lightweight stuff like Works out there.

Re:No surprise

[jawtheshark]

Do you know anyone who uses Works?!? For real?

Besides, Works is anything except lightweight. For starters, it comes with a full blown Microsoft Word.

Re:No surprise

[PRMan]

Actually, there's a video of Mark Russinovich talking about all the changes they made to the kernel to make it more portable. They broke it into 3 layers: MinWin, Server and Full and cut any ties that went up or down between them. I would say it's more portable than ever.

Re:No surprise

[PRMan]

But .NET applications compile Just In Time. So all they have to do is port the .NET framework and compiler and all .NET applications will work with almost no changes, especially if they virtualize the environment to make it look like a desktop (put a phony C: drive on an SD card, etc.)

Re:No surprise

[gilesjuk]

ARM chips use a quarter of the power compared to the Atom chips.

ARM core designs can be licenced and integrated into SOC (system on a chip).

With Atom you need the Atom chip plus a northbridge chip, with ARM you can use a single chip. More space in a mobile device means more space for batteries.

Re:No surprise

[DarkOx]

Really, why don't you think Office will run on ARM. First off more and more of it is being ported to .Net which we know the VM and runtime libraries are portable so all of that code should just work one ARM. Second any code I have ever seen from Microsoft has been really good about not making assumptions about the size if ints and endianness and things like that which generally cause portability problems. They already have an x86_64 Office that they ship, which is a pretty good sign they could make office run on other architectures as well.

Getting Office to work on arm probable would be a porting effort and not just a simple rebuild but its doable in short order if you have the resources and Microsoft does.

Re:No surprise

[PopeRatzo]

I think I can guarantee Office will not run on ARM, so its pretty much dead already.

Not being able to "run Office" hasn't hurt iOS4.

Re:No surprise

[Billly Gates]

It is not that simple. The MSIL just converts the code to win32 calls. Some of these are for more modern versions of Windows that are x86 specific. You would need to rewrite and port part of the win32 apis and MFCs. Sounds like pure torture.

Re:No surprise

[Billly Gates]

The newest version comes with the older word processor.

I tried it and it crashes when you cut and paste more than a page of text from Firefox. I had to clear my temp files afterwards as it crashed each time I started it up. Talk about POS.

Re:No surprise

[KibibyteBrain]

.NET apps CAN be shipped as pure IL assemblies but as far as I can tell in the real world this is more rarely done than it could and probably should be. .NET assemblies can be compiled into platform-specific assemblies with some Frankenstein mix of pre-complied code in them, and there are many, many .Net apps built targeted for the x86 platform, and which only world when build in such a fashion.

Re:No surprise

[geekoid]

well, since it might be hard, clearly they shouldn't try to get into a platform that is very likely to see much of the mobile market.

or maybe they already thinking about that:

http://www.microsoft.com/downloads/en/details.aspx?familyid=30092C39-22D1-4585-8E17-003C1ED00C49&displaylang=en

MS is actually getting their shit together. Maybe you should buy a clue?

Re:No surprise

[geekoid]

yes, it has. There market would be much bigger.

And it could run it, but you know the MS / Apple love / hate cycles. Right now it's closer to 'hate' then love.

Re:No surprise

[the linux geek]

It has another first-party office suite (iWork). Stop confusing the issue.

Re:No surprise

[jawtheshark]

My point exactly. That you even installed it is amazing.

Re:No surprise

[DragonWriter]

The NT Kernel might be, even after all this time slapping whatever each release thinks is a useful feature into it, but who cares about that. I think I can guarantee Office will not run on ARM, so its pretty much dead already.

I think all they really care about is whether IE, the .NET framework/Silverlight, and things like Office Live will work on it. ARM devices, if they are keyboard & mouse/touchpad devices, are going to be more likely to be ultralight netbooks or nettops rather than desktop-replacement laptops or standard desktops.

Re:No surprise

[Sancho]

http://office365.microsoft.com/en-US/online-services.aspx would probably work.

Re:No surprise

[TheRaven64]

I think I can guarantee Office will not run on ARM, so its pretty much dead already.

Why not? It's C++ code and runs on x86-32, so it will almost certainly run on ARM with a straight recompile. There's nothing exposed at the C level that's different between the two architectures.

Then there's the reason to run Windows at all - the 3rd party apps that are x86 only (many are not even x86_64 yet) and they won't run either.

Hmm, if only Microsoft had bought a company that made an x86 emulator. Oh, wait, they did. A modern emulator traps library calls, so an x86 app running on an ARM CPU would be running native code whenever it called any DLLs that ship with Windows, including all of the drawing routines and so on.

If you want a low-energy server farm full of ARM CPUs (and who wouldn't!) then you might as well run Linux there - many, many server apps run Linux anyway

And most of those apps run under Windows too...

Re:No surprise

[fwarren]

It is the same situation as MONO. You can write an app that will run on .NET in Windows and Mono in Linux. Write once and compile for each platform. The problem is it is all to easy to call stuff that wont port. The stark and bleak reality is any .NET app written for win32 or win64 will need major work to run on MONO or .NET-ARM.

As a stupid example. I had to take a Visual Basic programming course. I had to put some output into a multi-line textbox. If I had a choice I would have used a more advanced table control so I could break up the output into columns. Instead, I turned back to my old win32 api programming days and placed a few tab stops into the textbox. This is done with a win32api call, once that is done, the program is non-portable. Any nontrivial app will require some retooling unless it was written from the ground up to be portable.

Without a plethora of win32 apps, Win-ARM will have issues. Even then those apps are not designed for the iPad sized tablet or netbook. Dialog are to large, icons not sized for a touch display. If you Look at WM7 as well as all earlier WinCE stuff, this is not looking good for Microsoft.

Re:No surprise

[dimeglio]

It would be love if MS didn't decide to jump on the mobile phone bandwagon. If the company making the OS was split from the one creating the office automation tools, things might have been different. To think it almost happened... Sigh.

Re:No surprise

[jawtheshark]

Hmm, if only Microsoft had bought a company that made an x86 emulator. Oh, wait, they did.

Are you referring to Virtual PC? You might need to read up on what an emulator is and what virtualization software is. Bochs is an emulator, Virtual PC is virtualization software. You can't use Virtual PC on, let's say a SPARC, software to run Windows on that machine. You can, however, run Bochs on a SPARC machine to run Windows... I wouldn't suggest you try, because it's going to be slow.

Virtualization software only supports the architectures that the underlying architecture supports.

Re:No surprise

[Anonymous Coward]

You can write an app that will run on .NET in Windows and Mono in Linux. Write once and compile for each platform. The problem is it is all to easy to call stuff that wont port.

That's only one problem. Another problem is that Mono's framework is shit - a kludge with lots of incompatibilities. The System.DirectoryServices namespace, for example, sits on top of Novell's LDAP stack in Mono, so LDAP apps that work flawlessly in .NET land will often fail under Mono. This is all due to bugs in Novell's stack that they aren't bothering to fix.

Re:No surprise

[node 3]

I've never owned as ARM computer (just C=6502, 68000-60, PowerPC, x86, MIPS, and EE).

Why do you think that matters? There will always be someone how hasn't owned some particular thing, yet that thing can be popular.

Why do you think ARM will be a dominant brand in the coming years

It already is. iPhone, iPod touch, iPad, Android...

These devices are projected to outsell traditional PCs in the near future. It's likely that ARM outsells AMD already, and possibly even Intel. Even of not, ARM is already a dominant brand.

Re:No surprise

[node 3]

The NT Kernel might be, even after all this time slapping whatever each release thinks is a useful feature into it, but who cares about that. I think I can guarantee Office will not run on ARM, so its pretty much dead already.

Microsoft has two cash cows, Windows and Office. If they are going to take the time to port Windows to a platform, it would be strange for them to not also port Office. I have no idea how you can "guarantee" that Office won't run on ARM.

Re:No surprise

[shutdown -p now]

The MSIL just converts the code to win32 calls.

There is a factual error in pretty much every single word in this sentence.

First, MSIL does not convert anything. MSIL is the bytecode. It is what gets converted, by JIT compiler.

Second, it does not get converted to "win32 calls". It is converted to native opcodes on the particular architecture. All "win32 calls" are in the libraries such as WinForms.

Finally, porting Windows to ARM by definition means "port all Win32 APIs to ARM". So even something that P/Invokes a lot would not be affected.

MFC has nothing whatsoever to do with this. It's not a system API, and it's not used by .NET standard class library in any way.

Re:No surprise

[shutdown -p now]

You can write an app that will run on .NET in Windows and Mono in Linux. Write once and compile for each platform. The problem is it is all to easy to call stuff that wont port. The stark and bleak reality is any .NET app written for win32 or win64 will need major work to run on MONO or .NET-ARM.

You miss one very important reason why it's so hard to be portable with Mono. For one thing, it's because it doesn't fully implement all .NET libraries (e.g. no WPF), or sometimes it isn't 100% identical in terms of how it works. More importantly, it's because so many .NET apps use Win32 API directly (via P/Invoke and COM interop).

But here's the thing: neither of those would be a problem on a proper Windows/ARM port. Win32 API would be available in full (just as it was in past non-x86 versions of NT), and so would be .NET APIs.

About the only way I can think of making a .NET app non-portable between x86 and ARM would be to use packing or explicit layout to make fields unaligned, and then create a pointer to them and try to read or write via that pointer (IIRC, ARM requires aligned memory access).

Re:No surprise

[jonbryce]

Given that the current version is ported to the Intel Itanic, I would imagine yes.

Re:No surprise

[shutdown -p now]

Why not? It's C++ code and runs on x86-32

Office 2010 has an x64 version, as well. Which presumably means that at least some x86-specific quirks that might be present in the code base (assuming specific sizeof etc) were ironed out, making it easier to port.

Re:No surprise

[Grishnakh]

Heck, you don't have to have an Apple i-something to have an ARM either. Lots of more mundane devices use them: printers, DVD/BD players, etc. They're embedded in all kinds of stuff, and are easily the most popular embedded CPU architecture, and have been licensed by tons of companies like Broadcom, Marvell, Samsung, etc. Crack open your laser printer and you'll likely find an ARM CPU in there. Probably your broadband router too.

Re:No surprise

[jonbryce]

ARM sells (or rather licences) more chips every year than Intel has sold in its lifetime.

Re:No surprise

[cbhacking]

Dude, I've seen a *phone* run Office on ARM (and a WinCE kernel, but it could be ported to NT without so much trouble). You even brought it up yourself - WinPhone7. It's a limited version of Office, but it handles reading and writing the document format just fine; the rest is UI. Office also runs (well, ran) on PowerPC (Mac), and as with phones, the only maor difference is UI. What the hell makes you think it's not portable?

You have a valid point about apps, at least for un-managed code.

Re:No surprise

[Johnno74]

I'd be very surprised if you don't own something that has an ARM core. They are _everywhere_
If you've brought a cellphone since about 2005, or brought a consumer router from linksys, buffallo, asus or many others, or most media player gadgets then you'd probably find an ARM core in them.

Re:No surprise

[cbhacking]

Wow, you're wrong on so many levels!

MSIL doesn't convert anything. It's the code that gets converted. MSIL (more commonly called CIL, for Common Intermediate Language, now that Mono is a working non-MS implementation) is analogous to Java bytecode.

What does get converted (using a Just-In-Time compiler) is CIL to native code. Typically, this native code is x86 or x64, but there are already JIT compilers for ARM as well. After the JIT completes, the result is saved locally so the overhead is only encountered once.

As for Win32 calls, there's no "conversion" at all. What happens is that after the CIL gets compiled to native code, it links into libraries (native DLLs) that implement functions for the OS (such as Win32 calls). For example, if a .NET function calls System.IO.File.Create(), when that code is run, a managed code function gets called, and it in turn calls an unmanaged function in the linked library. That library makes the necessary translation into the native API (let's say Win32 on NT), resulting in an unmanaged call to CreateFile(), which in turn goes into the Win32 user subsystem library and gets translated into a NtCreateFile() system call, which is sent to the kernel.

If you're on another platform, such as Linux, WinCE, OS X, or other, on any architecture at all, the only difference is that you need to write a library that has the same public interface (System.IO.File.Create()) and calls the correct native function on its own platform (open(), for example). The .NET API is large, so it's not trivial to write this layer, but there's nothing specific to Win32 or x86 about it. Mono has already done this (works on Linux, *BSD, OS X, and even Windows) and so has Microsoft (for WinCE).

As for pure torture, have you contacted the Mono devs recently to express your sympathy?

Re:No surprise

[cbhacking]

IE already runs on ARM. WinPhone7 runs an (outdated) version of desktop IE, and will run IE9 in an upcoming update. .NET framework was ported to ARM long ago; in the Windows Mobile/PocketPC days.
Silverlight is the application runtime for Windows Phone 7, so it's fair to say it run on ARM. A browser plugin form of it for that platform is also forthcoming.
Office itself already runs on ARM, again on WinPhone7. The degree of control you can exert over documents is limited (mostly a UI problem), but it will happily read them.

Re:No surprise

[mysteryvortex]

Then there's the reason to run Windows at all - the 3rd party apps that are x86 only (many are not even x86_64 yet) and they won't run either.

The solution to this is something like Qemu's user mode emulation. For those that don't know it will emulate a different processor for the binary, but syscalls are made using native system code.

The Apple approach is actually quite good here, provide emulation support for a while until everybody has time to migrate to native applications. I don't know the details of Apple's emulation, perhaps they are doing something similar to Qemu's User Mode.

-Mysteryvortex

Re:No surprise

[Lennie]

Funny you should mention Intel, Intel actually bought an ARM-division which produced the X-scale processor:

http://en.wikipedia.org/wiki/XScale

The used it in all kinds of things, I think the I/O processors are used in in RAID-controllers.

Re:No surprise

[Lennie]

Sometimes MIPS, sometimes PowerPC, but very likely ARM.

Re:No surprise

[noidentity]

THE show-stopper is malware. It would take years to rewrite that for ARM, which would put this at a disadvantage for years until malware writers had time to port everything. Not even Microsoft can overcome this obstacle.

Re:No surprise

[PopeRatzo]

To think it almost [newsmax.com] happened... Sigh.

Every time you link to newsmax Baby Jesus throws up a little in his mouth.

Re:No surprise

[tepples]

Windows Phone already allows pure IL apps. If they don't intend to allow native code at all it's easier to develop for Android or any other platform. Why even bother.

Because games for Windows Phone are allegedly easily portable to Xbox 360 in the Xbox Live Indie Games environment, modulo a rewrite of the control scheme.

Re:No surprise

[BasilBrush]

I've never owned as ARM computer (just C=6502, 68000-60, PowerPC, x86, MIPS, and EE).

You probably own more than one ARM CPU and just don't realise it. They're in most mobile phones. They're in MP3 players, TVs, routers, printers, set-top boxes etc. Depending on who you believe, ARM CPUs have 70-90% of the embedded market.

Why do you think ARM will be a dominant brand in the coming years, instead of the low-power Intel units? (just curious)

I think it already is. Around 5 billion ARM CPUs ship per year. Compare and contrast with 385 million PCs per year. Total. Not just PCs with low power Intel units. And there's not much other use of X86 processors besides PCs.

Re:No surprise

[AvitarX]

Didn't Ms buy a CPU virtualization company, and use it to decent effect on the Xbox 360?

U bet they can do this to a level that gets office style apps running decent.

A level of basic testing and a cert for apps that pass. Use .Net to aid the process, typical GUI apps should work without too much effort. The more complex stuff will hopefully be re-written (something like google earth maybe) or too much for it to run anyway (like Maya).

Re:No surprise

[Anonymous Coward]

Best go back to Tennessee, Jed.

Re:No surprise

[jmorris42]

> Why not? It's C++ code and runs on x86-32, so it will
> almost certainly run on ARM with a straight recompile.

And you would be wrong. Microsoft has done ports to MIPS, PPC, Alpha, Itanium and X86_64. The only ports that have been able to run Office is x86_64 because it can run the x86 version and Alpha because that bad bitch kitty had enough advantage over Intel parts of it's day it could run an emulator for x86 at a good enough clip to let folks run Office. ARM can run in the same weight class with Intel parts but has nowhere the performance advantage to consider emulation. So no, it is doubtful Office is going to be up on ARM anytime soon unless MS has been running a secret project for the last few years.

Besides, forget an ARM port of Windows. Ain't happening. Any future commercial OSes are going to be Xbox/iPad lockdowns, not the more open environments we grew up thinking of as operating systems. Once Apple proved 3rd party vendors would give up a non-trivial percentage of all sales the days of allowing customers to install anything they want was dead. Ya want that freedom back? Come to the Penguin.

Re:No surprise

[RaymondKurzweil]

Your post is an exquisite cornucopia of fail. "ARM can play..." but "ARM can't". Thinking an iPad is a representative example of all ARM chips or thinking it is representative of anything more than a toolbag's status symbol. Newsflash, numerous ARM SoCs (including those used in mainstream Android phones) include hardware video decoding for MPEG-2 and MPEG-4, and many of these ARM based chips can easily decode MPEG-2 in software and can DMA that to the display.

I would actually be surprised if the iPad couldn't easily decode MPEG-4, because I thought they designed a custom ARM SoC for that thing. But then again, I always assumed it was a piece of shit anyway.

Re:No surprise

[ChunderDownunder]

Premature much? - baby Jesus isn't born yet. You'd think a pope would know this :)

Re:No surprise

[BasilBrush]

OTOH, the ARM can play back MPEG2 and DIVX content. ARM can't. ...and yes, I've tried this on an iPad.

Oh yes it can. Given the software to do it. CineXPlayer plays DivX movies on the iPad.

Re:No surprise

[BasilBrush]

Nobody is suggesting ARM as a replacement desktop CPU. But for netbooks and tablets, it's competing against the Atom. And for that it's processing power is in the same ballpark, whilst being much smaller and lower power. That's why Microsoft has to get WIndows running on it. Because they can't make WIndows tablets that are competitive with the iPad unless they do. Not because they imagine ARM replacing X86 on the desktop.

Re:No surprise

[shutdown -p now]

Actually, I can easily imagine ARM nettops as well. They'd have to come later, at the point where enough applications have been ported, but generally speaking, why not? Low power consumption is a feature in and of itself.

Re:No surprise

[shutdown -p now]

Windows and .NET are so fat and bloated that it'd be a miracle if there was a single ARM platform that could competently execute a JIT application.

All third-party Windows Phone applications are .NET apps. Yes, it's a slimmed-down version of the framework, but it still does JIT.

And guess what architecture do all WP7 phones use?..

Re:No surprise

[shutdown -p now]

Microsoft mobile OS (WinCE - and more specifically WinMo and WP7) has been available on ARM for ages. In fact, most of the devices running it in the recent years were built on ARM. The only news here is that desktop Windows is being ported.

Re:No surprise

[jonbryce]

and then sold it in 2006.

Re:No surprise

[Fizzl]

By your id, I'd imagine you were chewing on punch cards when the dinosaurs roamed the earth, but you seem to be fucking clueless about ARM.
ARM is not "a processor" or a specific set of instructions.
There IS a specific set of ARM designs that are "industry standard", such as ARM%, THUMB, Cortex, etc. It is cheap to license one of these, fab your own and be compatible with everyone else who licensed the same stuff. ARM processors are not "unable" to do anything. They are complete processors and by definition can do anything you throw at them. If you want to decode blueray faster -- fine -- just spec a proc with a dedicated unit for it. Or use a separate die for it.

ARM is a god damn godsend compared to other designs at the moment. In fact, I'm not sure if anyone could streamline chip design like that in next 10 years like ARM has done.

Anyway, consider yourself scolded by a kid who is a certified lauterbach ARM debugger and has prodded pretty much every Nokia device in between 2001-2008.

Re:No surprise

[Alioth]

ARM *already is a dominant brand*. ARM outships all other processor architectures (including x86) put together already.

Re:No surprise

[obarthelemy]

i really don't understand what you're talking about. ARM is first and foremost an architecture+ instruction set, like x86. The architecture is Turing-complete (really !) and can do anything a modern CPU can. Assembly language looks marginally more grokable than x86, and instead of a duopoly controlling implementation, you've got several designe house licensing the IP and developping chips with it, allowing for much more flexible and varied chips and SOCs.

It's just now moving out of it's initial very-low-power niche, and currently tops out at 1Ghz, single-core. There's many-cores and higher clock speeds on the way, and design houses have already tacked on "powerful enough" video and graphics units onto it, ie it can now decode HD, and play with reasonnable FPS at lower resolutions. Again, there's better stuff on the way, and no inherent limitations.

My take is today's best ARM offerings are more powerful and capable than the Celeron 750 I was using not so long ago, and which was perfectly OK for what I was doing with it.

OTOH, x86is not a very elegant architecture to start with, and has a clunky ecosystem with Intel controlling the design and the implementation, with AMD putting in an occasional appearance, and VIA pretty much wiped out.

I'm very enthusiastic about ARM. I see the basic architecture as better, the ecosystem as more efficient, and the whole thing as a chance to break out of the WIntel duopoly which has been gouging us and stifling innovation for decades now.

Re:No surprise

[Chrisq]

There will always be someone how hasn't owned some particular thing, yet that thing can be popular.

I have to agree. I've never owned a sex slave.

Re:No surprise

[obarthelemy]

to answer your specfic remark about ARM not being able to do things that are not in hardware

1- probably not, I can't think of anything ARM can't inherently do
2- even if, the great thing about ARM is that chip houses CAN tack on any hardware required for stuff that's important enough.

Re:No surprise

[gtall]

Technically, to be Turing complete, it would need an infinite memory size.

Re:No surprise

[seeker_1us]

I believe your information about the atom series is outdated.

ARM core designs can be licenced and integrated into SOC (system on a chip).

With Atom you need the Atom chip plus a northbridge chip, with ARM you can use a single chip.

Re:No surprise

[JamesP]

It is the same situation as MONO. You can write an app that will run on .NET in Windows and Mono in Linux. Write once and compile for each platform.

You usually don't have to recompile for MONO. The same binary works!

(windows.forms .exe and server .dll yep, it works)

Re:No surprise

[GameboyRMH]

Haha what? How is ARM crippled? "Unable to do things that are not specifically built into the hardware?" WTF?

I could switch to a laptop with a Marvell Armada tomorrow, and if I didn't have WINE on it (for running architecture-specific closed-source apps), apart from the drop in performance (down to Atom levels, still not a huge deal), near-elimination of heat and huge improvement in battery life, I wouldn't notice the difference. Atoms are a big improvement from traditional x86 CPUs in efficiency, but they're still not in the same ballpark as an ARM CPU.

My N900 has an ARM CPU, and the only reason it can't do everything an x86 PC can is the lower processing power. There are many netbooks with ARM CPUs.

Re:No surprise

[GameboyRMH]

There are many multicore Ghz-speed ARM-based CPUs on the market, such as:

TI OMAP 44X0 series (1-1.5Ghz dual core)
Marvell Armada (1.5Ghz dual core)
Samsung Orion (1Ghz dual core)

Re:No surprise

[gbjbaanb]

I think he meant, much of the .NET framework is just a wrapper round the Win32 API, so porting .NET would require porting a huge amount of old native code. I'm sure that's doable by Microsoft's army of coders, but don't assume it'll happen overnight with a re-compile of all your apps.

And besides, a lot of business apps out there are win32/x86 only, they're the ones to worry about. Which I suppose could be part of Microsoft's strategy to make everything .net only.

Re:No surprise

[GameboyRMH]

Routers are probably more MIPS than ARM, but ARM is in almost every phone or PDA ever made. I can't think of any with a non-ARM CPU. Most digital cameras use ARM-based CPUs too.

Re:No surprise

[GameboyRMH]

Who modded this troll? Mod parent Informative!

Re:No surprise

[GameboyRMH]

I can confirm it runs on an N900. The interface is cramped as hell (it's worse than running GIMP on that tiny screen actually), but it is usable.

Re:No surprise

[gbjbaanb]

Phone Office isn't Office though, itas a cut-down mini-me version. So they can have that almost for free, but the full-blown Office is a different beast (ie a beast). They do have a 64-bit version but I wonder how much of that is actually 64-bit code and not just a ton of 32-bit still in there. By all accounts Office isn't the cleanest, simplest code out there (it has been evolving for years after all).

So, I think a port will be possible, but it'll take a lot of resources - it is, as you say, a un-managed app that requires porting effort, not a recompile.

Re:No surprise

[GameboyRMH]

Huh didn't know that. .NET apps are first compiled into an intermediate language for distribution and are then compiled into native code, I presume on launch. Is that why all .NET apps take forever to start?

Re:No surprise

[sgtrock]

Translation: Novell's LDAP stack works correctly and Microsoft's incompatibility with the standard is regarded by AC as a feature, not the bug it really is.

Re:No surprise

[jedidiah]

All of this nonsense sound like all of the hype and hoopla surrounding Wayland. There are a bunch of academic sounding ninnies talking about academic ideas while actual real world performance is being ignored.

I can get that ARM gravely sacrifices performance for the sake of power usage.

The fans just need to be man enough to fully acknowledge the "grave performance sacrifice" part of this and not try to weasel around it.

One can only reasonably judge a platform based on what's actually out there in the field available to be put through it's paces. While Atom is a good demonstration of how weak the ARM can be, it's also at the same time a good demonstration of the problems of "let the co-processor handle it" mentality of system design.

Fanboy excuses and spin won't alter the task that Windows on ARM is faced with or the fact that far more meagre resources can be brought to bear.

Re:No surprise

[hairyfeet]

But for how long? In netbooks we have never really seen an ARM push, and for good reason. The public looks at those as "baby laptops" and expects them to run the same software as a full size only slower. My local Craigslist is full of ARM netbooks for $50, some even less, and when I inquired why they were selling I was told by several "It doesn't run Windows" which of course means X86 Windows apps which Windows ARM won't fix.

And as for tablets, while it is currently being dominated by ARM I wouldn't count x86 out yet, because AMD will have Bobcat in full production in early 2011. From what I have seen of early tests you are looking at a dual core with a 5xxx Radeon GPU so you have full hardware accelerated everything and even the ability to play games like WoW with some of the settings turned down, all in a chip that uses a MAX 9w with idle power draw of just 0.5w. Now pair this with an embedded Windows variant, something stripped of the cruft like a legal version of Tiny7?

People seem to forget there is a reason why x86 has lasted this long, even after its inventor has tried to kill it repeatedly, including with their own ARM variant. It is the same reason why Linux can't seem to gain any traction on the desktop, it is the huge amount of apps for x86 and the huge amount of time and familiarity that the public has with them. People will put up with the lack of familiar apps on cell phones, because it is a phone. Most see it as a throwaway device and are used to not being able to reuse squat thanks to their proprietary nature. With tablets so far from what I've seen folks treat them like an oversized phone so yet again no complaints about their apps not working because it is "something new" and doesn't have the expectation of running what they are used to. That does NOT apply to netbooks which the public look upon as "mini laptops" and if they start offering Bobcat based tablets it could quickly be the case for tablets as well.

So I wouldn't be fitting x86 for a toe tag in those markets just yet. After all, who wouldn't like to have all their apps and games run on such a convenient form factor?

Re:No surprise

[MightyMartian]

But there's always .NET out there. Yes, you may not see Office, but certainly there is an avenue for producing portable apps that conceivably could run on any port of Windows.

Re:No surprise

[present_arms]

well i guess that Microsoft could just use dosbox on a N900 to test ;)

Re:No surprise

[shutdown -p now]

I think he meant, much of the .NET framework is just a wrapper round the Win32 API, so porting .NET would require porting a huge amount of old native code.

Even if he meant that, he's still wrong: any wrapper around Win32 API would run on a hypothetical Windows ARM port with no changes whatsoever, because such a port would still keep providing Win32 API in its full!

I mean, if you use Linux APIs from your C application, you don't have to do anything special to make it work on a new architecture running Linux other than recompile - function-level interface is still the same.

What more, large chunks of .NET are already ported to ARM - remember that Windows Phone requires apps to be written in a subset of .NET, and hardware requirements mandate ARM CPU for devices.

And besides, a lot of business apps out there are win32/x86 only, they're the ones to worry about. Which I suppose could be part of Microsoft's strategy to make everything .net only.

I don't think businesses are the target audience here - they don't really need the extra portability that ARM would offer, and, as you note, they have more stringent back-compat requirements. Going ARM is clearly an aim at lighter and longer-living netbooks and tablets - the consumer market.

On a side note, ironically, there may well be more business apps written in .NET than consumer apps. When I think about it, most of stuff that runs on my Win7 desktop are native applications, typically written in C++, with only a few occasional .NET ones. But on enterprise Windows desktops, something written in the last 7 years or so is very likely to be a .NET WinForms app.

Re:No surprise

[gig]

EVERYTHING sacrifices performance for power usage. Intel ran P4 at 4GHz but then introduced Core at 2GHz. Why? Power usage.

The key thing is that most computers spend most of their time doing nothing. They are waiting for another keystroke, or another Web page, or sitting mostly idle while the GPU presents a video, or they are sleeping. Most users will not benefit from more computation as much as they will benefit from lower power. A key example of this is 1GHz ARM iPad with 10-12 hour battery and 30 day sleep which has outsold all other tablets, including dozens or hundreds of Intel-based tablets with 3-5 hour battery.

With multiple core ARM even more computation will be available when needed, but cores can sleep, you can still get down to almost no power being used.

Also, ARM is so cheap. You can buy more them than you can Intel for the same money.

Re:No surprise

[gig]

iPad has a built-in, low-power hardware ISO MPEG-4 player, same as all other modern devices. So why are you even trying to play MPEG-2 and DivX? Are you saving your movie collection for someone to invent a time machine? Transcode them to the modern ISO format so they play on portable devices in a small fraction of the battery power.

Re:No surprise

[Billly Gates]

It came with my computer :-)

Re:No surprise

[DaVince21]

One reason could be because ARM is lower-power (by nature). Another could be because the processors have been making more and more of an introduction into computers with the introduction of some ARM-based netbooks and tablets. Realistically speaking, ARM notebooks couldn't be that far away.

Re:No surprise

[makomk]

Even with the Pineview version of Atom, you still need an external I/O controller chip. Said chip is effectively equivalent to the traditional northbridge, except with the memory controller removed. Without the external I/O controller, I don't think you can even bootstrap the CPU, let alone do anything useful with it.

ARM SOCs integrate the functionality of the I/O controller onto the same chip as the processor, including PCIe, SATA, USB, audio...

Re:No surprise

[makomk]

Second, it does not get converted to "win32 calls". It is converted to native opcodes on the particular architecture. All "win32 calls" are in the libraries such as WinForms.

That's the theory. In practice, I don't think anyone's been able to find a WinForms application that doesn't call Win32 APIs directly. It's part of the reason Mono's never put much effort into implementing WinForms.

Re:No surprise

[BasilBrush]

And as for tablets, while it is currently being dominated by ARM I wouldn't count x86 out yet, because AMD will have Bobcat [wikipedia.org] in full production in early 2011. From what I have seen of early tests you are looking at a dual core with a 5xxx Radeon GPU so you have full hardware accelerated everything and even the ability to play games like WoW with some of the settings turned down, all in a chip that uses a MAX 9w with idle power draw of just 0.5w.

Right, so you're talking about a processor that isn't even on the market yet, and consumes an order of magnitude more power than the ARM in an iPad. Which means such competitor tablets will have much shorter battery life, or will be much bigger and heavier because of the size of battery needed. That's exactly what I meant by X86 can't be used for tablets competitive with the iPad.

And of course by the time that processor is on the market, better ARM processors will exist than what is in the iPad v1.

People seem to forget there is a reason why x86 has lasted this long... With tablets so far from what I've seen folks treat them like an oversized phone so yet again no complaints about their apps not working because it is "something new" and doesn't have the expectation of running what they are used to.

So you agree with me that X86 advantage on the desktop does not apply to tablets. And tablets is the reason why Microsoft realise they have to get compatible with ARM.

Re:No surprise

[BasilBrush]

Because when people are attached to mains electricity they don't care so much about power consumption. For sure it's better than higher consumption, but other differences between products are more significant to people. Most people don't even consider how much power a product uses.

It only becomes a factor of product selling importance when it comes to battery powered products, and their size and weight.

Does this article really need to mention ...

[Anonymous Coward]

Meanwhile, many other Linux distros have been shipping on ARM devices since before Ubuntu was a distribution.

Re:Does this article really need to mention ...

[couchslug]

"Meanwhile, many other Linux distros have been shipping on ARM devices since before Ubuntu was a distribution."

I thought Linux was a derivative of Ubuntu! (runs)

"Ubuntu is already starting to ship on some ARM...

[John Hasler]

...devices and running on many others."

Eh. Debian has fully supported ARM for years.

That's nice...

[pushing-robot]

But Windows' main (and practically lone) selling point is that it works with all your old software. If they rewrite it for ARM, it may say "Windows" on it but it won't run your apps or play your games.

And I'm sure users will enjoy discovering that after they buy "Windows" tablets and netbooks.

Re:That's nice...

[MightyMartian]

Microsoft has already stopped supporting a good deal of its legacy software with the 64 bit editions of Windows (no more DOS or Win16 support). Quite frankly, I don't think supporting legacy software is as big a deal as it once was. Write everything under the .NET platform and it isn't that big a deal. Yeah, your old games won't work, but I'm wagering a lot of folks running Windows-for-ARM are not exactly going to be looking at running that old copy of Office 2003 anyways.

Re:That's nice...

[igreaterthanu]

Windows is portable at it's core though, obviously programs will need to be recompiled for ARM, but if they were written correctly this should not really be much of an issue.

Microsoft should be able to get Office to run on ARM without too much hassle, even then the Microsoft Office Web Apps will still work. There are HTML+Javascript and Silverlight versions of these. Both of which should be able to run on ARM, no problem.

Also all programs written in .NET should automatically be compatible without recompiling.

Re:That's nice...

[zn0k]

Uhm, because it's a different CPU instruction set?

Is there some joke I'm missing here?

Re:That's nice...

[rekenner]

Uhm?
No?
That's not how OSes work at all. They mediate programs accessing hardware, not do all the work for the programs. They control what program gets what memory (and if things are in RAM or virtual memory) and take care of getting things from the hard disk, etc. But software runs directly on the processor. That's (part) of what virtual machines do.

Re:That's nice...

[Anonymous Coward]

That could work in their favour, however.

One of the biggest problems with Windows security is the need for backwards compatibility - an ARM version can do without all the legacy support, which would make that version a lot more secure (in theory) and potentially smaller and faster than the x86 versions. It would also allow Microsoft to enforce some of the programming standards (no random 'system' files in programs, nothing writing to \Windows\ and only installers writing to \Program Files\, proper use of \Documents and Settings\\, etc...)

That in turn would make a cull an easier sell for a future x86 version. So, if they use this correctly it could be a huge boon.

That said, most developers will probably just do a lazy recompile of their code for the ARM platform and ship dual-installers on the disk, as happens with OSX applications that still support the PPC machines.

Re:That's nice...

[Anonymous Coward]

Why wouldn't the ARM Windows run x86 apps?

While I think it would be technically feasible, doing so wouldn't be practical in any fashion. Writing a middle layer to translate the x86 instructions to the compatible ARM instructions would be a worse task than trying to develop a C compiler using COBOL. The first, and biggest, problem I see is taking the CISC from the x86 and breaking it into the multiple RISC commands ARM is designed to see.

If they managed to get this right, I would suspect even 10-15 year old applications running slower than frozen molasses in the middle of an Arctic winter.

Re:That's nice...

[jawtheshark]

Troll or serious question?

Every CPU architecture has its instruction set and to run the code it needs to be in that instruction set. Imagine that the code 01 means ADD 1 to the Accumulator on architecture 1, but 01 means apply NOT on the Accumulator. So, the "same" instruction means something completely different on the two architectures.

The task of the operating system is not to abstract the hardware from the software in that sense, because the software that runs is still in pure machine instructions (It's the only thing your machine actually understands). The task of an operating system (as we know them today) is to provide a way for the machine to use the resources in a (relatively, for coders) easy way. Programs running on the operating system still need to be compiled, which results in the binary which are nothing more or less than numbers having meaning to the CPU. You change the CPU, you must change those numbers.

If you think of libraries... Yes, they make it easier for applications to be more portable, but still in the end the binary must match the binary of the library. There is no way around it

What you want would be a kind of on the fly compiler or interpreter, which was the original goal of Java. Java Chips would be there "any day now". Not many around, eh?

Your vision on what an operating system is, seems a bit off.

Re:That's nice...

[commodore64_love]

Okay I was wrong. (shrug) I knew old OSes provided little protection (which is why Amiga500 programs often don't run on newer A3000/4000 machines), but I thought modern OSes blocked the software from running directly on the hardware, so then it could run on a wide range of setups. Oh well.

Re:That's nice...

[TheNarrator]

x86 is such a funny architecture. If you've ever done operating system development in x86 it's crazy to see how much old crap there is in there from the 80s. Real Mode! Hello? Not to mention such inglorious hacks as getting the keyboard controller to reset the CPU!

Re:That's nice...

[jo_ham]

Which is why Apple wrote a translation app called Rosetta to enable PPC-only binaries to run on Intel Macs (while pushing for universal binaries, since using Rosetta is obviously slower). It wasn't quite full emulation like a VM - just a dynamic translator, so it had some limitations but it was pretty successful in most cases.

I have no doubt the same could be done for x86 software written for Windows.

Re:That's nice...

[jawtheshark]

I thought modern OSes blocked the software from running directly on the hardware

In the end.... everything that runs on your machine, runs directly on the hardware. Even Java Applications, even Perl scripts... They just are passed through layers and layers and layers of checks and sandboxes, but in the end, what has to be done is done on the hardware. Directly. There is no magical layer which does the work without the CPU, you know.

Re:That's nice...

[contrapunctus]

i believe he's talking about emulation like rosetta on OS X.

Re:That's nice...

[zn0k]

The advantage ARM has over x86 is that is much more efficient when it comes to power requirements. This comes at a trade off in regards to speed. When Apple went Intel they had at least equivalent processors, and Rosetta often was quite a bit of a dog.

Running an x86 emulator on ARM doesn't sound like a very good idea at all. Binaries made for very fast processors running emulated on a slow processor would be a bad user experience, and there's quite a lot of evidence that in the mobile space the average person values user experience over everything else.

Re:That's nice...

[Etherized]

But Windows' main (and practically lone) selling point is that it works with all your old software. If they rewrite it for ARM, it may say "Windows" on it but it won't run your apps or play your games.

And I'm sure users will enjoy discovering that after they buy "Windows" tablets and netbooks.

I would be very, very surprised if they would port Windows to ARM and *not* include something like Apple's Rosetta. Sure, you take a performance hit when running legacy, crusty apps, but considering that those were probably designed for much slower computers originally it hardly matters if you're running them with a hefty performance penalty now. I know I was quite pleased with the PPC -> Intel transition process on my Macbook Pro.

Re:That's nice...

[petermgreen]

The OS does abstract the hardware to some extent but in almost all cases the application code still runs directly on the CPU (with the CPU running in an "unprivileged" mode so the user code can't just do what it likes).

It IS possible to add CPU emulation to an OS, indeed it's been done at least three times I can think of in operating systems from major vendors. However it carries a significant performance penalty.

The performance penalty is tolerable if your new architecture is faster anyway and you don't care too much about power (e.g. when apple went from m68k to PPC and from PPC to x86 and when NT was ported to alpha) but I'd expect it to be a problem for running existing windows software on arm. I very much doubt an arm running x86 code in emulation will be competitive on either performance per watt or overall performance witha true x86 chip.

Re:That's nice...

[Bert64]

The OS provides an API layer at the code level, that is if you have source code you can usually recompile it to work on different architectures...

This works well on Linux, because the source code for most applications is available making it easy to port apps to other architectures... On windows, the sourcecode for most apps is not available and the owners of most of this source won't recompile their apps unless there is a sufficiently large market for them, and will usually take quite a long time to do the porting... Users similarly won't buy the hardware unless apps are available, catch-22 situation.

The only things that would work, are apps which don't come as machine code... That is, apps with source, or apps in a language thats compiled to hardware neutral bytecode such as java.

Most windows apps come in the form of x86 specific binaries, and these would only run on ARM if you used emulation... Emulation is slow at the best of times, but when you consider that ARM cpus are generally designed for power efficiency and lack the raw performance of x86 chips... The extra overhead of emulation would result in code which performed terribly and kept the cpu running flat out negating the power efficiency.

Re:That's nice...

[gilesjuk]

ARM is a RISC design. It's easier to emulate CISC on a RISC than RISC on a CISC.

Re:That's nice...

[pushing-robot]

There's a lot of things that won't run under Rosetta. Besides, Rosetta was emulating a RISC architecture on higher-powered CISC chips. This would be emulating a CISC architecture on lower-powered RISC chips. Good luck.

Re:That's nice...

[contrapunctus]

"like rosetta" not rosetta

Re:That's nice...

[damnbunni]

Not only could be done, it has been done.

Windows NT/Alpha could run Windows NT/Intel programs via Digital's CPU Transcription software.

It worked two ways: When you first ran a program it just ran in a Pentium emulator. Then, later on in the background, the transcription engine would disassemble the Intel code and reassemble it as Alpha code. It still wasn't as fast as actual Alpha code, but it was a lot faster than the plain emulator.

At the time, the fastest Alpha was enough faster than the fastest Intel that some Windows/Intel programs ran faster on the Alpha than on a Pentium.

Re:That's nice...

[commodore64_love]

Classic Max OS 8 and 9 did that (if I recall correctly).

It emulated 68000 CISC apps on the new PowerPC RISC machines. Although not very well. I remember the first PowerMac was slower than the 68040 QuadraMac, when running classic apps like WordPerfect, Eudora, and so on. For awhile I specifically avoided the PPCs when going to the college lab, since the Quadras ran faster.

Ahhhh... those were the days (1996). Even the college line loaded the Web as slow as a dialup connection. "Looking for scifi.com"...... "Finding scifi.com"..... loading scifi.com/index.html..... loading scifi.com/titleimage.com. I became very familiar with that animated Netscape logo as I stared at it, and wondered if my page would ever load: http://upload.wikimedia.org/wikipedia/en/7/78/Netscape_throbber_2.gif

Re:That's nice...

[Bert64]

There are many security weaknesses that are externally exposed design flaws, and could not be dropped... Such as the use of weak password hashing types which are integral to the networking protocols (google for pass the hash).
If they fixed this, you would lose the ability to use most of the ms networking protocols.

Re:That's nice...

[the linux geek]

It worked pretty well with Itanium. Applications generally ran transparently, at roughly the same speed as a Xeon at the same clock speed as the Itanium (1.4-1.7GHz). Some stuff (later versions of Office) specifically checked for IA64 and refused to install, but even these had workarounds.

Re:That's nice...

[guruevi]

but if they were written correctly this should not really be much of an issue.

Even open source programs that are intended to run on multiple platforms suffer from developers fixing stuff for theirs and unintentionally breaking stuff on other platforms. If you've ever done it, you know it's actually a major issue unless you write very good code without shortcuts/optimizations or you write in an interpreted language.

Microsoft should be able to get Office to run on ARM without too much hassle, even then the Microsoft Office Web Apps will still work. There are HTML+Javascript and Silverlight versions of these.

A browser-based application will work even on non-Windows systems. Running a full-blown Office on ARM is going to pose some serious problems. Even Office for Mac or the versions they had for Windows Mobile had major issues and they didn't ever port Visual Basic Script or ActiveX on those platforms. They did rewrite versions of Word, Excel and PowerPoint but they were majorly different than their Windows counterparts, even in their layout-engine.

Also all programs written in .NET should automatically be compatible without recompiling. .NET has been touted as an interpreted language but I haven't seen even a single concept where it runs on other platforms. A lot of .NET applications still have legacy Win32 in it somewhere and even the libraries are very closely linked to Win32. Besides, JIT has never been very good in .NET, I wouldn't give it much better chances on the classically less powerful ARM chips.

Re:That's nice...

[Score Whore]

Well, Java apps and Perl scripts are more data than program (yes I know about JIT.) Which should illustrate to you how a different architecture could provide the mechanisms for running legacy code. Hell, outside of the mobile market the runtime compiled code could be saved and then used in lieu of the foreign code on future invocations. The very good chunk of software would run just fine in that kind of environment. Even drivers could be implemented this way if so desired (barring any timing loop issues.)

Re:That's nice...

[TheRaven64]

Apple wrote a translation app called Rosetta

No, they didn't. They licensed it, from a company that is a spin-out from Manchester University. The same software has also been licensed to a few UNIX vendors to allow them to run legacy code on other architectures (and, in a few cases, to help customers move from a competitor's system).

It wasn't quite full emulation like a VM - just a dynamic translator, so it had some limitations but it was pretty successful in most cases

It wasn't at all like a VM. The thing that made it perform well was that it was the opposite of a VM - it emulated as little as possible. It provides a mechanism for including stub libraries, which trap out of the emulator. When you call a function in one of the stub libraries, it tweaks the arguments (swapping byte order and so on) and calls the native version. Since a typical program spends a significant proportion of its time in third-party libraries, this means that even a relatively poor emulator[1] can achieve good performance, because all of the time spent in Apple-provided libraries is spent running native code. This includes all of the Cocoa frameworks, CoreGraphics, and so on. Complex things like text layout and antialiased rendering are all done in the native code.

Microsoft could easily license the same code and include it with Windows. Almost anything in a system DLL would be native. For a typical app, this is quite a lot of the total run time.

Re:That's nice...

[ChunderDownunder]

china's MIPS clone has x86 emu assist. Not ARM though!

Re:That's nice...

[jawtheshark]

In a Von Neumann Architecture, Data and Programs are the same. In the strict sense of the word, even compiled code is data. So just differentiating Java Apps or Perl scripts from compiled code makes no sense.

It's not impossible to do this translation (thinking of Rosetta here), but is it the task of the operating system? That's pretty much what commodore64_love was insinuating.

As for drivers... How can you even mention so casually "apart from timing loop issues"? The reason they're drivers is because they have these issues, otherwise it could simply be implemented in user space.

Basically, if you want this, you need an operating system that provides only a managed Virtual Machine (in the Java sense) and you can only implement on that. To gain backward compatibility (which this ARM/x86 thread is about), you'd need a VM that does x86 on any architecture. That is called emulation and is slow. Try Bochs someday.

Re:That's nice...

[igreaterthanu]

Even open source programs that are intended to run on multiple platforms suffer from developers fixing stuff for theirs and unintentionally breaking stuff on other platforms. If you've ever done it, you know it's actually a major issue unless you write very good code without shortcuts/optimizations or you write in an interpreted language.

I agree, but as I said if they have written it correctly. Any recent Windows software should already be written for both x86 and x64. That alone should remove most portability related bugs.

A browser-based application will work even on non-Windows systems. Running a full-blown Office on ARM is going to pose some serious problems. Even Office for Mac or the versions they had for Windows Mobile had major issues and they didn't ever port Visual Basic Script or ActiveX on those platforms. They did rewrite versions of Word, Excel and PowerPoint but they were majorly different than their Windows counterparts, even in their layout-engine.

The Silverlight versions of Microsoft Office Web Apps have all the features most consumers would be using anyway.

Mac is a complelty different platform to Windows. Same goes for Windows Mobile, it's not really Windows at all. Windows on ARM is quite similiar to Windows on x86, especially in terms of the API.

Also all programs written in .NET should automatically be compatible without recompiling. .NET has been touted as an interpreted language but I haven't seen even a single concept where it runs on other platforms. A lot of .NET applications still have legacy Win32 in it somewhere and even the libraries are very closely linked to Win32. Besides, JIT has never been very good in .NET, I wouldn't give it much better chances on the classically less powerful ARM chips.

Probably this is because Microsoft only has an implementation of .NET that runs on Windows. Mono works fine on Linux and OS X.

As for being tied to Win32 you are probably refering to System.Windows.Forms which is mostly just wrappers for Win32 code with a few bits of syntax sugar. Mono has implemented System.Windows.Forms in it's entirety so any .NET applications that run on Windows using only the built in APIs should run fine on Linux. (With the exception of WPF and a few libraries that are not commonly used). It is quite rare to reference Win32 or COM directly from .NET code.

Re:That's nice...

[shutdown -p now]

Microsoft has already stopped supporting a good deal of its legacy software with the 64 bit editions of Windows (no more DOS or Win16 support).

Not quite - you can still run those virtualized in XP Mode.

Re:That's nice...

[Rockoon]

Quite the opposite is true.

Emulating the x86 instruction set with regards to its flags register will take considerable development effort, and thats just one thing.

RISC is much easier to emulate on CISC.

Re:That's nice...

[Score Whore]

Outside of theoretical concepts there's an easy way to tell if something is instruction or data: Does the processor's IP ever point to the relevant address in memory? The answer for Perl and non-JIT java is no.

It's easy to casually mention binary translation for drivers because my parenthetical is going to be rare in an environment, like Windows, where the hardware ranges from single-core mobile atoms on the low and to multi-socket, multi-core Nehalems on the high end. Getting timing by way of executing a known number of instructions is going to be highly ineffective.

On most common OSes drivers are implemented outside of userspace because of OS architectural decisions, not because of any fundamental need to run at kernel level privileges. The OS could provide access and primitives that would allow drivers to run in user space. It's just not done due to complexity and for performance. We already see some types of pseudo drivers that run in user space. Going forward this will likely become more common in order to protect the system from bad drivers.

Binary translation would be fine, no need for emulation.

Re:That's nice...

[Guy Harris]

but I thought modern OSes blocked the software from running directly on the hardware, so then it could run on a wide range of setups.

It depends on what you mean by "on the hardware". Modern OSes generally don't allow user-mode code to directly access the control registers of peripheral devices, bus controllers, etc., and run them in a mode where memory addresses are virtual addresses translated to physical addresses by the memory management unit. This isolates applications from the details of how physical memory is laid out, what I/O buses you have, what controllers you have for those buses, etc..

Most of them do, however, run user-mode code that is supplied in the form of machine-language code, so they don't isolate applications from the instruction set of the processor on which they're running.

There are exceptions, such as the system software on IBM's AS/400^WiSeries^WSystem i^Wi5 or whatever it's being called these days. The "machine language" generated by the compiler is translated into executable machine language by low-level system software, which is why they could switch the executable machine language from the old "IMPI" CISC instruction set to a PowerPC variant without breaking binary compatibility for most programs. (I think that, as a disk-space-saving measure, you could delete the "machine language" part of a program, leaving behind only the translated version; if you did that, you'd have a problem running on an AS/400 with a different native instruction set.) This would also work for most if not all applications distributed as, for example, Java bytecode or .NET CLR bytecode.

Some OSes may provide software that can translate machine code for one processor into machine code for another, such as the FX!32 translator in Windows NT on Alpha, translating x86 machine code to Alpha machine code, or the Rosetta translator in Mac OS X, translating PowerPC machine code to x86 machine code.

Re:That's nice...

[yuhong]

To be more precise, some of them relates not to x86 themselves, but how the IBM PC series implemented it.

Re:That's nice...

[tepples]

Even open source programs that are intended to run on multiple platforms suffer from developers fixing stuff for theirs and unintentionally breaking stuff on other platforms. If you've ever done it, you know it's actually a major issue unless you write very good code without shortcuts/optimizations or you write in an interpreted language.

But it's still easier than having to make a complete manual line-by-line rewrite in another language to run on another platform, as one has to do in order to make an app for BlackBerry (JVM bytecode only), Windows Phone 7 (CIL only), and iOS (Objective-C++ only). At least the Android and BlackBerry versions of an app can share everything but the front-end because the Java language compiles to both the JVM and Android's Dalvik VM.

A browser-based application will work even on non-Windows systems.

But how well will it run over an intermittent Internet connection? Besides, Internet Explorer is just as different in its layout engine from other browsers as Office for Mac is from Office for Windows.

.NET has been touted as an interpreted language but I haven't seen even a single concept where it runs on other platforms.

XNA uses CIL on both Xbox 360 (PowerPC) and Windows Phone 7 (ARM). Silverlight uses CIL on Windows Phone 7.

A lot of .NET applications still have legacy Win32 in it somewhere

If apps P/Invoke Win32 functions, the same functions would likely still be present in a port of Windows NT to ARM.

Re:That's nice...

[CAIMLAS]

But Windows' main (and practically lone) selling point is that it works with all your old software.

Maybe to you. To many others, the new Microsoft software - Sharepoint, Exchange, etc. - looks pretty appealing, too. "I can't get Exchange to work on my Blackberry" isn't exactly an uncommon complaint.

The demand is there.

Re:That's nice...

[purplemecha]

How does Rosetta compare to WINE. They sound similar. What if Microsoft were to use WINE to run apps on ARM. :)

Re:That's nice...

[bky1701]

Wine does nothing for incompatible archs. It would need to be heavily modified to be useful. On the other hand, it is probably easier to make wine into a cross-platform windows API than it is to make the current windows API into a cross-platform windows API....

Re:That's nice...

[shutdown -p now]

Even open source programs that are intended to run on multiple platforms suffer from developers fixing stuff for theirs and unintentionally breaking stuff on other platforms. If you've ever done it, you know it's actually a major issue unless you write very good code without shortcuts/optimizations or you write in an interpreted language.

There is a subtle but important difference here: you're talking about different platforms, but the story is about the same platform on a different architecture.

Why this matters: different platforms may support different APIs (yeah, there's POSIX, but there's still a lot of Linux-specific calls, for example), and even for the same calls, behavior may differ in some aspects. This is the most common source of incompatibility.

With one platform, the API remains exactly the same, and so does its behavior. Architecture differences are only breaking for some low-level stuff (e.g. non-aligned access). This is a much smaller class of problems.

NET has been touted as an interpreted language but I haven't seen even a single concept where it runs on other platforms. A lot of .NET applications still have legacy Win32 in it somewhere and even the libraries are very closely linked to Win32.

In this case it doesn't matter, since Windows running on ARM still means the same exact Win32 API.

Besides, JIT has never been very good in .NET, I wouldn't give it much better chances on the classically less powerful ARM chips.

.NET JIT is more naive than HotSpot, especially in terms of advanced optimizations (virtual call elimination, aggressive inlining, stack allocation of objects where possible etc). But this affects all platforms in roughly the same way.

Re:That's nice...

[JamesP]

Great explanation

Even though translating from PPC is much easier than translating from x86 (which of course has been done several times already)

But (program speed) performance from PPC->x86 is likely much better than x86->ARM

and remember Rosetta did not support Altivec

Re:That's nice...

[TheRaven64]

WINE and Rosetta are almost exactly the opposite. WINE provides a mechanism for loading executables for the same architecture, but a different OS. Rosetta provides a mechanism for loading executables for a different architecture, but the same OS. There was some work done by the Darwine team to combine QEMU with WINE so that you could run Windows apps on PowerPC Macs, but there would be no point in Microsoft using this work - they already have a Win32 API implementation that runs on their kernel, and it would make far more sense for them to use this than WINE.

Re:That's nice...

[TheRaven64]

But (program speed) performance from PPC->x86 is likely much better than x86->ARM

In general, it's easier to emulate a CISC architecture on a RISC architecture than the other way around. This is because CISC instructions are generally equivalent to short sequences of RISC instructions (and are microcoded as such), so you end up using the RISC-like subset of a CISC architecture when going the other way, which is not ideal.

Emulating x86 on PowerPC (which VirtualPC did, and at a decent speed - things like bzip2 in an emulated Linux install were well over 50% native speed) was made a lot easier by the fact that PowerPC was designed to make it easy to write x86 and m68k emulators. The same is true of the latest Chinese Loongson (MIPS-compatible) chips, which contain a set of instructions for emulating the x86 instructins that aren't easy to emulate.

ARM was not designed with this in mind, but it is a much more RISCy architecture than x86. A little bit of dynamic feedback can make an x86 emulator a lot faster. One of the nasty things about x86 (from the perspective of a chip designer, as well as an emulator writer) is that a lot of instructions have various side effects (setting condition flags and so on). Very often, these side effects are safe to ignore, but calculating them in the emulator often takes some effort. A dynamic translator can only bother calculating them if they are actually used, and that's one of the things that VirtualPC did.

and remember Rosetta did not support Altivec

It did as of OS X 10.4.3. I actually didn't remember it not supporting it. I used Rosetta to test the AltiVec code paths on some of my code (for correctness, not for performance) and was unaware that it had ever been unsupported.

Re:That's nice...

[JamesP]

About Rosetta, ok, I guess I got it wrong

http://en.wikipedia.org/wiki/Rosetta_(binary_translation_software)

What it doesn't translate are G5 specific ops, but Altivec works

About time

[mirix]

If they want to keep relevant on cheap, portable devices - they'd better support ARM.

Even the atoms use a lot more juice, and for simple appliances ARM can be enough horsepower.

Although - they might be advised not to put too much into it, as I don't think there will be much margin on SW for $200 devices and whatnot... And good luck with getting manufacturers to make ARM drivers, I think they'll be needing it.

Re:About time

[Waffle Iron]

And good luck with getting manufacturers to make ARM drivers, I think they'll be needing it.

They shouldn't even need to bother doing that. They'd be better off if they get with the program: Slap their user space on top of the Linux kernel (which already has all the ARM drivers). That's what Google did with Android.

All the old x86 Win32 API apps won't run on ARM anyway, so the Windows kernel won't enable their traditional strategy of leveraging the installed software base. Instead, Microsoft should just port their .NET runtime onto an ARM Linux kernel and call it a day. A lot of modern Windows software would run on this environment without too much modification, and Microsoft's development and vendor relations costs would be a fraction of that required to develop and distribute a custom kernel.

Of course, hell will freeze over before they go this route.

Re:About time

[John Hasler]

They shouldn't even need to bother doing that. They'd be better off if they get with the program: Slap their user space on top of the Linux kernel (which already has all the ARM drivers).

Thereby making it almost trivially easy to produce a binary-compatible clone.

Re:About time

[Waffle Iron]

The .NET framework is probably more complex than an ARM kernel, and it's peppered with patents. Microsoft will undoubtedly add a bunch of tablet-related patents to the mix. The basic Windows kernel has also already been cloned (WINE). The scenario I described probably isn't significantly more or less cloneable than what they're going to do.

Re:About time

[tepples]

All the old x86 Win32 API apps won't run on ARM anyway

But Silverlight apps surely will, and CE apps might. See my other comment.

Why?

[gilesjuk]

Why port it to ARM and talk about it if there's no clear strategy or reason for doing so?

It's odd that Intel are trying to get people off ARM and onto Atom (low power x86) while Microsoft are thinking of moving people from Intel to ARM.

Re:Why?

[bloodhawk]

WTF? how is there no clear strategy or reason? ARM is rapidily proliferating in low powered devices, it performs better than the Atoms. The strategy is obvious, they need to ensure they are not locked out of a rapid growing part of the hardware market by being incompatible with it.

Re:Why?

[MightyMartian]

Precisely. Besides, any project to produce an ARM-capable version of Windows means that they have a fully portable OS, and are no longer tied to Intel. They tried this in the early 1990s, but Intel's penetration was so great that it didn't make sense to continue putting resources towards Alpha and PowerPC ports. Times have changed, and the proliferation of ARM-based hardware out there is immense.

Re:Why?

[DragonWriter]

Why port it to ARM and talk about it if there's no clear strategy or reason for doing so?

My guess is the strategy and reason for doing so is to encourage device makers thinking about, e.g., ARM netbooks to hold off on committing resources to things like Chrome OS (which Google has made it quite clear they want to be on ARM devices as well as the initial x86 devices) and Ubuntu.

My guess is that Chrome OS is the big trigger, from timing and the fact that Chrome OS is being actively and heavily promoted by a well-funded company that is clearly focussed on competing with Microsoft on a wide range of markets, and for whom weakening Microsoft's OS dominance in the keyboard+mouse/touchpad market is a key lever to weakening (in the case of, e.g., office suites) or preventing (as in the case of, e.g., cloud application hosting) Microsoft's market power in a wide range of other markets in which the two compete.

It's odd that Intel are trying to get people off ARM and onto Atom (low power x86) while Microsoft are thinking of moving people from Intel to ARM.

Microsoft isn't trying to move people from Intel to ARM, Microsoft has realized that stopping people from moving to ARM isn't something they have the power to do, and is trying to minimize the likelihood that those who does decide to use ARM support competing operating systems in the process.

Re:Why?

[Bucky24]

The last I checked Windows (and any program I care to run) will work fine on an AMD processor. So how is that being "tied to Intel"?
And the last time I had an AMD processor in any of my main computers was almost 7 years ago.

Re:Why?

[Guy Harris]

The last I checked Windows (and any program I care to run) will work fine on an AMD processor.

Because the instruction sets of the Intel processors in current personal computers and the AMD processors in current personal computers are (almost) identical. (There are some differences, most of which are, I think, extensions implemented by AMD and not Intel or by Intel and not AMD. Most compilers can probably avoid using those extensions.)

So how is that being "tied to Intel"?

OK, so replace that with "tied to the x86 instruction set". The ARM instruction set is quite different from the x86 instruction set.

Re:Why?

[Bucky24]

OK, so replace that with "tied to the x86 instruction set". The ARM instruction set is quite different from the x86 instruction set.

That makes much more sense. Thanks for clarifying.

Re:ARM now?

[MightyMartian]

And yet many *nixs through the last few decades have managed to port to other architectures. Heck, Linux can be compiled, so it's hardly that big an issue. NT was supposedly built to be portable and crossplatform from the very beginning, and in a way, we already seeing two architectures with 64-bit versions of Windows.

At any rate, the failings on the Alpha had nothing to do with architecture, and everything to do with the fact that, by and large, the Alpha platform failed. If Alpha had in fact taken off I have no doubt that Microsoft would have happily kept producing NT for it.

ARM has already proven itself, and there's a significant argument for Microsoft coming on board. If it doesn't have programmers who know how to manage an operating system codebase across multiple platforms, well, there are several kernel-level programmers out there that could be brought in, but honestly, I doubt it's a problem. I wouldn't even be surprised if they already have the kernel running on ARM hardware, but as the article says, the issues are drivers, just like they were for 64bit versions of Windows when Server 2003 x64 and WinXP x64 came out. The incentive for manufacturers to write Windows ARM drivers is going to pretty huge, so I doubt that will be a problem.

Re:"Ubuntu is already starting to ship on some ARM

[pslam]

Eh. Debian has fully supported ARM for years.

Indeed - I've been using Debian on ARM devices for at least 12 years. I'm always amused when someone new comes along and assumes a big distro running on ARM is a new thing.

Nahh

[Co0Ps]

Streamlined hardware with bloated software? Doesnt sound like a great combo IMO.

Usual Microsoft

[surfdaddy]

Among the steps needed is for hardware makers to create ARM-compatible drivers, a time-consuming effort that explains in part why Microsoft is talking about the initiative well ahead of any products being ready

Isn't Microsoft always talking about initiatives well ahead of products being ready?

Re:Usual Microsoft

[Animats]

Among the steps needed is for hardware makers to create ARM-compatible drivers

That's really Microsoft's problem, not the hardware makers.

Re:Usual Microsoft

[Bucky24]

Well, the way Microsoft treats hardware makers (ie, if you make the hardware and want it to run on windows, you write your own driver), I think it is their problem.

Windows Phone 7

[iONiUM]

As countless articles have already pointed out, it's extremely strange for Microsoft to start "porting" or whatever Windows 7 [embedded|CE|whatever] to ARM. They made a touch interface, they supposedly think it's awesome.. why aren't they using it?

Talk about fragmentation.. This is just making development/platform targeting even worse, with no gain.

Re:Windows Phone 7

[Anonymous Coward]

This is talking about the kernel. Windows Phone 7 has a UI layer that runs on top of a CE kernel - the CE kernel exposes an interface close enough to that of the NT kernel that it's not far fetched to think they could run the Windows Phone 7 UI layer on an NT kernel without a whole lot of changes.

CE made sense when mobile hardware had 4 MB ram and no protected mode hardware or memory map units. Modern mobile hardware looks a lot more like desktop hardware, so it makes sense that they would want to use a mature kernel that was built from the ground up to take advantage of those features.

Re:Windows Phone 7

[Archangel Michael]

Worse than fragmentation is proves what I've been saying (and getting modded "troll" for it) that Microsoft is a Windows company, not a technology company. Everything they do is trying to leverage Windows. Windows on ARM may just be the stupidest thing they've done. It is as if to say "Me Too On Arm" just to say it.

Someone needs to fire the board, the top managers and start making some real gutsy calls on direction of the company, or else Apple will eat them for lunch as they keep chasing what Apple and Google have already done.

I'm kind of feeling sorry for the once great giant these days. They just can't seem to get things right.

Re:Windows Phone 7

[cbhacking]

Um, where does it say anything about porting Windows 7 (from anybody who knows the difference between a kernel and a colonel)? They're porting *NT* to ARM, and that makes all kinds of sense. For example, it lets the move WinPhone7 off of CE (which, despite all the work that has gone into it, is still an inferior kernel in many ways) and onto NT (much like Apple did with XNU/iOS, or Google with Linux/Android).

This frees up resources from developing and maintaining WinCE, and adds a lot of capabilities to WP7 at the same time. Hell, they might even release a native SDK at that point; if they've been planning to do this all along it makes sense to not publicly offer native apps on a platform that is going to have its kernel swapped out in a year or three.

Also, who ever said they aren't using that nice touch interface? Microsoft could put a WP7-style interface on a much larger device. Remember, this isn't about Windows 7, it's about future products. There's no reason a Metro-style UI couldn't run on NT, either on a phone/PDA-style device, or a much larger tablet/touchscreen computer.

Re:Windows Phone 7

[Archangel Michael]

No.

They had a great opportunity to do something awesome with Windows recently. They blew it... twice.

They could have made Windows Vista/7 64bit only. Leave XP on 32 bit only. They could have killed the cruft of backwards compatibility once and for all.

But that would have required forward thinking AND risk taking.

Linux on Arm isn't so bad, because Linux is just a kernel. The rest of the OS could be anything, as Android is.

Re:Windows Phone 7

[xigxag]

Apple and Google aren't eating Microsoft's lunch. Admittedly Microsoft isn't so dominant as it used to be, but this is supposed to be a good thing for consumers, right? Not a cause for alarm.

In their most recently reported fiscal quarters:
Apple revenue of $20.34 billion, net profit of $4.31 billion
Google revenue $7.29 billion, net profit of $2.17 billion
Microsoft revenue $16.20 billion, net profit of $3.25 billion. Revenue was a MS all-time quarterly record, in fact. And the profit shattered estimates and was up 51% from last year.

Re:Windows Phone 7

[drsmithy]

They could have made Windows Vista/7 64bit only. Leave XP on 32 bit only. They could have killed the cruft of backwards compatibility once and for all.

How ?

Re:Windows Phone 7

[shutdown -p now]

They could have made Windows Vista/7 64bit only. Leave XP on 32 bit only. They could have killed the cruft of backwards compatibility once and for all.

It's also an extremely good way to get rid of most of your paying user base (which is enterprises).

Re:Windows Phone 7

[Archangel Michael]

Not really. They could do something like help WINE project and get it out of "beta" and leave the pieces for the "community" to support. A form of "Embrace (wine), Extend (wine), Extinguish (win32).

Re:Windows Phone 7

[shutdown -p now]

What does Wine have to do with a 32-bit to 64-bit migration at all? Wine is just an alternative implementation of Win32 API on Unix-like systems. It doesn't have any form of CPU emulation - it runs native 32-bit code as native 32-bit code, just providing it the API it expects to see. It wouldn't help to run 32-bit applications on a 64-bit-only OS.

Unless I'm misunderstanding what you mean, and you actually meant to say that there should have been no 32-bit editions of Vista/7 (but 64-bit editions should still be able to run 32-bit apps, as they do today). In which case the answer is even simpler: netbooks don't have x64 CPUs, and, of course, Microsoft wants Windows to run on them.

Re:"Ubuntu is already starting to ship on some ARM

[Yvan256]

Ubuntu is the Arduino of Linux distros.

Come on RISC OS!

[QJimbo]

Everyone is rushing to get on the platform you were running on twenty years ago!

Time for you to make a dramatic comeback and show how an ARM powered Operating System is done properly.

Re:Come on RISC OS!

[acid_andy]

Hear hear! Wish I had some mod points....

Why Windows?

[Yvan256]

Why are they trying to keep Windows? Yes it's a well-known brand name, but so is Microsoft. All they have to do is create a tablet-specific OS and leave all the compatibility headaches behind. And even without any compatibility headaches, most Windows applications weren't written with a touch interface in mind, so having a goal of Windows on a tablet is just asking for trouble.

Microsoft has an opportunity to start fresh, leave the Windows problems behind and create something new. But yet they don't.

Re:Why Windows?

[Rockoon]

And even without any compatibility headaches, most Windows applications weren't written with a touch interface in mind

Are you missing the part where it will be using ARM CPU's, thus what "most windows apps" are doing is moot?

This is like pointing at a Linux tablet and asking "Why are they trying to keep Linux?"

Re:Why Windows?

[ByteSlicer]

All they have to do is create a tablet-specific OS.

You mean like Windows CE?
Even though it shares the 'Windows' name, it's a different OS (only reusing some of the Win32 and .NET APIs), with different kernel flavors, one of which targets ARM (and has done so for over 10 years).

Re:Why Windows?

[DragonWriter]

And even without any compatibility headaches, most Windows applications weren't written with a touch interface in mind, so having a goal of Windows on a tablet is just asking for trouble.

ARM is not the same thing as touch. Google has been rather upfront in that while the first consumer netbook for Chrome OS following the Cr-48 pilot device will, like the Cr-48, be Intel devices, they really want to get hardware partners for ARM-based Chrome OS netbooks, as well, and eventually they want to deliver (via the Portable Native Client technology now in development on top of the existing x86/ARM Native Client that allows platform-specific native code to run in the Chrome browser) "native" Chrome OS apps in LLVM bitcode that can transparently be run as sandboxed native apps on both x86 and ARM (initially, and potentially more architectures over time) systems without any need to maintain separate source code or even separate architecture-specific builds.

Re:Why Windows?

[Grishnakh]

In case you haven't noticed, Microsoft has never been very creative when it comes to naming their products. "Windows"? It didn't take any genius to think of that one. "Internet Information Services"? Can you think of a name more boring and generic? Their more clever names (like "Excel") are for products they purchased from other companies long ago, and they took the names from there rather than creating their own.

Re:Why Windows?

[master_p]

They could named their new O/S "Windows NG", for 'next-generation'. They could run legacy apps via emulation...

Pushed by Chrome OS?

[DragonWriter]

With the Chrome OS hardware/software in a kind of semi-public test phase with fairly imminent general release, even though the initial hardware (both the Cr-48 and the announced initial planned consumer units) is x86, there is some pressure on MS, since Chromium OS -- including Native Client -- as I understand is already working on ARM and Google has stated that they intend to work with hardware manufacturers to get branded Chrome OS delivered on ARM devices.

Announcing plans for Windows on ARM is potentially a way to try to dilute manufacturer support for Chrome OS on ARM to avoid or at least mitigate Google getting a foothold in the OS market at the inexpensive end of the keyboard & pointing device market that Windows still dominates.

Especially once Portable Native Client is working (delivering code over the web in LLVM bit code form that is verified on the client and compiled to native code for x86, ARM, and potentially future supported platforms) rather than NaCl only using platform-specific compiled code, Chrome OS may be one of the strongest challenges MS has seen in that market since its dominance was established.

Re:Pushed by Chrome OS?

[tepples]

Especially once Portable Native Client is working (delivering code over the web in LLVM bit code form that is verified on the client and compiled to native code for x86, ARM, and potentially future supported platforms)

If they're going that far, then why not just have LLVM recompile Dalvik bytecode to x86, ARM, etc.? Oh wait, because that would be too much like Android.

Re:Pushed by Chrome OS?

[DragonWriter]

If they're going that far, then why not just have LLVM recompile Dalvik bytecode to x86, ARM, etc.?

I would expect that at least one of the options on the table for Chrome/Android convergence -- which Google has been open is the long-range plan -- is either a Dalvik/PNaCl bridge (so that Dalvik bytecode would be converted to PNaCl wire format for transfer and executed via NativeClient) or using Dalvik bytecode as an alternative wire format to PNaCl using the same basic infrastructure.

Oh wait, because that would be too much like Android.

While Android and Chrome OS have different initial target markets and short-term priorities, Google has never made it a secret that they see the two as, in the long term, converging. So, no, I doubt that "that would be too much like Android" is a reason to reject an approach in Chrome OS.

Re:"Ubuntu is already starting to ship on some ARM

[tukang]

If you don't mind could you please share more about your setup and what your user experience is compared to any other x86 systems you have? Thanks

Re:ARM now?

[Bert64]

NT was actually more stable on Alpha than it ever was on x86...

Drivers are not really a problem for ARM, since most of these devices will be small (tablets, netbooks etc) with fixed hardware, the hardware manufacturer will supply the necessary drivers.

The problem is apps...
Existing windows apps would need to be at the very least recompiled (or may require significantly more work depending on the code), and with most apps being closed source only the original vendor is in a position to do that... Now as with alpha, ppc mips and ia64, commercial vendors won't port their apps unless they see a market for them... And end users wont buy the platform unless they see available apps, catch 22.

Linux doesn't really have this problem because the vast majority of applications are open source, and have already been compiled for multiple architectures. If the original author hasn't ever tried to compile the app for another platform, chances are one of the distributors has (debian has been supporting arm cpus for years)...

The only advantage ARM has over alpha/ppc/mips/ia64 is cost of hardware, if those platforms had been price competitive with x86 they would have had a lot more sales to linux users (i know many people who wanted an alpha but just couldn't justify the cost).

There is a lot to be said for writing new applications which are actually designed for a tablet or netbook, rather than trying to shoehorn desktop apps onto small devices with different input methods... But if you're going to write new apps, why bother writing them for win32/arm instead of simply writing them for linux?

The only advantage windows has in this area is familiarity, they would lose their traditional selling point of compatibility/lockin, if you go arm you will need new apps regardless and if people have learned anything over the past 15 years they should take this chance to break free of the lock-in rather than getting caught up in another round.

Windows Has Been Running On ARM

[nato10]

This is a strange article; Microsoft has had their Win32-based Windows CE operating system running on ARM processors for 14 years. In many respects, Windows CE (now called Windows Embedded Compact, for some confusing reason) is a far superior operating system to desktop Windows, especially for the sorts of devices that are going to typically be running ARM processors.

Microsoft had the right idea 14 years ago; create a new operating system from scratch that is appropriate for lower-power processors and provide as much API compatibility as possible but without layering on all the bloat. They'd be better off moving Windows CE to the desktop -- preferably with a modern graphics API and touch support -- something like what Apple is trying to do with iOS.

Re:Windows Has Been Running On ARM

[DragonWriter]

Windows CE (now called Windows Embedded Compact, for some confusing reason)

Probably because it avoids the natural abbreviation of Windows CE to WinCE, which is undesirable (from Microsoft's perspective), given what the word "wince" means in the English language.

Re:"Ubuntu is already starting to ship on some ARM

[inf4mia]

There is a metric ton of software available. Lots of web browsers, window managers, office suites etc. make for a nice experience. Windows will have many years worth of software ecosystem catch up to play. In the ballpark of a 500-800MHz or better processor and 192MBs RAM (256 is a lot nicer) is required for a pleasant user experience.

With such an excellent track record....

[u19925]

Microsoft has an excellent track record of supporting Windows on non-X86 processors. MIPS, PowerPC, DecAlpha, Itanium. With such an excellent track record, I am sure, the industry will take it very seriously and we will see tons of devices, computers in the market very quickly. Thank you Microsoft.

Re:With such an excellent track record....

[Anonymous Coward]

Mac Office has been out since 1989. It ran on the Motorolla 68000 and later the IBM PPC.

Re:With such an excellent track record....

[cbhacking]

Microsoft ports software to hardware that will sell it. They aren't discontinuing Itanium support because they don't take it seriously, they're discontinuing Itanium support because the industry doesn't take it seriously, and therefore doesn't buy it, which makes it kind of pointless to sell software for it. Notice anything interesting about the architectures you mentioned? None of them are used in PCs or workstations anymore, and most of them haven't been in years (a decade or more, for many).

I have a friend who still bemoans the death of NT on Alpha, but even he - a Linux-using guy who avoids Microsoft stuff to the point of not even having Wine installed - says it was DEC's fault, not Microsoft's. They insisted that Alpha only go in high-end (expensive) systems, and that strategy was not commercially viable. If they'd made it a commodity PC platform, Microsoft woul have been happy to continue providing software for that platform.

ARM, by comparison, is a very up-and-comping PC architecture for low-power or highly-portable systems. The tech industry wants to buy ARM chips, and they're going to need software to run on them. That's where MS comes in. Also note x64, which is rapidly outpacing x86 in the conventional PC world, and which is strongly supported by MS to the point that they're releasing native versions of Office and such for it even though it can run the x86 versions fine.

Re:With such an excellent track record....

[inf4mia]

And for how many non-Intel architectures has Microsoft provided versions of Microsoft Office? Oh that's right, none.

What about ARM on WinCE? There were Pocket versions of Office.

Where's the beef?

[kraln]

Lots of people commenting that Microsoft is missing the point: Apps.

But they're not missing the point. Anything written for .NET won't need a recompile for the new architecture. In fact, I'd imagine that's part of their plans for world domination: Imagine the power of targeting one platform, and having your stuff run on Xbox360 (console), Winodws Phone 7 (mobile / tablet), and Desktop (x86/arm)?

I don't think they're getting the credit they deserve, here.

Re:Where's the beef?

[Belial6]

I would say it is less 'missing' the point, and more a matter of 'avoiding' the point. Obviously .NET was designed for this. Of course, the % of peoples computing that is done in the browser also makes the worry about x86 compatibility moot for many.

Re:Where's the beef?

[bky1701]

"But they're not missing the point. Anything written for .NET won't need a recompile for the new architecture."

Yes, yes they will. As many others have stated, they will need a "recompile" at least, and most likely significant changes on top of that.

Windows has long been an x86 monoculture: it (the collection of programs that run on windows) still hasn't even taken the first baby steps to supporting 64 bit CPUs, and you're telling me you expect to plug and chug ARM?

Re:ARM now?

[Jeff DeMaagd]

NT was actually more stable on Alpha than it ever was on x86...

Alpha NT was the best you could get at the time for Windows, but the FX86 or whatever software DEC offered to translate x86 to AXP can be very annoying, and after a while, not worth the additional hardware stability. The main benefit I got was that because I couldn't play very many games worth a damn, it got me off the game upgrade cycle so the computer lasted me eight years before I gave up, instead of two before I wanted to do major upgrades for the next game. I replaced it with a used Intel-based workstation, I've found that and succeeding workstations to be pretty much as stable. Maybe the lesson was to buy well-engineered and well-built components with good drivers.

Re:"Ubuntu is already starting to ship on some ARM

[icebraining]

Join #debian-arm at irc.debian.org, pretty sure they can help.

Re:"Ubuntu is already starting to ship on some ARM

[larry bagina]

Almost all the debian packages (at least that I've seen) are available for ARM. The only exceptions I know of are some architecture specific stuff (like Xen or virtual box). Oh, no gnat either. Hope you don't like ADA. (Maybe you could cross compile it if you're desperate).

Some combination of git and libz is flaky as hell, though. That's the biggest problem I've had.

Re:"Ubuntu is already starting to ship on some ARM

[Kaz Kylheku]

I remember seeing Linux running on Netwinders sometime around 1998.

Re:ARM now?

[geekoid]

sigh.

It's for the mobile platform. It would be a different set of apps.

Not the recompiling is really the difficult.

Re:ARM now?

[Billly Gates]

How many real apps like Java and Adobe Flash can run in these alternative Linux platforms? Commercial apps only focus on 98% of the marketshare and deliberately make sure it wont run on anything else to cut down on support costs. Even Adobe tried to abandon the mac a decade ago.

The only thing portable are open source apps. That is the true problem. The Arm would have to emulate x86 to be optimal. All the win32 server apps will not be compiled for anything else as the PHB's love their low support costs. All the open software is for Linux. Sure Apache and PHP exists for Windows but how many people use it for a serious production environment? I use it to write software that will run on Unix when it is done.

Microsoft has a problem here. My guess is the arm on server blades are the only true market besides some Windows7 mobile tablets/phones. It is dead on the desktop. Solarisx86 should serve as an example of trying to port.

If Joe Six pack can't run World of Warcraft above 5 fps in emulation there will be hell to pay.

Windows still built on non-x86 platforms ...

[perpenso]

I wonder if the NT guts of newer versions of Windows are still as portable as they were a decade ago.

My understanding is that even though non-x86 retail versions are no longer available MS still built non-x86 versions for internal testing in order to maintain/verify portability of code. It also helps for debugging. A problem that is difficult to reproduce on one hardware platform is sometimes much more apparent on another hardware platform.

Re:Windows still built on non-x86 platforms ...

[Gadget_Guy]

They don't support other architectures because they can't write portable code.

What a load rubbish. What is your justification for that? How is Compaq releasing the IPAQ using Windows Mobile rather than Linux any indication that Microsoft can't write portable code?

The fact that Windows NT has run on 6 different architectures and Windows CE runs on 4 architectures proves that they can write portable code.

Re:Windows still built on non-x86 platforms ...

[Alex Belits]

What a load rubbish. What is your justification for that?

They are Microsoft.

How is Compaq releasing the IPAQ using Windows Mobile rather than Linux any indication that Microsoft can't write portable code?

It explains how the first generation of handheld computing devices (PDAs then) failed.

Manufacturers cancelled non-Windows development believing that users will like "Windows" on those devices or, more likely, as a result of pressure from Microsoft. Windows CE was total shit, so PDAs ended up running total shit, and it was too late to move them to another platform after they have spent all their budget on trying to make things work with Windows CE.

The fact that Windows NT has run on 6 different architectures and Windows CE runs on 4 architectures proves that they can write portable code.

They could do it for a few years. Nobody outside Microsoft knows how much of this was portable code and how much of it was each hardware architecture splitting into its own branch of code. The fact that non-Intel platforms all disappeared strongly indicates that it was mostly the latter in the end.

Re:Windows still built on non-x86 platforms ...

[91degrees]

They are Microsoft.

They are a huge multinational with practically unlimited resources and a very good reputation as an employer. They can hire just about anyone they want.

And shocking though it may seem, MS come up with some of the best software out there. Their software has a certain level of usability, reliability and responsiveness that 90% of other companies can't manage. Seriously - while you may complain about all sorts of issues, most companies produce stuff that's buggier, bloatier and sometimes completely unusable.

Re:Windows still built on non-x86 platforms ...

[iserlohn]

They only appeal to two types of developers -

Business types who know programming
Software engineers that put $$$ before their profession

Re:Windows still built on non-x86 platforms ...

[Alex Belits]

They are shit company that produces shit software based on shit ideas, using shit development practices.

The best they could do was to hire a bunch of relatively smart people just to keep those people from working for anyone else -- and having no other use for those people they had to keep them in a glorified zoo that is Microsoft Research.

Re:Windows still built on non-x86 platforms ...

[91degrees]

They are shit company that produces shit software based on shit ideas, using shit development practices.

This description applies to the majority of developers. Of all the shitty software I use on a regular basis, Microsft's is the least shit.

Re:Windows still built on non-x86 platforms ...

[Alex Belits]

This is because you use Windows -- software running on Windows can't possibly be less shit than Windows, as shittiness of the whole system is a product of shittiness of all layers in it.

This is also why I avoid Windows like the plague.

Re:Windows still built on non-x86 platforms ...

[91degrees]

I've used some pretty crappy software on Solaris and Linux as well.

And occasionally some really quite decent software on Windows.

What is it specifically about Windows that you dislike, because I get the feeling this is colouring your perception of the entire company.

Re:Windows still built on non-x86 platforms ...

[Gadget_Guy]

What a load rubbish. What is your justification for that?

They are Microsoft

Ah yes, the ostrich approach. Stick your head in the sand and ignore all the evidence that doesn't match your prejudices.

Manufacturers cancelled non-Windows development believing that users will like "Windows" on those devices or, more likely, as a result of pressure from Microsoft.

And you know this because... Ah wait, don't tell me. They are Microsoft. Just blind speculation again.

The original iPAQ ran Pocket PC 2000, which was the 3rd generation of the mobile platform. Compaq had plenty of time to see what the OS was like before committing to the product. I am sure that they thought that it suited their needs. And none of your rampant speculation sheds any light on their capacity to write portable software.

Nobody outside Microsoft knows how much of this was portable code and how much of it was each hardware architecture splitting into its own branch of code.

You could always go have a look at the Windows 2000 code that was leaked to the Internet, or ask someone who has access to it through the Microsoft Shared Source Initiative.

The fact that non-Intel platforms all disappeared strongly indicates that it was mostly the latter in the end

It seems more likely to me that it would be simplifying 3rd party drivers and applications that would make standardizing on one architecture desirable. Plus the fact that there was never any great demand for the non-Intel versions anyway.

Re:Windows still built on non-x86 platforms ...

[Alex Belits]

Microsoft is one of the companies that ONLY make crap. Anything that relies on Microsoft software ends up being crappy.

And occasionally some really quite decent software on Windows.

By Windows quality standards -- yes.

What is it specifically about Windows that you dislike, because I get the feeling this is colouring your perception of the entire company.

Complete lack of any thought placed into engineering of their products. Everything is a special case. Sine "cool" ideas stuffed into software without any kind of overall design or purpose. "Technologies" that are descendants of DDE (interprocess messaging) and OLE (object management) being rebuilt every 3-5 years into larger and larger monstrosities only to show how Microsoft developers completely miss the point of having clearly defined interfaces. This is how second-year CS students write their projects, and how Microsoft operated since the moment it was founded. It can not be fixed by re-doing everything as more special cases, it can be only avoided by keeping Microsoft cancer away from new technology.

Re:Windows still built on non-x86 platforms ...

[Alex Belits]

Sine

Some

Re:ARM now?

[guruevi]

The kernel (for Linux) is cross-platform and only requires minor changes (the x86-bits). The same could be said for NT if NT hasn't done major x86 optimizations or ASM code.

The main problem is the applications. You can't just take a random app in Linux and put it on an ARM-based system. Some will cross-compile if the developer wrote very good code or if you're willing to do minor changes, others are written in interpreted languages like Perl. But besides that, the applications are limited.

And if you're going to rewrite or write your application from scratch, why not forgo the whole paying for licensing deal and just use a proven and stable system that has already been running on those type of CPU's for years. Windows for ARM will not be without major bugs and inconveniences for at least a few years and it's not like you could fix it yourself or recompile the kernel if your custom SOC doesn't behave well with the stock kernel.

Re:ARM now?

[Belial6]

The last time that MS released Windows for a non-x86 platform, people did 99% of their computer activity locally on their computer. Today, many people do 99% of their computer activity in the web browser over the internet. While backward compatibility is a big deal to some of us, it is naive to think that it is to most people. Honestly, as long as it runs IE, java, flash, VPN, remote desktop and MediaPlayer, they will have a decent sized legitimate market for the product.

Re:ARM now?

[westlake]

The problem is apps...

Apps are not going to be a problem when you are porting from an OS with a 90% share of the market as whole.

Mobile vs. Desktop (Global)
  Mobile vs. Desktop (North America)

if you go arm you will need new apps regardless and if people have learned anything over the past 15 years they should take this chance to break free of the lock-in rather than getting caught up in another round.

Lock-in never seems to trouble anyone but the geek.

Top 5 Operating Systems (Global)
  Top 8 Mobile OSs In North America

Re:"Ubuntu is already starting to ship on some ARM

[TheRaven64]

Wrong way around. Debian has supported ARM for a while, but new ARM devices are shipping with Ubuntu preinstalled. That's the new development - there have been Linux-based ARM devices before, but they've usually been embedded devices. You can pick up a pretty cheap ARM tablet from China with Ubuntu installed now (there are a few hundred for about £100 on eBay at the moment, typically with something like a 600MHz Samsung ARM11 CPU).

*Hopefully* pointless effort.

[Junta]

Microsoft's success with end-users is almost entirely predicated on compatibility for third party software. Windows for ARM would not be able to execute Windows for x86 code in any reasonable way. MS would want to have stringent licensing restrictions at significant cost while Google just doesn't care or have reason to care and will let OEMs do what they will. For end-users, no benefit is available from Windows, for manufacturers, the software is an expense that is not recoverable via crapware preloads like in x86 world.

Of course, MS could have an advantage with the device manufacturers here, but only if it is willing to nearly give away the OS for free to manufacturers. A *large* part of the consumer electronics experience is governed by the software. A software update can give a customer everything they wanted in a new device without buying a new device. If the software is consumer friendly and let's the user update to latest edition for free, many will opt to do so instead of buying a new device, to the chagrin of the manufacturers who want to move more volume. Meanwhile, if MS offers an OS that would cost $100 to update and the cost of a new device (including the update they wanted) is $200, a lot of customers will just go ahead and get a new device, giving a bump for the market. For manufacturers to get the numbers so close MS would have to take away a relatively small revenue amount per purchase. Essentially amounts to colluding with manufacturers to screw the consumer over by artificially keeping retail prices up and precluding any other inexpensive path to updates. Microsoft surely would never do such a thing...

Oh and finally, chasing Google's tail on this is the wrong way to do it anyway. Google's ChromeOS *and* android is a mistake, and MS probably would do better by having a converged phone+netbook+tablet platform instead of trying to copy over the desktop platform and suffer odd overlap between their 'phone' and 'desktop' platform on smallish arm systems.

Re:*Hopefully* pointless effort.

[Junta]

I will also say that this is another reason why not to set desktop expectations on ARM devices given a chance to reset. Why offer major upgrades via retail at all rather than only with purchase of new devices. Now *there* is a way to really win over manufacturers. Android already exhibits this behavior to a large extent with locked down devices, so this may be a lost cause no matter how they position it.

How Dave Cutler got it to work last time ...

[perpenso]

They can just trot down to the Azure lab and ask Dave Cutler how he got it to work last time.

The NT dev team's method is no secret, throw everything out and start from scratch.

FWIW, note "NT" not "Windows NT", it actually started as "OS/2 NT". Back in the day MS was telling people that Windows was a temporary thing for users sticking with DOS rather than migrating to OS/2 1.x plus the Presentation Manager GUI, a 16-bit protected mode environment. IBM was going to do a more expedient x86-only 32-bit version, OS/2 2.0, while Microsoft was going to do a 32-bit portable version targeting various CPU architectures, OS/2 NT. At some point Microsoft decided to split up with IBM and renamed the product Windows NT.

Re:How Dave Cutler got it to work last time ...

[JamesP]

Correct

that was when IBM got the short end of the stick with MS

Re:How Dave Cutler got it to work last time ...

[commodore64_love]

I've never owned as ARM computer (just C=6502, 68000-60, PowerPC, x86, MIPS).
Why do you think ARM will be a dominant brand in the coming years, instead of the low-power Intel units? (just curious)

2 or 2.5 GHz is not slow, it's equivalent.

[Futurepower(R)]

"They are also a quarter of the speed."

Apparently you are talking about clock speed, but 2 GHz or 2.5 GHz is not slow compared to the Intel Atom. The speeds are equivalent.

Until marketing gets wind of it

[HangingChad]

Then it will only run one program at a time and be issued in 4 versions.

Re:ARM now?

[Bert64]

But if you're not going to run anything which is tied to windows, then what's the point paying more for windows?

Linux runs a browser, java, flash, vpn, rdesktop and a media player - and it costs less than windows. Backwards compatibility is about the only selling point windows really has.

MS Office was portable in 2008 ...

[perpenso]

The NT Kernel might be, even after all this time slapping whatever each release thinks is a useful feature into it, but who cares about that. I think I can guarantee Office will not run on ARM ...

I believe MS Office Mac 2008 targeted Intel and PowerPC cpu architectures, that would make it highly portable.

Re:MS Office was portable in 2008 ...

[ChunderDownunder]

Highly portable to ARM running OS X, sure.

But Office for Mac is a different product. (After the Word 6.0 disaster...)

Re:ARM now?

[Bert64]

Porting *from* an os with 90% share?
What you port from doesn't matter, if your porting from an os with 90% share you could be porting *to* beos, or vms...

What matters is the share of the os your porting *to*, if that os has no users then closed source apps will never be ported.
If there are no apps, then no users will use the os.
Open source apps will probably be ported if anyone cares enough, but then if an app is open source it probably already runs on linux/arm anyway.
Windows already failed on alpha, mips, ppc and ia64, primarily due to lack of apps... (yes the ia64 port still exists but its being scaled back and looks likely to be dropped).

Theres also the matter of history...
Windows apps have traditionally been written for x86 only, and when targeting a single architecture you can make various assumptions which can cause breakage when the code is compiled for a different cpu... Think endian issues, and differently sized data types etc...
Linux however is a unix clone, and unix clones were already widely used on different architectures, even before linux was ported to different processor types, so most unix source code is fairly portable across different hardware. I have run linux on various kinds of non x86 hardware for years and very rarely had problems compiling things...

Lock-in should trouble anyone trying to run a business, no well managed business would ever let itself get locked in to a single supplier in any other field... Why should software be treated any differently?
Individuals should care too, but generally have less invested in it (tho im sure there are people who still remember being stuck with a betamax vcr or hd-dvd player)...

after running Win7 on a new laptop

[FudRucker]

i have to say microsoft better call a butcher to cut the fat and bloat out of their current OS before i would bother to use it, i would rather run a lightweight Linux distro on an ARM than the bloated crap microsoft has, i would be ashamed to admit i was a microsoft employee if i worked for them.

Re:after running Win7 on a new laptop

[cbhacking]

Do a clean reinstall. The difference, in terms of performance, install footprint, memory usage, boot time, and stability between an OEm image and a clean install is astounding. Vista had much the same problem - it actually would run happily on a 1.8GHz machine with 1280MB of RAM, far below the "unofficial minimum requirement," if you did a clean install. Win7 is better still.

Woth the last laptop I bought (from HP), the initial bootup of the OEM image, where it configures a dozen GB of crappy bundled software, took longer than the entire proces of formatting the disk, installing Windows cleanly, booting, and running through the standard out-of-box experience and configuration.

In any case, something aiming for a small, cheap and low-powered ARM device probably wouldn't run an OS intended for a primary home PC or a workstation. "Porting Windows to ARM" doesn't mean running Win7 on an ARM device. It means making sure that the kernel, userspace APIs, core libraries, and important apps (IE counts, Office might, Media Center probably doesn't) can be run on whatever the new trend in computing hardware leads to.

Re:"Ubuntu is already starting to ship on some ARM

[baka_toroi]

He asked about the user experience, you pedantic fuck.

Re:I should add...

[scdeimos]

You won't have any problems with .NET apps though - even those which directly access system DLLs. So as long as most of your software is built with .NET on Windows, you might be just fine.

Can I sell you a clue?

Please?

You only have to step very slightly outside of the core .NET namespaces (system.*) before .NET has problems being portable between Windows 7, Vista, and XP. Even System.Net.* behaves slightly differently on each of those platforms.

Exactly. Windows CE is already there.

[Weaselmancer]

I couldn't have said it better. What would be the point of porting the desktop Windows to ARM when MS is already in that market segment with Windows CE?

What would the difference be?

No x86 software would work on it and it would be a reimplementation of the win32 API. Which would be...Windows CE.

Why? Is Win CE dead?

[guidryp]

Can anyone make a sane case for this?

Intel Medfield is supposed to close the power gap on ARM and will be out before product from this port will.

Arm and x86 netbook both with windows, both competing with each other, and not binary compatible with each other.

Seriously I think the original info source is faulty and this is really Win CE 7 (already ARM) for tablets.

 

Re:Why? Is Win CE dead?

[shutdown -p now]

You can take a Windows application written in C/C++ for x86 and x64, and recompile it to target ARM - barring a few rare corner cases, it would really just work. The point here is that the OS itself is exactly the same, and fully supports all APIs.

You can't do the same thing to get a Win32 app work on WinCE, even on the same architecture.

Re:Why? Is Win CE dead?

[guidryp]

"You can take a Windows application written in C/C++ for x86 and x64, and recompile it to target ARM - barring a few rare corner cases, it would really just work."

In theory and for small simple programs sure. But for ancient legacy apps some even containing x86 assembly optimizations, It is never that simple.

And even if it was it would negate the main advantage of windows, it's massive legacy of applications. Half of that legacy is abandonware at this point.

What are you going to choose a laptop with ARM that only runs a subset of recompiled applications, or one with x86 that run new and all legacy software.

MS doesn't need a new kernel for mobile, they need a new interface with the Priority on Touch.

Re:Why? Is Win CE dead?

[shutdown -p now]

In theory and for small simple programs sure. But for ancient legacy apps some even containing x86 assembly optimizations, It is never that simple.

True, the real legacy software wouldn't get in there. But there is still plenty of non-legacy stuff that is being actively developed.

And even if it was it would negate the main advantage of windows, it's massive legacy of applications. Half of that legacy is abandonware at this point.

It's often touted as the main advantage of Windows, but I don't think it really is. When I look at what apps people I know use on their Windows desktops and laptops, I can't actually recall any "legacy" stuff except, possibly, games. Businesses, now - those are more likely to run something written in VB6 ten years ago and not touched ever since. But they clearly aren't the target market for ARM netbooks/tablets anyway.

What are you going to choose a laptop with ARM that only runs a subset of recompiled applications, or one with x86 that run new and all legacy software.

It depends - if the ARM one can last for two days on a single battery charge, I'll certainly have to think about it. Especially in the case of a tablet rather than a laptop.

Re:Why? Is Win CE dead?

[guidryp]

It's often touted as the main advantage of Windows, but I don't think it really is. When I look at what apps people I know use on their Windows desktops and laptops, I can't actually recall any "legacy" stuff except, possibly, games.

Really you must be living in a different universe. Because I am in the one where when a few applications broke under Vista, the mob broke out the torches and pitchforks.

Now a windows that breaks ALL software... That is a completely insane idea.

There is no way that NT Kernel is being ported to ARM, it is just nonsense. A miscontrued bit of info.

This is almost certainly a Win CE relaunch.

Offline use

[tepples]

How well would a cloud-based Microsoft Office service work on devices that have only intermittent connections to the Internet, such as smartbooks, Wi-Fi tablets, and 3G tablets in areas with poor signal coverage? Does it use HTML5 CACHE MANIFEST+localStorage or some other tech to work offline?

Re:Offline use

[Sancho]

Honestly, I don't know. I could just really see Microsoft trying to promote something like that rather than port Office.

Re:Offline use

[ChunderDownunder]

Similar approach as Google Docs, in other words? If it's good enough for ChromeOS...

Verifiably type-safe

[tepples]

I'm sure it will run OpenOffice.org/LibreOffice (as long as they don't use the iPhone model).

The current version of Windows on ARM (Windows Phone 7) goes past the iPhone model, requiring all programs to be written in verifiably type-safe CIL. Standard C++ will compile to CIL, but it won't be verifiably type-safe and therefore won't run on Xbox 360 or Windows Phone 7. Instead, even the platform-independent model portion of a program has to be rewritten to use the different syntax and semantics for pointers and arrays in the verifiably type-safe subset of C++/CLI.

Before Intel Macs, VPC was an emulator

[tepples]

Hmm, if only Microsoft had bought a company that made an x86 emulator. Oh, wait, they did.

Are you referring to Virtual PC?

Yes. Before Apple started making Macintosh computers with Intel CPUs, Microsoft sold a product called "Virtual PC for Mac" that was an emulator that ran Windows and Windows applications on a PowerPC CPU.

Re:Before Intel Macs, VPC was an emulator

[jawtheshark]

Interesting.... Is it still one? Don't forget that Microsoft has the nasty habit of buying companies and gutting them in such a way that they only serve Microsoft. In this case, the gutting may have occurred prematurely.

Re:They only need enough drivers

[Daengbo]

And yet when you read tech blog comments on Chrome OS, the turfing is all about drivers and whether your digital camera is going to work.

Windows CE-Me-NT

[tepples]

What would be the point of porting the desktop Windows to ARM when MS is already in that market segment with Windows CE?

What would be the point of making a home version of Windows NT when Microsoft was already in that market space with Windows 98? Just as the home PC market was switched from the 9x codebase to Windows XP (i.e. NT 5.1), the mobile market could be likewise switched to NT, finally unifying all three markets (home, professional, and mobile) under one codebase. Microsoft might even be able to pull it off if it includes a subsystem for running CE apps, much like wowexec on 32-bit NT or wow64 on 64-bit NT.

Re:Windows CE-Me-NT

[Weaselmancer]

Well that's sort of a different thing. Software for the x86 9x platform would be expected to run on the x86 NT platform.

In this case you're changing the processor so it would be a fresh start. And one they've already done. Windows CE. It is the win32 api (trimmed down a bit) running on ARM.

Now, if they could do the "one codebase many architectures" thing like the Linux kernel - well, that would be nothing short of spectacular.

But don't hold your breath. They break compatibility all the time just moving down the x86 line as it is. Throw in another processor into the soup and you'd have a real mess, unless they put an insane amount of work into it. And from what I've seen from them so far I'll just be polite and say that seems highly unlikely.

Re:Windows CE-Me-NT

[hxnwix]

Just as the home PC market was switched from the 9x codebase to Windows XP (i.e. NT 5.1), the mobile market could be likewise switched to NT, finally unifying all three markets [norton.com] (home, professional, and mobile) under one codebase. Microsoft might even be able to pull it off if it includes a subsystem for running CE apps, much like wowexec on 32-bit NT or wow64 on 64-bit NT.

This fellow just opened the pinata in one deft strike. Well done.

Re:ARM now?

[Billly Gates]

I thought Windows7 phones already are mostly arm based.

Is Microsoft thinking of using something other than WindowsCE?

Windows CE applications

[tepples]

But Windows' main (and practically lone) selling point is that it works with all your old software.

Windows for ARM could run Windows Mobile applications. Please see my other comment.

Compare handheld video game systems

[tepples]

I don't think there will be much margin on SW for $200 devices

How much margin is there on software for Nintendo DSi, PSP, and iPod touch, which fall close to that price range?

Re:Compare handheld video game systems

[mirix]

I meant OS, not the applications, should have been more clear.

I don't think nintendo makes much on DSes (?), HW & OS portion at least. and if a third party made a different "DS OS" I couldn't see them being able to sell it for much. Games though, big money, sure.

Re:ARM now?

[tepples]

Existing windows apps would need to be at the very least recompiled (or may require significantly more work depending on the code)

Not necessarily. See my other comment about handling a transition from Windows CE to Windows for ARM much like the transition from Windows 9x.

Xbox games on Xbox 360

[tepples]

The original Xbox console had a Celeron CPU. Xbox 360 has a 3-core, 6-thread PowerPC CPU. The x86-on-PowerPC dynamic recompiler from Virtual PC for Mac ended up in the ability to play select Xbox game discs in emulation on the Xbox 360.

But for how long? Microsoft has been fickle.

[dpbsmith]

Originally, Microsoft claimed Windows was portable to just about every significant processor available. Then they shifted direction and, lo and behold, everything but Intel dropped out, one by one. The company I worked for was seriously hurt when Microsoft dropped support for DEC's Alpha, just months after we had made a big marketing push and sold what for us was a large number of Alpha-based systems. Support for Windows on the PowerPC architecture went the same way.

And, of course, remember the ACE initiative, Windows running on a MIPS-based reference architecture? Microsoft sandbagged that, too.

Multiplatform support means very little if you are completely dependent on a vendor's whims (or strategic marketing objectives) as to what platforms are supported.

AD/Printer servers, IIS

[itzdandy]

I see a gap in microsoft's product line. Its small branch offices where a traditional server is overkill in power usage and expense.

If microsoft were to produce an ARM version of server2008r2 that was able to provide a full AD DC role, print server role, WSUS or IIS as a single role server on a lighter ARM box they would kill.

If you could get a single role, or single primary role such as a AD DC + print server, or IIS + WSUS, at a more fitting price for a low power machine, then AD would find many more homes in small offices.

Considering that ANY full size server is going to chew up 250W, and 350W more often than not, a 100W ARM server, redundant hard disks included, would be a significant savings in expense. 250W*24hours*365 = thats ~2.2MW or around $250, the ARM server would be $150 per year cheaper. Now do 2 AD DC, 1 IIS + WSUS, and 1 fileserver your at 1.25KW*24*365 thats 11MW or $1200 vs $300-$400 for the arm. Microsoft should also license these out at a reduced price (1/2 I think) but keep CALS the same price.

There are many roles that just arent worthy of an entire machine and shouldnt be put in a VM. A backup server for DPM for instance. Doesnt need much horsepower, just diskspace, server 2008r2, and the DPM software. PERFECT for a small ARM platform like a dual core 1.5-2Ghz.

Re:AD/Printer servers, IIS

[drsmithy]

f microsoft were to produce an ARM version of server2008r2 that was able to provide a full AD DC role, print server role, WSUS or IIS as a single role server on a lighter ARM box they would kill.

No it wouldn't. The cost savings wouldn't even be significant enough to count as a rounding error.

Considering that ANY full size server is going to chew up 250W, and 350W more often than not, [...]

250W ? 350W !? A decent gaming machine won't use that much power, and a mostly-idle server (without a screen or power-hungry video card) wouldn't get close.

A 2U rackmount server with 8 cores @ 2.5Ghz, 48GB RAM and 8x15k RPM pulls under 250W with a light load. Any contemporary, basic "server" (~2Ghz dual-core CPU, 4-8GB RAM, 2-4 hard disks) should rarely, if ever, break 100W in typical usage.

There are many roles that just arent worthy of an entire machine and shouldnt be put in a VM.

Why not ?

A backup server for DPM for instance. Doesnt need much horsepower, just diskspace, server 2008r2, and the DPM software. PERFECT for a small ARM platform like a dual core 1.5-2Ghz.

The power savings over an identical machine with a Core 2 based machine would be insignificant, in the context of an office's annual budget. You'd probably save an order of magnitude more money just by getting rid of the water cooler.

Re:AD/Printer servers, IIS

[JamesP]

Yeah, but the costs of HW x86 are very cheap.

The rest of HW is arch independent (storage, mainly)

Power? You can go with the slowest modern processor, or Atom

Re:AD/Printer servers, IIS

[itzdandy]

A 2U rackmount server with 8 cores @ 2.5Ghz, 48GB RAM and 8x15k RPM pulls under 250W with a light load. Any contemporary, basic "server" (~2Ghz dual-core CPU, 4-8GB RAM, 2-4 hard disks) should rarely, if ever, break 100W in typical usage.

A Dell Poweredge r410 with a dual xeon 2.6Ghz and 8GB RAM, 4 disks draws a steady 300W according to my killawat.

A Dell T100 with a Core2 Duo 2.8Ghz and 8GB RAM, 4 disks pulls ~225W according to the killawat.

in the context of an office's annual budget

Seriously? That kind of justification is a prime example of how to let a business's finances run off the rails.

Considering the disk costs and power consumption are set a different platform wont alter that. Many ARM 'systems' draw under 5W under max load. 10W per drive puts a 4 disks system in under 50W under light load assuming 8-10W per disk and doubling the power draw of the SoC.

Electricity is getting more expensive quickly. At $.12/KWh we are talking hundreds of dollars a year, but electricity is just getting more and more expensive and $.30 is not so far off for a lot of businesses.

Re:AD/Printer servers, IIS

[itzdandy]

Atoms are actually VERY slow. head to head with an ARM CPU mhz to mhz ATOMs dont fare well. Toms hardware has shown that Core2Duo chips are MUCH more power efficient than atoms. What makes the current generation of atoms efficient is actually the chipset.

I have a D510MO board with the dual core atom 1.6Ghz, 2GB RAM, 64GB SSD, and Server2008R2 as a AD DC in testing (in the M350 case). The hardware is fine, despite being fairly slow. The issue here is that the same server license that I can run on a dual socket 8 core system is what I have to use on this machine which is an order of magnitude slower. btw, this machines idles at 17W and load at 21W per my killawat.

I suppose the draw to ARM or something is really the possibility of change in Microsoft opening up to more specific use server licenses. Server2008r2 ADDC only licenses for say $300. Something to bridge the gap between 7Pro and Server. I use 7pro for print and file servers but really need a domain controller license that is less than $700.

Active directory is very handy for small offices with just 5-6 computers. Something like small real estate, mortgage brokers, insurance agencies, etc. These places typically have low technical skill levels and also very small budgets. A CAL is comfortable, but 2 servers and licenses for server2008 plus a print server plus a file server which is microsoft's best practices (2x DC and single use servers/server VMs) gets prohibitive quickly.

Re:ARM now?

[Belial6]

As much as I would love to see Linux make headway, the cost for windows preinstalled just isn't that much. The same people that would do 99% of their work in the browser would be the people that would lean towards the known company over the unknown.

So, the same demographic that would consider moving brands is the same demographic that would have the hardest time, while the demographic that would stick with brand name would be the group that could move brands if they cared to.

Re:ARM now?

[Belial6]

Touche!

I will refine the statement in the future to read "Desktop Windows"

Re:ARM now?

[fragMasterFlash]

The NT kernel is optimized to run SMP on cache coherent cores. ARM is not cache coherent and it is likely that making it cache coherent would ruin much of its power efficiency compared to x86. NT running on a single ARM core doesn't seem very interesting and supporting multithreaded applications on SMP ARM will require either strong thread affinity or adding some really ugly shared memory hacks to WIN32.

Re:ARM now?

[PatPending]

Thanks for the links. I've bookmarked this site.

Re:ARM now?

[shutdown -p now]

A hypothetical ARM port of Windows would still get much more software, since most of it is really just a recompile away (Win32 API would remain the same, and so would the C/C++ compiler). You know - Office, Photoshop... the usual names that people mention when talking about what's missing on Linux.

Re:ARM now?

[Bert64]

Why?
Office might be ported if MS are trying to push the platform hard, but photoshop? I doubt it...

Photoshop was never ported to NT/Alpha or NT/IA64, and those platforms offered superior to x86 performance and memory capacities - very useful for running photoshop, ARM is a low power platform which is unlikely to be used to run photoshop...

Sure, theoretically most of it is a compile away... But unlike on linux, only a single entity can recompile each piece of software...
Also very little win32 software has ever been written for anything other than x86, who's to tell how many x86 dependencies might exist in the code which would make porting harder?

Re:ARM now?

[Bert64]

While a single copy of preinstalled windows isn't that much, a hundred thousand copies is a lot... If your an OEM looking to ship thousands of units, removing a costly component could have a very positive impact on your margins.

As for end users, thats all down to marketing... Chances are if these people are leaning towards known companies, then they will be buying hardware from known brands too and so if the OEM promotes it well there could easily be linux sales... A decent linux distro (note: not the crippled distros that have shipped on previous netbooks) has a lot of advantages to a typical end user, they just don't know about them because there is little or no marketing.

On the other hand, if the people are buying unbranded equipment they are probably doing so because its cheaper, so buying unbranded software isn't much of a stretch for the same reason.

Re:ARM now?

[shutdown -p now]

Granted, Photoshop might have been a bad example. I dunno, what else is usually thrown out - Quicken?

Oh yes, and games. So long as the drivers are there, DirectX (11 or whatever it'll be by then) will be as well.

Sure, theoretically most of it is a compile away... But unlike on linux, only a single entity can recompile each piece of software...

Yes, of course. Which is why the real legacy software won't get there. But those programs which are still developed - so long as the porting is easy, and ARM netbooks and/or tables become widespread, well, why not?

Also very little win32 software has ever been written for anything other than x86, who's to tell how many x86 dependencies might exist in the code which would make porting harder?

There has been quite a struggle in moving software to x64, and most quirks have been ironed out then. Even for those apps which didn't move, Microsoft C/C++ compilers since 2003 have had a mode which detects typical portability issues even when compiling for 32-bit and emits them as warnings. So the usual set of problematic patterns - sizeof dependencies and such - is largely treated by now.

The point, anyway, is that it is definitely much easier than porting the same code to Linux or OS X...

Re:ARM now?

[Belial6]

Your theory seems to have failed up until this point. There is no reason to believe that it would change in the future.

Re:ARM now?

[91degrees]

But if you're not going to run anything which is tied to windows, then what's the point paying more for windows?

I think we're on that "nobody ever got fired for buying Windows" thing, or something similar.

What you can be reasonably sure of is that it will be supported for some time (MS isn't going to go bust for a while), at least some third party developers will be producing applications becuase it's easy to find developers who know Windows, and it could become a self fulfilling prophesy that Windows ARM becomes successful because everyone expects it to do so.

Re:ARM now?

[iserlohn]

Actually, netbook manufacturers were "incentivised" by MS into shipping XP (and then Win7) for netbooks. They have tremendous leverage as these manufacturers need the OEM licensing that MS provides for a range of other products as well and does not want to damage that relationship.

Eventually Android tablets and the iPad will obliterate netbooks sales. We can already see a glut of netbooks this year, unsold for the Xmas season. Chrome OS will probably pick up most of the slack when it does come out if it offers a more seamless experience for the younger generation that uses computers permanently online.

legacy software is such a false reason

[cheekyboy]

If I install windows, i rarely use anything thats older than 3 years old. (except old licence copies of office/vstudio)

So legacy is not a reason any more.

Anything beyond 3-4 years is either utter crap, or just irrelevent and has a superior competitor that 10x better and at least supports newer cpus and dual core.

Re:ARM now?

[Bert64]

so long as the porting is easy, and ARM netbooks and/or tables become widespread, well, why not?

They wont become widespread until there are apps, and commercial vendors wont port apps until the hardware is widespread (ie there are actual customers to buy it)... Doesn't really matter how easy porting is...
There will almost certainly be a lot of open source apps fairly quickly, but then linux already has all these apps, so will this be enough to bring customers to the platform? Not unless hardware vendors seriously screw up their linux implementation/marketing - and thats more likely to kill the platform totally...

HP and Intel went out of their way to make porting apps to IA64 easy, and look what happened there...
Porting to windows on mips, ppc and alpha was easy too - the alpha even used a special compiler to simulate a 32bit cpu to make porting easier, and yet these platforms never took off... mips and ppc were very quickly killed (and microsoft even made their own mips hardware) while alpha hung on in niche markets for a while because it was so far ahead on performance in those days.

x64 is an entirely different kettle of fish, x64 systems can still run x86 applications just fine and most software still ships as 32bit x86 binaries anyway, only a very small niche of software is compiled for x64 so far.

Yes, the porting may be easier than osx or linux, but both osx and linux are currently a larger market than windows/arm and yet are often considered not large enough for commercial ports.

Also since you mention quicken and photoshop, both of those apps already exist for osx on both powerpc and x86, and photoshop even used to have unix ports (irix at least)... Porting to linux would not be terribly difficult.

You will also get fragmentation of brand...
On linux at least, the same applications are already available for arm and x86 (or mips, or whatever else), if a piece of software is for "linux" then chances are it can run on your hardware regardless... Also the repository/appstore model suits this very well.

Windows apps being closed source, pretty much depend on running on compatible hardware... Users will be annoyed when they buy "Games for windows" and find they don't work on this new windows/arm, they will be forced to check what architectures the apps they want to use are available for. Most apps these days are not written in hardware neutral frameworks like java or .net...

Re:ARM now?

[cbhacking]

NT has been ported to a lot of architectures other than Alpha. In fact, there's a currently supported (though being phased out) port to Itanium, which is nothing like x86 despite coming from the same company.

The problem is that it does cost money to maintain ports, and therefore Microsoft won't do it unless they make more than it costs. Itanium has not been a great success, and is falling behind rapidly now, which is why it's being abandoned. Alpha went through something very similar, in a much shorter time-frame, during its heyday: a shiny new architecture with awesome capabilities and a Windows NT port that ran great, but the chip itself was not a commercial success (my personal understanding is that DEC screwed up the pricing and marketing, targeting only very expensive systems rather than commoditizing the CPU). Without sufficient financial incentive to keep it around, MS dropped the ARM port.

So far, ARM seems to be going the opposite direction. It's been around for a long time, but is only starting to be taken seriously for general-purpose computers. It's low-cost and already very commoditized, and PC OS developers are starting to look at it with interest as it becomes powerful enough to be relevent in a general-purpose PC. Because there's a ready-made market niche for it (low-power and low-cost systems, possibly portable and/or touchscreen based), adoption will probably be pretty quick (unlike many other non-x86 architectures of the past).

Make a DS OS, get sued

[tepples]

I don't think nintendo makes much on DSes (?), HW & OS portion at least.

Nintendo makes plenty on the operating system, or at least the part that verifies each game's digital signature.

if a third party made a different "DS OS" I couldn't see them being able to sell it for much.

Only because Nintendo has successfully sued companies selling the different "DS OS". See multiple prior articles.

Re:ARM now?

[sgtrock]

Lock-in never seems to trouble anyone but the geek.

Top 5 Operating Systems (Global)
    Top 8 Mobile OSs In North America

A year's worth of data refutes that statement.

Windows (NT not CE) on Atom netbook?

[perpenso]

Isn't ARM already dominant? Think smart phones and tablets not laptops and desktops. The former will one day exceed the later with respect to personal ownership.

ARM may also get used in some netbooks. I suppose something from the NT side of the family, as opposed to the CE side, could make sense there. I'm not sure why a desktop or laptop might go that route (Atom + NT).

Univ Profs/Students had Win NT source ...

[perpenso]

Nobody outside Microsoft knows how much of this was portable code and how much of it was each hardware architecture splitting into its own branch of code.

Wrong. MS had (has ?) a program granting access to Windows NT source code for university researchers. MS had to like the research topic and be granted the right to use anything that comes from this research (keep in mind universities like to patent things, MS would automatically get a license) and the professor and students had to sign NDAs and keep the source "locked up" so those outside the project would not have access. A friend was on such a project while in grad school, I believe they had Windows NT 4.

Regarding architecture specific branches, that is pretty much only done for portions of the hardware abstraction layer of NT, just as it is done for portions of Linux and BSD kernels.

The fact that non-Intel platforms all disappeared strongly indicates that it was mostly the latter in the end.

A terribly bad guess. Windows NT started on MIPS (i860 when it was OS/2 NT?), designing the code for portability was a priority since day 1. MIPS was used to further this goal. Alpha and PowerPC cpus were more commercially oriented ports. Their failure in the Windows market was not necessarily MS' fault. Apple never delivered the Mac OS component of CHRP that would let people have native Mac OS and native Windows NT running on the same machine. On the low end server side Linux thwarted MS expansion into that realm. The non-x86 retail products were dropped due to a lack of consumer interest. Note that x86 includes two hardware platforms, IA32 and AMD64.

Re:Univ Profs/Students had Win NT source ...

[Alex Belits]

Wrong. MS had (has ?) a program granting access to Windows NT source code for university researchers. MS had to like the research topic and be granted the right to use anything that comes from this research (keep in mind universities like to patent things, MS would automatically get a license) and the professor and students had to sign NDAs and keep the source "locked up" so those outside the project would not have access. A friend was on such a project while in grad school, I believe they had Windows NT 4.

And no one is allowed to publish any of that, so they are just as good as Microsoft employees.

Regarding architecture specific branches, that is pretty much only done for portions of the hardware abstraction layer of NT, just as it is done for portions of Linux and BSD kernels.

You wouldn't have proof of that even if it was true.

A terribly bad guess. Windows NT started on MIPS (i860 when it was OS/2 NT?),

And Java was started as a language/platform combination for embedded systems utilizing special Java-optimized hardware. By the time anything usable was released, it was something completely different.

Their failure in the Windows market was not necessarily MS' fault.

They could "fail" and would be still supported if code was truly portable, because portable code means ZERO effort necessary for keeping a hardware platform supported. Ex: NetBSD and Linux supporting architectures that have a tiny handful of users.

Apple never delivered the Mac OS component of CHRP that would let people have native Mac OS and native Windows NT running on the same machine.

This is completely irrelevant, as PPC is a quite popular architecture among things other than desktop computers bought specifically to not run Windows.

On the low end server side Linux thwarted MS expansion into that realm.

Entirely within x86 architecture, so it's irrelevant.

The non-x86 retail products were dropped due to a lack of consumer interest.

If the code was truly portable, it would not be possible to drop an architecture, code would compile on it anyway, and it would cost nothing to list it as supported. It's not like HP is going to issue a new bootloader for Alpha any soon.

Note that x86 includes two hardware platforms, IA32 and AMD64.

AMD64/x86-64 was specifically developed to be similar to IA32/i386. Beyond supporting architecture in compiler and memory management, all Microsoft had to do was to not mess up pointers width, use long integers in a sane manner, and possibly be aware of compiler's idea of alignment. I am also absolutely sure that they still messed that up, and ended up writing "special" code for that, too.

Re:Univ Profs/Students had Win NT source ...

[perpenso]

Wrong. MS had (has ?) a program granting access to Windows NT source code for university researchers. MS had to like the research topic and be granted the right to use anything that comes from this research (keep in mind universities like to patent things, MS would automatically get a license) and the professor and students had to sign NDAs and keep the source "locked up" so those outside the project would not have access. A friend was on such a project while in grad school, I believe they had Windows NT 4.

And no one is allowed to publish any of that, so they are just as good as Microsoft employees.

Wrong. There were no restrictions on publishing the research. Only the Windows source code was under NDA. MS was merely granted a license in the event the research was patented or otherwise restricted.

Re:Univ Profs/Students had Win NT source ...

[Alex Belits]

Wrong. There were no restrictions on publishing the research. Only the Windows source code was under NDA. MS was merely granted a license in the event the research was patented or otherwise restricted.

How does publishing of things other than source code affect the fact that they can't publish any of that source code?

Re:Univ Profs/Students had Win NT source ...

[perpenso]

Wrong. There were no restrictions on publishing the research. Only the Windows source code was under NDA. MS was merely granted a license in the event the research was patented or otherwise restricted.

How does publishing of things other than source code affect the fact that they can't publish any of that source code?

By "Windows source code" I am referring to the Windows operating system code written by Microsoft. The code written by the university researchers may be published.

Re:Univ Profs/Students had Win NT source ...

[Alex Belits]

Again, how is that relevant? I have claimed that there is no way to prove that Windows source code is clean and cross-platform that Microsoft fans believe it to be. The fact that someone had seen it under NDA and published something else, has no effect on this.

iPad seems to do okay without it

[nobodyman]

I doubt that an ARM version of windows would ever wind up in a Desktop (or laptop). Could be that they are attempting to create a more tablet-friendly version of windows than what you get with Windows 7. You could get away with Office on something like that.

Personally though, I suspect that there's less of a story here than people think. They are probably just going to reveal a newer version of Windows CE. Big deal.

Re:ARM now?

[shutdown -p now]

They wont become widespread until there are apps, and commercial vendors wont port apps until the hardware is widespread (ie there are actual customers to buy it)...

Yeah, the vicious circle. That's when you (i.e. MS) actively promote app developers to pick it up via various financial incentives and support. We're already seeing the same tactic in action for WinPhone, which suffers from the same problem (new platform -> few users -> few apps written -> few users).

HP and Intel went out of their way to make porting apps to IA64 easy, and look what happened there...

But IA64 was never successfully marketed as anything but a server platform; why would makers of consumer and "workstation" software even bother with it?

Porting to windows on mips, ppc and alpha was easy too - the alpha even used a special compiler to simulate a 32bit cpu to make porting easier, and yet these platforms never took off... mips and ppc were very quickly killed (and microsoft even made their own mips hardware) while alpha hung on in niche markets for a while because it was so far ahead on performance in those days.

The reason why ARM is clearly taking off, with or without Microsoft onboard, is the very recent explosion of consumer mobile device market - smartphones first, and now tablets. The latter especially - you can't have a really good Windows tablet (with decent battery life) unless it's ARM. That alone is a strong incentive for both MS to do it, and for app vendors to jump on the porting bandwagon lest they miss it.

Yes, the porting may be easier than osx or linux, but both osx and linux are currently a larger market than windows/arm and yet are often considered not large enough for commercial ports.

The issues with Linux on the desktop as a market are not just with market share - it's also about fragmentation and constant headaches with hardware support. That it hovers somewhere around 1% is just the final nail in that coffin.

OS X, meanwhile, is doing okay. I mean, we actually have MSOffice there, and a bunch of non-indie games.

But, see - "porting may be easier" is quite an understatement. To port a Win32 app to Linux or OS X, you have to pretty much completely rewrite the UI layer using the new widget toolkit for the target platform - and that's assuming you have clean separation of UI and the rest, which many old code bases do not! To port a Win32 x86 app to ARM, you have to recompile and check for any architecture assumptions - endianness will not be an issue, sizeof would be the same on 32-bit ARM, so that leaves only data alignment issues - and since those will crash your app if there is a problem, they're easy to take care of with automated functional testing (just run your full suite!).

If you're unlucky, you may also have some bits of assembler in your source code which may have to be ported (or just rewritten in C, if their performance isn't really critical on modern PCs in the same way it was 10 years ago when they were written). This would probably be the biggest issue anyone would run into, barring some very special software that is architecture-dependent by definition, such as JIT-compilers.

Also since you mention quicken and photoshop, both of those apps already exist for osx on both powerpc and x86, and photoshop even used to have unix ports (irix at least)... Porting to linux would not be terribly difficult.

It would still mean rewriting the UI in either Qt or Gtk. The existence of those apps on OS X indicates that their UI is reasonably cleanly separated from the logic, so it's easier than it could be, but it certainly isn't trivial.

On linux at least, the same applications are already available for arm and x86 (or mips, or whatever else), if a piece of software is for "linux" then chances are it can run on your hardware regardless... Also the repository/appstore model suit

Re:ARM now?

[makomk]

While a single copy of preinstalled windows isn't that much, a hundred thousand copies is a lot... If your an OEM looking to ship thousands of units, removing a costly component could have a very positive impact on your margins.

Yep. Cost-cutting is alive and popular in the computer hardware industry. For example, I have an Acer Aspire One on the desk next to me. The original Aspire One was available in a version with an integrated 3G modem, which was fitted to a second mini-PCIe slot.

In order to save a dollar or so per netbook, Acer didn't bother populating the connector for the second slot on machines which didn't have the 3G modem to go in it. Cost-cutting was so important to them that it was worth producing and tracking two different types of motherboard just to save a tiny amount on component costs.

Re:ARM now?

[BasilBrush]

It does no such thing. Those stats are counting web usage. They thus show iOS a year ago with a percentage far higher than their real market share, because the Mobile Safari UI was the first mobile web browser worth using for accessing real (not mobile specific) web sites.

The rise of market share of Android over the last year is because it too offers a decent web browsing experience and represents many manufacturers, with cheap smartphones.

It's got nothing to do with lock in. The average smartphone purchaser hasn't a clue what lock in is, and even if they did, couldn't point out which phones would earn the description. ANd even if they could, they couldn't care.