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

[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

[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

[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

[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

[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

[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

[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

[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]

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

[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

[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

[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

[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.

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...

[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...

[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...

[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: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.

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:"Ubuntu is already starting to ship on some ARM

[Yvan256]

Ubuntu is the Arduino of Linux distros.

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: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.

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: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.

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 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.

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.

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.

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.

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.

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: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.