Slashdot Mirror
Windows Already Up and Running On ARM Architecture
syngularyx writes "Over at Microsoft's MIX Developer Conference in sunny Las Vegas, Microsoft has demoed a new preview build of Internet Explorer 10 (which you too can take for a spin, if you feel so inclined), and also dropped a little premature Easter egg – the build of IE10, and the underlying Windows OS, were both running on a 1GHz ARM chip. Sneaky."
But... But... But...
/rimshot...
How are they going to make it compatible with all those viruses and trojans out there?
At least based on my MS friend's claims... they probably have many such projects (say, like, a fully functional web-based MS office)
In fact I'd say this is one of those companies where such innovative ideas usually go to die, as they often "might windows or office cashflows".
Now that windows is threatened, then the skunkworks projects get revealed. The battle for ARM dominance is joined and now there are many contenders (WebOS, iOS, ChromeOS, etc).
Make sure everyone's vote counts: Verified Voting
It's about frickin' time! As usual MS take the longest to get on the trend train.
Windows CE has been running on ARM for about eight (?) years.
Except that is Android does run on iOS hardware, good point.
http://www.idroidproject.org/
Gone!
The NonStop didn't, and doesn't, run Windows. It runs a custom operating system called NSK, which is somewhat unique (each core runs a copy of the OS).
ARM isn't standardized like x86 is, so probably not... at least not easily. IBM PC clones use a fairly standard set of firmware and peripherals, whereas ARM-based machines tend to be largely custom, just with a degree of binary compatibility between them. Getting Windows running on an iDevice would take serious work.
Debian has supported arm since potato (2000)...
Sent from my PDP-11
It's about frickin' time! As usual MS take the longest to get on the trend train.
It's too little, too late. Even if Microsoft was able to get "true" Windows working perfectly on arm, what about all the 3rd party apps? What about Office? Outlook? Anything that matters in the Microsoft ecosystem?
With arm, Microsoft has to start from zero and compete on a level playing field. Something it has never been good at.
Have you got your LWN subscription yet?
What amazes me is how many of the young 'uns here are surprised, whereas we old guys remember when MSFT brought over Dave Cutler his big thing was portability and he had WinNT running on just about every chip out there.
So I wouldn't doubt they've kept a division of MSR going with an up to date portable version of the NT code base. what I don't see how they can keep from getting bit in the ass on is if they name it Windows people are gonna expect Windows apps to work which of course they most assuredly WON'T, not without a recompile that most companies simply won't do.
that is one I will hand to the F/OSS guys, if they want to run F/OSS OSes on the old Motorola 68k or any other chip they can do so if they spend the time recompiling it for the arch. Too much of Windows value is tied up in third party code that will simply not get off x86 anytime soon, and without it windows is pretty much worthless. After all people aren't gonna buy Windows licenses just to play Solitaire.
ACs don't waste your time replying, your posts are never seen by me.
Assuming that Microsoft doesnt jump the shark and do something totally unlike their past releases, like overtly junking all back-compatibility with x86 legacy applications (I see this windows offering being adapted for use on the emerging tablet market, where existing legacy application support, even if crippled, would be a big selling point), this offering will be technologically inferior to the existing (and based on more portable technologies) offerings like iOS and Android.
The reason is because this new windows flavor will have to JIT emulate the x86 instruction set for those legacy apps, and do all kinds of calisthenics to make shit happen between native binaries and emulated binaries. The ARM cpu uses less power, but is also somewhat more gutless compared to desktop x86 chips. It will suck hard trying to emulate that bloated dinosaur of an instruction set.
If microsoft finally sacrifices the holy vestal virgin of legacy compatibility (Its major strongpoint in corporate environments by a long shot-- Look at the immense power of zombie IE6) for its ARM port, it will suffer the same fate as all the previous alternative architecture builds (PPC, SPARC, Itanium, et al.)-- That is to say, it will die on the vine because users will hate it with purple pasion.
I am curious to see how microsoft pulls this off. If they were smart, they would do something similar to what Apple did when they switched from PPC to x86 commodity chips, and incorporate a special abstraction layer like Roseta. (Note, I am NOT an apple fanboi-- If you call me one, you are an idiot. Just pointing out something I thought apple did that was interesting.)
Sadly, like so many things microsoft does these days, it will probably be filled with so much useless bloat and duct-tape code that it will run like congealed dogpoo even on high end ARM hardware when trying to do such legacy support-- (again, if they even do it at all.)
I will reserve further judgement until I see it in the wild. It might be great-- but I wont get my hopes up.
Running the OS on an ARM chip isn't even half the battle. What about the apps? Has Microsoft created a "fat binary" format, the way Apple did for its migration from PowerPC to Intel? Are the development tools ready? Are all the Windows application developers lined up to recompile and migrate? How much of that stuff is still tangled up in assembler, anyway?
Microsoft's advantage has always been the breadth of its ecosystem. Now that's Microsoft's disadvantage. There's not much point to owning a power-miserly ARM-based Windows machine if the apps you've come to depend on aren't available. You might as well swallow the medicine and migrate to a more secure, stable OS with a future.
Pure .NET apps should work though, which will assist Microsoft in eliminating non-managed languages.
Exactly. Plus I seriously doubt they are going to get anywhere near the performance or efficiency that Linux (Android Linux, other Linuxes) or iOS does on ARM because they are so late to the game. I bet it would take years to tune it to work "well enough", which would STILL be way behind the competition.
So start with no apps, no performance, no efficiency, and probably not much demand. If they can pull off MS-Windows on ARM as a market success, I would be REALLY surprised.
Eliminate but not quite. The future of Windows is one where only authorized driver developers, Adobe, and game companies are allowed to run native code.
Fortunately Windows will probably be all but dead by then (except for in the business world).
Pfft. That's nothing. My browser release goes all the way to 11. It also supports the "beating-a-dead-meme" tag.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
The real value of Windows is in the massive installed base of applications that it has. I wonder how many vendors of important Windows applications will release an ARM build. I do hope that it will be as simple (for the most part) as recompiling the same source in an ARM-based build environment, but even so I wonder how many developers would do it. Good luck getting all those legacy VB6 apps running on ARM Windows though, or any other app for which the source is gone. Without the application ecosystem one might as well be using some other platform.
Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
Was that a joke?
Darwin, which is the actual OS underlying OS X is also the actual OS underlying iOS, which runs on iPhones and iPads. It's also open source.
CLR/.Net stuff should run fine I imagine. Also, I remember Alpha had FX32! which would run x86 code at decent speeds using static recompilation and that was many years ago now.
Holy cow, Batman! How much more backward can you understand the problem?
The reason x86 can emulate ARM is because ARM is *simple by design*. ARM cannot emulate x86 at decent speeds because x86 is a *pile of crap* from 30 years ago with legacy bullshit bolted on top of each new generation.
He's calling bullshit the fact that Windows has no infrastructure for an ARM release. They already showed off Office for ARM months ago.
OS is short for operating system. Flash has nothing to do with the operating system.
I know Slashdot has gone downhill in the last ten years, but are you sure you're on the right site?
Except it is unbelievably bad at it. touch only works half the time, accelerated graphics hardly ever works, trying to get 3g to work is a pain, accelerometers are practically useless, onscreen keyboard non existent. I think I’ll wait for 11.4 and unity ui to improve before i try it again. I love the concept of a Linux tablet but unless your a super duper programmer its probably not quite there.
Rocket Surgeon.
Not really. Every office I've ever worked in always had Office and at least a couple of other mission critical applications along with it. Be it Quickbooks with various plugins, photoshop, endicia, the ups app for shipping, etc. Office and ie are nothing on arm without the rest of the third party gang along for the ride.
The soylentnews experiment has been a dismal failure.
My installer says nothing below win 7 is supported either - are they already leaving Vista in the lurch?
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
Adobe? Why Adobe? Don't they introduce more exploits to a Windows machine than even Microsoft? I know I've read articles in the recent past that say more exploits are using Adobe products as the vector than all other vectors combined. And, you're going to give Adobe some kind of a free pass on the new architecture? Wow - you should be a politician. You certainly have the smarts for it!
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
Windows can't open OOXML documents. Office can. That's a whole 'nother kettle of fish, they had big problems getting Office for Mac from PowerPC to x86, and reportedly the Office for Windows codebase is even older and more convoluted. It'll be hard if not impossible to port to ARM.
The big problem, Windows will be at a big big disadvantage, and in fact I don't thik it'll be competitive:
1) It's bloated and poor-performing when compared to most Linux distros, or MacOS for that matter. ARM systems tend to me "small" (low processor speed, low RAM, etc.)
2) Applications. This is really Windows main (IMHO sole) strength, on ARM it is gone! You use Ubuntu, and you have a full set of NATIVE applications on ARM just as on x86*. You use Windows, you'll either have almost no applications (if it doesn't emulate x86), or you'll have all these apps that run at a fraction of native speed. Microsoft *had* NT running on HP PA-RISC, Dec Alpha, PowerPC, and perhaps one or two other platforms. The absolute lack of apps did the in (Alpha used an x86 emulator however.) There was Windows for Itanium, again no apps (it was really stripped, though, couldn't even print.)
---------------------
*Side note, i almost got into collecting some "exotic" computers, but after we installed Linux onto several, they were so indstinguishable from the regular PC experience I figured it wasn't worth it even if I could get them at a good price. I put Linux onto a DEC Alpha about 5 years ago, it was so similar to an x86 desktop that I would not have been able to tell it was an Alpha without looking at the case (which was a PC-like Case but said "Alpha" on it.) As a prank, my workmates switched my x86 Ubuntu desktop out for a PowerMac with Ubuntu, moved it into the same case, and got USB->PS2 adapters so my model M keyboard and all was plugged in, and put my home directory etc. back onto that. Seriously, I didn't notice it was a Mac until I rebooted and heard the Mac startup sound. We installed some distro on a PA-RISC, again it was indistinguishable from a x86 desktop. With a ARM based system you will not be disappointed with an ARM distro.
Windows NT was originally positioned as a portable, platform-neutral system and Microsoft made a big deal of it not being just limited to Intel architecture but also running on ACE platforms (remember ACE?), MIPS, Digital Alpha, and at least one other whose name escapes me. IBM PowerPC maybe?
Microsoft seduced and abandoned companies that committed to Windows on non-Intel platforms, with the abandonment beginning almost as soon as the seduction was complete. My employer made a significant commitment to Windows-on-DEC-Alpha--at that time, their specific application benchmarked over twice as fast on Alpha as on Intel. It was NT 3.51, IIRC, and Microsoft moved up to Windows 4.0 on Intel and kept dragging feet and making excuses on Alpha, finally acknowledging that it was not going to be supported. At that point, the Alpha systems bought by my employer's customers were barely a year old, and those customers were not happy with us for selling them such rapidly orphaned products.
What matters is not whether Windows can run on ARM, but whether Microsoft actually has any serious or durable commitment to supporting it on that platform.
"How to Do Nothing," kids activities, back in print!
Doesn't really matter what kind of device you are referring to, I was remarking more on how delusional one must be to think ie and office meet the needs of 50 percent of consumers. Last I checked, games were what was burning up the sales charts for tablets and smartphones. Neither of which ie or office are.
The soylentnews experiment has been a dismal failure.
Windows firewall programs aren't really firewalls, for the most part. They're more like ACLs for API calls involving sockets.
That's why when you run a Windows "firewall" program you don't generally see things like IP addresses, masks, protocols, port numbers, and state information. If you do, it's buried in the menus someplace, not the core function of the program, and likely added as a limited afterthought. They're definitely not a great example of bloat but they are certainly more resource-intensive than something like iptables and the relevant *nix kernel support.
The few times I have used a Windows sytem in the last several years, it was most disappointing. Where you could just write a few rules to cover your needs, now you have to go through a tedious list of programs and incrementally enable each one that may want to use a particular protocol after, of course, having some system tray pop-up distract you from whatever you were trying to get done. Depending on the "firewall", you may have to do it again when you upgrade/update the program since the executable has changed.
Really the only justification for this is the terrible host security of so many Windows systems, which leads to the hope that a strange executable the user has never seen before that wants to use the network might get noticed. It's one of the least efficient ways to operate a firewall. The need to enforce permissions that apply to system calls (of any kind, whether they are related to sockets, disks, etc) should be a core OS function that requires no third-party utilities. The need to regulate network traffic is a different problem that would properly have a different solution.
Honestly it's a fucking inelegant mess but it avoids the BIG SCARY OH NOES!! of requiring users who want to adjust a firewall to know a few things about how networks and firewalls work (sort of like the way we expect people who want to tinker with an engine to have skill as a mechanic and no one calls that unreasonable) or, failing that, to hire/consult someone who does. Like most of the culture surrounding Windows really. For those people who like it this way, use what you like and I say more power to you. To me, it's downright suffocating. I'd much, MUCH rather spend a few minutes reading up on networking, learn it one time, and do it the simple/elegant way from them on, rather than continuously do everything the hard way solely to avoid a little reading.
This set of priorities, more than anything else, is the difference between Windows "computing as a product" and many other systems. You can spend a great deal of time looking at differences in design and technologies without having a satisfying understanding of why things work out the way they do.
As far as antivirus goes, it's a terrible substitute for a good security system that doesn't treat the user like an illiterate idiot. I'm wondering how much worse the malware problem has to get before more people are willing to admit that antivirus is at best a band-aid and does not address the problem of security. Usually things have to become some big-ass crisis before people are willing to say "you know, the way we've been doing things doesn't work, maybe it's time to try another approach." Until then, those who said all along that something is not sustainable, is moving in the wrong direction, and lacks long-term viability are ignored and marginalized. Too often, that's the way it works.
It is a miracle that curiosity survives formal education. - Einstein
Windows NT had the same problem with PPC. It wouldn't actually run on a PPC Mac even though it was the most common machine out there.
IE running on Windows is about as exciting as grass growing in dirt - it works, but it is not exactly novel. As you said, Windows NT was designed on architecture independence. In fact, Windows itself is even endian independent, but it still reads and writes files in the native endian-ness (or so I remember from Alpha-NT). With ARM endian-ness is not a problem because ARM is bi-endian, so they can just use little-endian and be happy. If IE only uses the Windows API and the Windows API only uses a kernel built for the hardware, it should compile and run without any changes (because the Windows API is essentially a hardware abstraction layer with the kernel being hardware dependent).
Generally with this sort of design, the API itself is architecture independent (in this case, C++) code and hardware dependent pieces such as graphics, I/O, and devices are part of the kernel. Apple has pretty much the same thing in architecture independent Objective-C code on top of a hacked Mach microkernel (aka monolithic kernel based on mach) which they used to transition from PowerPC to Intel.
So... I will surprise everybody.
WIN8 running very very well already on ARM processors.
They rebooted WIN8 to the originally planned WIN7 micro kernel.
Win8 is a one microkernel with multiple interfaces to be booted up within 3sec.
1. It can be traditional PC
2. CAN be Tablet
3. Can be WInphone (Bye bye WInphone 7... if you didn’t realize it was/is just a research and UI project)
4. It runs inside TVs (Hello Samsung!)
5. Runs in the cloud.
6. It is the embedded.
The same Win8.
The Winphone 7 software delivery packaging implemented and further enhanced for consistent solution delivery.
One development toolkit to develop solution across all platforms.
You think it is not true. You don't believe that MS can pull this off. They already did it!!! Just they have learnt from Apple. SILENCE! You will be shocked.
People talking about the backward comp ability as an issue. This is NOT a problem anymore because of what MS done in the virtualization.
The virtualization is part of the kernel and can natively virtualize anything to achieve backward compability.
Have you ever thought what this Really really means? You should have goose bumps...
I'm not sure "seduced and abandoned" really captures the flavour of those heady days. From what I can recall, most of the companies involved were fighting fires on three fronts: their old-line proprietary businesses were getting chopped to bits by PC's and the war of attrition that was Unix at the time - the company I worked for had internal in-fighting as the unix and PC business started to threaten the old mid-range server business and competition BETWEEN companies was even more cut-throat. Sun was playing everyone for suckers as the Unix wars played out. Microsoft offered a plausible, one size fits all solution that looked like a complete end-run around Sun. Digital, in particular, the company with most to lose (vax, ultrix, a dead line of PCs that started with the wacky rainbow and ended up with them buying white boxes or 3rd party contracting out that part of big govt contracts) signed up big time. In fact the relief was palpable in their office nearby when the sales guys suddenly had a story to tell other than obvious loser products like OSF.
That NT never took off on anything other than Intel wasn't really Microsofts fault - in fact to think they orchestrated some Machiavellian plot to sucker a bunch of lucrative partners into mercy killing their businesses doesn't match what happened. What happened is that the customers woke up to proprietary hardware.
In a lot of ways, Sun looked like "the good guy" for 15 years but they really were kind of evil by currying discontent amongst the other Unix vendors (and even their own partners like Novell). Microsoft were the main beneficiary of Sun deciding to try to monopolise the Unix market which inadvertently made Windows a player beyond the desktop.
I think you missed the point. The ISA (instruction set architecture) may be standardized (even then, there are dozens of variants), but you don't even really have an idea what sort of bus you're going to be sitting on, let alone anything else. On an x86 system you know you've got a north bridge, a south bridge, a particular type of PIC, a certain kind of timer, PCI, etc. While you could certainly build a computer based on an x86 that is completely unlike that, it would be an oddball. On ARM systems, no, pretty much anything that isn't an industry x86 architecture, it's just total chaos.
Microsoft will end up specifying a particular reference platform. Those of us who have NDAs with MS will get the details in the next little while. I even know which variant of ARM is going to be used, though of course I can't say what that is right now.
I think we'll be surprised how many Windows apps will run on Windows 8 with just a recompile - or for that matter, just running through the .NET CLR. MS appeared to be pushing this way, one way or another, since the "Microsoft Java" days for application development, and their programming frameworks improving significantly along the way... it's not MSVC++6 anymore...
On the phone, I think the value Windows will provide will be:
* Real Outlook
* OneNote
* Modern security models
* More mature kernel with proper memory protection, etc.
* Adaptability/utility to the person who actually wants to use the device
Basically, it'll be what Windows Mobile should've been 5 years ago, and what Windows Phone isn't. At least, that's my theory.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
uh... by hardware problem i meant "hardware platform". problems on the brain @ work....
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
It's too little, too late. Even if Microsoft was able to get "true" Windows working perfectly on arm, what about all the 3rd party apps? What about Office? Outlook? Anything that matters in the Microsoft ecosystem?
Have you heard of .Net? All they need to do is write an ARM implementation of the CLR - something i'd wager they've already done - and they're good to go with all .Net apps. Why do you think there was the heavy transition by MS of so many of their apps to the .Net platform with the release of Vista and 7?
"Seduced and abandoned?" Not hardly. MS makes their OS for the processors it feels there is a market for. In the NT days, they decided to try it on some other platforms, since it was portable. Problem was hardly anyone was buying. Yes, yes your employer got on board, well one company is not enough to make a market for this kind of thing.
You are also incorrect about support, NT 4.0 supported Alpha, MIPS, PPC, and x86. With Windows 2000 they were dropping support for MIPS and PPC due to massive lack of interest, but initially planning on keeping Alpha support. You could get it in beta. However, Compaq announced they were dropping Windows on Alpha, so MS dropped it with RC1, since that was the last major vendor that gave a shit.
That means they supported Alpha versions of Windows NT from July 1993 (Windows NT 3.1) to June of 2004 (the date they stopped support for NT4) and they were releasing new updates for the OS until November 1999 (SP6's release date). That is not an insignificant timeline. They didn't exactly role it out and kill it a year later.
The thing is Alpha was dying by the end of 1999, when Windows 2000 was launched. Like I said, Compaq stopped supporting Windows on Alpha (and they owned DEC at that point). In 2001 they sold Alpha to Intel, killing all development for it.
So either you are pissed off because you made a bad decision, and got bitten for it (if it got orphaned in one year, you were selling your products in 2003, which means Alpha had been officially dead for two years) or you are just making stuff up because you dislike MS (given that your statements do not fit the facts).
So, what'll happen with Windows on ARM (presuming they release it, could be just a test or for embedded applications)? Well that'll depend on the market. If there is strong demand, they'll keep making it. If nobody wants it'll they'll phase it out.
Same shit with IA-64. MS supported that in Windows 2000 Server, and has continued support for it with Windows 2008R2. However demand has been declining, so they've said 2008R2 will be the last Itanium version unless anything changes. They didn't support it for one version and drop it, they supported it as long as there was demand, and if demand picks up again, so can support. It also isn't like they make it a surprise. They've announced support is stopping, however 2008R2 will be supported at least until 7/10/2018 (that is their guaranteed date for support, they can extend it). So it isn't like there isn't some time to make a change.
Does anyone write "Pure .Net apps" though? A serious question, as I can't think of an app that I've written that is pure .Net. I always need to include some pInvoke (Platform Invoke or Windows API calls), which can make code less than portable (depending on memory packing / variable alignment, pointer size, etc.). However, since I write code to help maintain our Windows images and also as utilities for users (not as large applications), perhaps my perception is a bit skewed.
I need to use p/invoke in about half of my projects, usually to shell functions (e.g. requesting information about explorer shell items, building context menus, and the like). That's necessary for seemless integration with the desktop. But I suspect p/invoke to windows api functions will still work, it's only p/invoke to a custom dll or using a non-MS COM object/activex control that is likely to fail, so we should both be in the clear...
Thing is, emulation introduces a huge overhead. You really don't want to do it unless the architecture you're emulating is several times slower than the host architecture you're emulating it on.
That's not the case with emulating x86 on ARM.
I think the purpose is less to do with "let's run Windows everywhere" and more to do with "this way we only need to maintain one OS and maybe a different shell for tablet devices. With the added bonus that we can still take advantage of the Windows name as a marketing tool".
You clearly haven't worked with any embedded systems. The PC architecture is well defined and, for the most part, backwards compatible. There's a reason you can still put a windows 95 CD in a machine and it will be able to find the display controller, enumerate the PCI busses etc. It's because much of that stuff is not going to change. Might be because the BIOS or the chipsets provide a static abstraction layer over the underlying system, but it doesn't matter - from a software view everything works the same.
When you get an embedded system what you have is a cpu core (ARM, PPC, whatever) and a whole bunch of other silicon IP on the same chip that provides additional functions. So if you want to get to the PCI bus, you need to know how that's been interfaced. Presumably there's some IP core on the chip somewhere that provides the PCI connectivity, but how do you access it? Is it at a certain memory address, do you need to write some magic control register to enable it, do you even know how it works?
If you want an example - have a look at your linux source. In my arch/x86/config I have two defconfig files, one for x86 and one for x86_64. That's it for every single PC platform out there, laptop, desktop, server, whatever. Now have a look at arch/arm/configs or arch/powerpc/configs. See the difference? Many of those will come associated with platform specific code to support that architecture. That's how Linux does it - you provide the interface between the standard system code and the underlying hardware and everything falls into place, no doubt the Windows port is similar. ARM is a CPU core, not an architecture.
Thing is, emulation introduces a huge overhead
The thing is, no it doesn't. For one thing, most modern emulators don't emulate everything. A platform like Windows ships with a large number of standard libraries, including things for drawing and even video playback. When you draw a line in a window, 99% of the CPU time is spent computing the pixel intersections, and this is all done in Win32 code. When you draw a character on the screen, you're drawing a set of antialiased bezier curves and compositing them onto a buffer. Pretty processor intensive. However, when you do this in emulated code, only the initial call is emulated - the 99% part is native code.
For really CPU-intensive things, like video decoding, this can be even more pronounced. A Windows app playing back video will typically use DirectShow filters for the decoding. It passes a chunk of data to the filter and gets a decoded frame back (often passing it directly to the display device). In an emulated environment, the decoder filter will likely run on the ARM SoC's DSP, and the emulated code will be woken up periodically to pass it new data. Very little of the application actually runs in the emulator.
For 3D stuff the code is even shipped as bytecode already. nVidia and AMD don't even provide the same instruction set between product generations, let alone between vendors. When you run a 3D application, all of that shader code is already being JIT compiled (by the drivers) for the current target GPU. Doing it for the GPU on an ARM SoC is not a challenging problem.
I've written an article on the challenges Microsoft faces with the ARM port. None of them are insurmountable.
I am TheRaven on Soylent News