intel license ARM technology?
How long will it take?
Before they do...
Microsoft looks to have created a version of Windows Server that runs on ARM processors. Loquacious sources close to Microsoft confirmed a "test version" of Windows Server is up and running, but the report from newswire Bloomberg was scant on other details. That's not a stunning feat: having developed Windows RT – a version …
Most of the HAL was removed in NT 4 to improve speed on x86.
Well according to this support article at least some of it still exists in Win2k8 (search for 'HAL'). But I confess that I wouldn't be surprised if it was cut down from the original concept and implementation. But based on web searches something by that name still exists and is doing a lot of what you'd expect it to since people changing their hardware are getting STOP 0x79 which means 'MISMATCHED_HAL'.
The main problem is the x86 model. Turns out that context switching is very slow so you put things (networking, printer, etc.) in the kernel to make them run faster. The kernel is architecture-specific. This is why NT 3.5.1 was more stable and secure but slower than NT 4 and later. By then there weren't any customers interested in anything other than x86.
C# and .NET do dive a degree of insulation from the architecture when it comes to apps.
Indeed, it is easy, Windows NT was built multi-arch from the ground up.
The one problem they will have is the same one OpenSolaris has ... drivers. They do expect everybody to write drivers for Windows, well, that does not work out so much since XP 64 and Windows Server 2003. Windows 7 has had better driver support, yet a lot of old hardware remains unsupported and look at the state for Windows 8[.x] !
The second problem they face is software, NT software from 3rd parties is not a recompile away from a new hardware platform, unlike the Linux/Solaris/FreeBSD equivalents.
Windows Server has a footprint in the tens of Gb; compare that to the tens of Mb the competition has.
meanwhile there is multiple well supported ARM based distro's for linux - and I mean distros that have nearly the entire software stack available (i.e 1000's of packages - no flash - but that is a blessing.)
Its easy generally for open source software to be rebuilt for ARM - closed source - not so much.
Like all those cash machines? Ooops, no they run Windows. All those medical devices? Ooops no they run Windows CE.
And what are they left with now? An unsupported OS that the vendor (MS) is actively advising against, riddled with vulnerabilities and the stability even a recent graduate would be embarrassed of.
Their mission critial LOB systems are simply dismissed as "legacy software" by MS, written with libraries/frameworks that are over 3 generations old where the experts are rapidly dwindling and are no longer as cheap as they once were - far from it.
"ooops" indeed.
We have to build with Developer Studio 2005 because Microsoft dropped support
It's dreadful the way we have to do things like that. It makes us extremely wary of committing to Microsoft in the future - even if there's no alternative (which is rare nowadays).
The pathway to Microsoft is paved with dead technology.
"Its easy generally for open source software to be rebuilt for ARM - closed source - not so much."
Assuming that you have the source code (as Microsoft obviously do) then it would be no more difficult than to port closed source. Easier if anything in this case due to the HAL based design of Windows.
Windows used to support 4 different CPUs types, and already runs on ARM for phones and tablets.
We had a bunch of Alpha NT machines back in the day. Nothing worked. All the (useful) Windows software was closed source and no-one would sell us Alpha binaries. Even the official release of Microsoft Office for Alpha (4.2?) was flaky.
Eventually, we gave them away. I took one home to use as a server, but as it ran a buggy version of Windows NT 3.51, it wasn't much use for that either. It could have probably run Linux, but Linux was fairly primitive back then...
Back in the day, there was a remarkable tool for NT/Alpha called FX!32 which would do an on-the-fly translation of a Win32 application from x86 to Alpha (and save the results). That kind of thing is relatively routine these days.
FX!32 didn't help with Win16 stuff or with off the shelf x86 drivers, or with "support" from commercial app or driver vendors, which meant that an NT/Alpha box was still a bit of a specialist box.
"Even the official release of Microsoft Office for Alpha (4.2?) was flaky."
That's the thanks DEC got for trusting promises from Microsoft. There's a story goes around that Office for Alpha had been shipped with the debug code left in, with all the performance implications that might have.
Assuming that you have the source code (as Microsoft obviously do)
They only have the source code for the OS and a few supporting apps like Office.
What use is an OS without the software? I mean, take a look at Windows Phones!
Closed source developers will not port to ARM because it costs them money.
Fortunately for Linux, it's virtually an automated process to port almost an entire package repository. Windows just doesn't have that luxury.
Possibly Microsoft are doing this to put a bit of pressure on Intel for some reason. The cost of doing a test port of Windows Server to ARM probably does not exceed a few million dollars (if that) which is very small change to Microsoft. Microsoft might be trying to apply a bit of pressure on Intel to get them to produce faster CPUs (faster single threaded performance especially) to drive a new PC update cycle (with the resulting new Windows licence fees). ARM CPUs have been increasing in performance faster than Intel CPUs over the last several years and telling Intel that Windows might not remain their exclusive domain puts pressure on Intel to improve their CPUs
A windows version for arm will be just like windows for alpha, ppc, mips and ia64... Absolutely useless because there will be little or no native software for it.
Most applications for windows are closed source and will be compiled for x86, so you won't get them running on arm.
You would probably be able to get open source server software running on windows/arm without too much difficulty, but virtually all such software also runs on linux and has already been built for linux/arm.
Linux/arm is also tried and tested, whereas windows/arm is new, and you also have no guarantee it wont suffer the same fate as the other non x86 versions of windows and get abandoned in short order.
Yes we were here before. I think in 1992/1993 there was some other cpu type that the original development was happening on. The 64 bit XP Itanium Workstation version was quietly dropped possibly even before Vista was released. The other versions died with NT3.5x / NT 4.0
However potentially there are more native applications likely for ARM than Alpha, 64 bit Alpha, PPC, MIPS and Itanium, especially for server. I did after all have MySQL, Apache and X running on Windows before I ditched our last Windows server.
Too true @Mage, this does have a vaguely familiar smell to it.
I am slightly surprised it took them so long. I would have thought releasing the Windows Server for ARM at the same time as WindowsRT might have given them a more coherent message and demonstrated a commitment to the ARM platform. But that would have left open more questions. A Windows Server for ARM might be expected to have some of the goodies they left out of WindowsRT - domain membership, for example.
> A windows version for arm will be just like windows for alpha, ppc, mips and ia64... Absolutely useless because there will be little or no native software for it.
Not quite. Expanding the WinRT API would provide application-level compatibility across any Windows kernel. Which would be nice, really, and a rather better development experience (write once, er, that's it) than even linux provides.
I note, however, that the report does not indicate any useful expansion of WinRT.
a rather better development experience
That's highly subjective. It's only good for developing MS technology (of the day).
I've been a Windows developer since 3.0 (I have MCF/COM/.NET/etc. tattooed on my arse), and I've recently moved to Linux and that's made me realise developing under Windows was so... primitive and restrictive - both technical and cultural. (I still have MSDN, because I maintain "legacy" systems). I've 20 times more experienced with Windows, yet I can get more done with Linux.
I was actually going to add a "however.." part, but I can't think of anything positive to say about developing under Windows. Ah... for developing Windows apps Windows is probably adequate.
Microsoft 'bought' Insignia Solutions (or at least took out a pretty much exclusive license) for their SortPC technology that allowed 'foreign' binaries to run on a particular architecture, a feature called Windows-on-Windows (WOW).
This meant that you could have had shrink-wrap Windows applications that should run on all Windows platforms. I doubt that the technology was maintained when Windows became x86 only.
I see a possible future of computing here.
Proper real Windows running on your phone/work phone/BYOD.
At work, you dock it and work on proper keyboard and big screen.
On the train you tether it to a tablet screen for a few odd tasks or media consumption.
At home you re-dock it to a proper keyboard and screen, or any other hardware that takes your fancy, log onto work VPN and carry on working if needed.
Funny, I can write stuff using Google Docs on the iPad and sync it via my mobile acting as a hotspot, then pick it up and continue working on the document at home on the PC.
A sync solution and compatible software is what is needed. The underlying OS/tech is less important.
Windows has variously run on MIPS, Alpha, PowerPC, ARM and Itanium in the past. The actual challenge has less to do with the hardware Windows is running on and more with persuading 3rd parties to support it.
I bet 3rd parties already find it a hassle to make 32-bit / 64-bit builds of their software without adding another architecture. Microsoft could make it more attractive if their compilers could spit out virtual machine executables (using something like LLVM bitcode) which could run on any architecture at near native speeds.
I suspect a lot of these Windows-on-ARM projects are to counter claims that Windows is a lost cause and will fade away with ARM processor usage on the rise.
There are plenty of Linux and ARM fans who would argue that case and there's a whole arsenal of anti-Windows and anti-Microsoft rhetoric which Microsoft has to address. I hear plenty of anti-Microsoft fanbois claim Microsoft can't or won't do this or that and their doing it rather proves them to be utterly wrong. It won't stop the anti-Microsoft invective but it keeps Microsoft in the picture.
It really is no big deal for people to build ARM versions of their executables. We already do it for x86 and AMD64. Having sorted the build process for 'more than one', the third is easy. Visual Studio has support for compiling your C++ to ARM already, just add it to the build configuration and the batch build will spit out all three version. And the .net ones are in IL code anyway, that is compiled and optimised for the specific processor it ends up running on.
the small matter of just how to get applications written for x86 running well under ARM
A very small matter. I doubt whether more than a handful of applications still depend on assembly language for anything and probably even fewer have actually been optimised with an eye to the strengths of the x86 family.
They'll run as well on ARM as they do on x86 and unless Microsoft's ARM compiler has gone backwards in the past ten years it will just be flicking a switch in your IDE.
So Googling this, NT 3.5 supported IA-32, MIPS, and Alpha; NT 4.0 supported IA-32, MIPS, Alpha, and PowerPC. Windows 2000 if I recall, DEC had up through some beta version of Windows 2000 running before they dropped it. The HAL is still there. The problem they ran into as I understand it was by XP, the HAL was still there and portable, kernel was still prety portable, but above this portable level the libraries and execuables they pulled in from Win9x series, and some of the newly written code, was not particularly portable (assuming 32-bit little endian for instance). Keep in mind Xbox also runs a Windows kernel on PowerPC (just not the usual Windows userland.)
Looking in my crystal ball here.. first off, I'm assuming Windows Server for ARM will be traditional and not WinRT-based. OK. Windows for Itanium was a full port; if you look at it's feature list, it's rather incomplete. But, the features it does support are a likely bare minimum of what I would expect Windows Server for ARM would support, these portions are likely already portable.