Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Microsoft Windows Intel Internet Explorer Hardware

Windows Already Up and Running On ARM Architecture 348

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."
This discussion has been archived. No new comments can be posted.

Windows Already Up and Running On ARM Architecture

Comments Filter:
  • by Daniel Phillips ( 238627 ) on Tuesday April 12, 2011 @08:26PM (#35801990)

    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.

  • Comment removed (Score:5, Insightful)

    by account_deleted ( 4530225 ) on Tuesday April 12, 2011 @08:27PM (#35801992)
    Comment removed based on user account deletion
  • by wierd_w ( 1375923 ) on Tuesday April 12, 2011 @08:32PM (#35802042)

    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.

  • Reality check (Score:2, Insightful)

    by jmorris42 ( 1458 ) * <jmorris&beau,org> on Tuesday April 12, 2011 @08:32PM (#35802046)

    Yes Microsoft is going to chase the trend and make something for ARM, otherwise they cede the mobile space to Apple and Google. However, while they will call it Windows 8 it won't bear much relationship to the x86 edition we all know and either loath or love.

    1. Anyone think Microsoft (or any of their hardware OEM partners) are remotely interested in releasing what we think of as an Operating System on a new mobile platform? Not when they can lock it down hard and rake in the same 30% Apple gets from their app store. Do not think it an accident Microsoft also leaked screenshots of thier app store this week.

    2. No, it won't run any existing Windows apps. ARM is puny, x86 is strong. x86 can emulate ARM (see iOS and Android dev environments) but there is no way ARM is going to emulate x86 apps at a usable speed. Assuming of course I'm totally full of crap on point one and unsigned apps were somehow permitted in the first place. Exception possible for .NET projects with no native code, but again see point one.

    3. Even if you could, smartphones and tablets are a different environment so an existing Windows app would be lame.

    4. Microsoft has ported Windows in the past. They even got some of their own apps running. I'm told Alpha even had most of Office running native vs via FX!86 before the end. But 3rd party buy in wasn't there and they suffered something similar to the fate of Linux. No 3rd party apps means no large deployements which means no interest by developers to port the 3rd party apps. If Microsoft can make cross porting totally painless this time they might have better luck, but again see point one and three. Just having an ARM binary of Photoshop crap out of Visual Studio along with the x86_32 and x86_64 copies won't result in a product Adobe would be willing to sell to tablet customers. Also have to wonder if they will like giving Microsoft 30%. Yes the normal retail path eats more but BestBuy isn't out to kill them.

    So if Windows on ARM gains little from the existing catalog of "Windows" applications, will almost certainly require more robust hardware (battery life is issue one) to run it vs Ubuntu or Android and might even piss off customers who won't realize that Windows != Windows will it get traction?

  • by yelvington ( 8169 ) on Tuesday April 12, 2011 @08:36PM (#35802062) Homepage

    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.

  • by Anonymous Coward on Tuesday April 12, 2011 @08:49PM (#35802196)
    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).
  • by Elbereth ( 58257 ) on Tuesday April 12, 2011 @08:50PM (#35802204) Journal

    What are you calling bullshit on? Where is your evidence that it is indeed bullshit? Do you have anything of value to actually say?

  • by dido ( 9125 ) <dido AT imperium DOT ph> on Tuesday April 12, 2011 @08:55PM (#35802238)

    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.

  • Real Reality Check (Score:2, Insightful)

    by Anonymous Coward on Tuesday April 12, 2011 @09:09PM (#35802340)

    ARM is puny, x86 is strong. x86 can emulate ARM (see iOS and Android dev environments) but there is no way ARM is going to emulate x86 apps at a usable speed.

    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.

  • Re:holy crap! (Score:0, Insightful)

    by Anonymous Coward on Tuesday April 12, 2011 @09:25PM (#35802466)

    Um...it generally gets you off if you're the pitcher...

    if you are homosexual i guess it has a strong appeal to you. not really any other way to have penetrative sex with a man.

    if you are heterosexual ... i don't understand that one. maybe you do not have a real deep intimate emotional and spiritual connection with your partner so that any kind of romance or sex or even just curling up with her and watching a good movie is wonderful and satisfying .. so you're bored and think some kink will make up for the mediocrity of your realtionship.

    otherwise, meh, why do you want to do her in the anus when a much nicer more appealing hole is about an inch away that will probably give her more pleasure and less discomfort? i suspect men who really like to have anal sex with women might be latently gay or have some of the tendencies but they don't know it because they are scared of the "fag" label and do not want to explore such a question. call it denial or whatever you like. as a heterosexual i can tell you that lesbians find a certain acceptance where gay men can be repulsive to both men and women, right or wrong that's the reality.

  • by walshy007 ( 906710 ) on Tuesday April 12, 2011 @09:27PM (#35802484)

    They already have the solution to that,. .net, it is just in time compiled on x86 too and so once they port the .net framework over all things written in it will work just fine.

    Sure you will lose native x86 compatibility, but there are many apps already out in .net that will work just fine, and you can code for x86 windows and arm windows in the same way.

  • by oakgrove ( 845019 ) on Tuesday April 12, 2011 @09:40PM (#35802568)
    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.
  • Re:Question (Score:5, Insightful)

    by causality ( 777677 ) on Tuesday April 12, 2011 @10:24PM (#35802884)

    I think you mean bloating of the OS, not CPU. And a firewall hardly adds bloat, it's in the kernel (although I must admit I'm not sure if that's where it is in Windows... I sure hope so).

    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, Microsoft Security Essentials is actually very good, and extremely lean. There's not much reason to use any of the commercial antivirus bloatware anymore.

    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.

  • by pclminion ( 145572 ) on Tuesday April 12, 2011 @11:04PM (#35803176)

    The PE format most decidedly doesn't support fat EXEs. Read the spec [microsoft.com], page 12, if you need proof. There's only one field in the file for the architecture type, and that field can only hold one value. There are no currently documented methods for embedding multiple PE sections for multiple architectures into a single file. That isn't to say there isn't some way it could be shoehorned in, but as of yet, there is no way to have a fat EXE on Windows.

  • Oh give it a rest (Score:5, Insightful)

    by Sycraft-fu ( 314770 ) on Wednesday April 13, 2011 @02:23AM (#35804482)

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

  • by squizzar ( 1031726 ) on Wednesday April 13, 2011 @06:18AM (#35805502)

    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.

  • by Anonymous Coward on Wednesday April 13, 2011 @06:41AM (#35805582)

    It'll be hard if not impossible to port [Microsoft Office to] ARM.

    Why do people keep saying this? Office is written in various high level languages. All they have to do is recompile it. Just like any other applications. Just as they have clearly done for Internet Explorer.

All seems condemned in the long run to approximate a state akin to Gaussian noise. -- James Martin

Working...