Slashdot Mirror


Taiwanese OEMs Consider ARM Products For Windows 8

siliconbits writes "At CeBIT 2011, we went around the stands from some of the biggest component manufacturers in the world and asked them a simple question, would you consider bringing out ARM products (barebones, laptops, tablets, motherboards) for Windows 8? The answer was a unanimous yes; like Microsoft, the same firms that have been faithful Intel and AMD partners for years are prepared to explore other territories as soon as Windows 8 will go live."

167 comments

  1. Dumb question - of course they'll say yes. by tomhudson · · Score: 5, Insightful

    What did you expect them to say - "No, we won't - we'll cede that market to our competitors, because our customers prefer products with crappy battery life"?

    1. Re:Dumb question - of course they'll say yes. by RobertM1968 · · Score: 3, Insightful

      What did you expect them to say - "No, we won't - we'll cede that market to our competitors, because our customers prefer products with crappy battery life"?

      Parent is correct... and for even more reasons than indicated. (no, this next section is not a slam against MS... read through the whole thing) Sure, Win8 may bomb on such things (pick a reason: no interest, Microsoft yet again not fulfilling their promise to have something actually suitable for such devices, Win8's requirements being too absurd for such "minimalist" hardware, whatever)... but the simple fact is, it may gain traction and take off. On that possibility, there isn't one OEM with half a brain that would say "no, we aren't doing this" at this point in time. When the correct time comes to make a decision, they'll choose to (a) release some test bed units, (b) dive full in or (c) look away from Win8 and concentrate on other things - but now is definitely not them time for them to say no, especially under the possibility that they will need Microsoft's good will in the future (assuming Win8 proves suitable and desired on such devices).

    2. Re:Dumb question - of course they'll say yes. by Anonymous Coward · · Score: 0

      Also, it's not a lot of work to load an OS onto your device if the OS is designed for it. No skin off of their noses.

    3. Re:Dumb question - of course they'll say yes. by poetmatt · · Score: 1

      these companies are already making ARM products, it's just that they'll be making them for the next windows version when it comes out. So this is a change of nothing.

      hint: it's not going to be called windows 8.

    4. Re:Dumb question - of course they'll say yes. by arivanov · · Score: 1

      Wrong question, wrong answer.

      All major Taiwanese manufacturers have been shipping ARM based devices for years. The only difference as far as they are concerned is that instead of WinCE 3 years ago and Android today they will be shipping Win8. They are not the ones who support the end product and do the software development for it so they could not care less what it actually runs.

      --
      Baker's Law: Misery no longer loves company. Nowadays it insists on it
      http://www.sigsegv.cx/
    5. Re:Dumb question - of course they'll say yes. by mwvdlee · · Score: 2

      hint: it's not going to be called windows 8.

      Yes, it would be uncharacteristic for MS to settle on a versioning scheme.
      We've already had version numbers, two-digit years, four-digit years, single-digit numbers, acronyms and names.
      The only thing left is using nonsensical symbols like Prince did; TOSFKAW.

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
    6. Re:Dumb question - of course they'll say yes. by gl4ss · · Score: 1

      I got a bet riding that it'll just be a drop of the whole naming shenigans totally. so it would just be windows. no windows apex, no windows eitty, no eight-eight. it's stupid enough to produce a new year-named server edition every couple of years(stupid as there's no good ideas about what to add, actually) or to make a new naming for every change of the default theme.

       

      --
      world was created 5 seconds before this post as it is.
    7. Re:Dumb question - of course they'll say yes. by poetmatt · · Score: 1

      I doubt it. You've still gotta call it something. Forget shenanigans, but you can't call every version windows or how are people going to be able to differentiate?

      The server editions are very straightforward names. Can you not tell the diff of server 2k3, server 2k8, and server 2k8 r2? That's not exactly marketing buzzwords. Do you have a problem with new server editions which have substantial changes in, well, server?

    8. Re:Dumb question - of course they'll say yes. by Ancantus · · Score: 1

      Yes, it would be uncharacteristic for MS to settle on a versioning scheme. We've already had version numbers, two-digit years, four-digit years, single-digit numbers, acronyms and names. The only thing left is using nonsensical symbols like Prince did; TOSFKAW.

      I am betting on Greek symbols, or one of the curse words I invent while staring at a Blue Screen Of Death.

      --
      Violence is the last refuge of the incompetent. -- Isaac Asimov
  2. Good by betterunixthanunix · · Score: 3, Funny

    OK, finally we are moving away from x86 and toward RISC. We are only 20 years behind schedule, but hey, better late than never.

    --
    Palm trees and 8
    1. Re:Good by Anonymous Coward · · Score: 0

      And since it's "move to RISC if Windows moves to RISC too", we'll be trapped with RISC for another two decades if something even better comes along.

    2. Re:Good by spiffmastercow · · Score: 2

      We moved away from x86 over a decade ago.. The instruction set for x86 is emulated in hardware. But yeah, hopefully this will mean at least a move to a sane assembly language. Not that anyone even uses assembly anymore...

    3. Re:Good by betterunixthanunix · · Score: 2

      The microarchitecture argument is not very convincing -- yes, the instruction set is translated, but in the end, you still expose the x86 instruction set. As an example, we still have to deal with floating point registers that are arranged as a stack, although some compilers (GCC for example) have a option to use SSE registers and instructions as an alternative. In general, x86 inherits a lot of very outdated designs, which can be very annoying when you are forced to deal with them (or which just waste space on the die if nobody uses them anymore).

      --
      Palm trees and 8
    4. Re:Good by partyguerrilla · · Score: 2

      RISC architecture is going to change everything.

    5. Re:Good by Anonymous Coward · · Score: 1

      OK, finally we are moving away from x86 and toward RISC. We are only 20 years behind schedule, but hey, better late than never.

      MS-DOS was running on ARM's x86 emulator in 1987.

    6. Re:Good by Svartalf · · Score: 1

      Depends on if your'e doing kernel code or similar. The device driver and OS dev crowd still uses it...

      --
      I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
    7. Re:Good by Desler · · Score: 0, Flamebait

      A modern "x86" chip is RISC tardo. Way to be a decade or more behind the times when it comes to Intel chip designs.

    8. Re:Good by hittman007 · · Score: 3, Informative

      As I recall Windows NT 4.0 was independent of hardware. They had this concept they called HAL, which did all of the communication when it came to hardware. You had an alpha chip, no problem, just get a alpha HAL. I have in person seen Windows NT 4.0 running on other architectures, including alphas and apples of the day (long before they switched to intel equipment).

      I'm guessing they dropped this capability with one of the newer incarnations...

      --
      --- When you start with the conclusion that you want, then throw out any facts that don't agree, is it true?
    9. Re:Good by Kjella · · Score: 5, Insightful

      RISC won 20 years ago, all x86 processors decode to some internal instruction set. I am certain the engineers at Intel and AMD have tested exposing the native instructions and if it could perform much faster than x86 I'm sure they'd enable applications to bypass the hardware decoder and send micro-ops directly. While they still process the instructions the really obscure ones live in microcode instead of hardware, x86_64 adjusted the number of registers etc. so most things have been tweaked. I don't need to remind you that the last attempt to do better was the Itanic...

      --
      Live today, because you never know what tomorrow brings
    10. Re:Good by the+linux+geek · · Score: 1, Insightful

      No it isn't. Way to lose the whole point, which is predictability of how many cycles an instruction takes.

      Not that it matters at this point. VLIW, like in high-performance DSP's and certain niche processors, is the future.

    11. Re:Good by Sponge+Bath · · Score: 2

      It's been a long, long time since I've used assembler for a driver in Windows (Win 3.1/95) era, and I've never needed it for Linux. Even for core kernel devs it is more the exception than the rule. These days, the ultimate language of all time, C, rightfully rules for these tasks.

    12. Re:Good by Sponge+Bath · · Score: 2

      "VLIW, like in high-performance DSP's and certain niche processors, is the future."

      I want an Itanium in my iPhone!

    13. Re:Good by RobertM1968 · · Score: 2

      As I recall Windows NT 4.0 was independent of hardware. They had this concept they called HAL, which did all of the communication when it came to hardware. You had an alpha chip, no problem, just get a alpha HAL. I have in person seen Windows NT 4.0 running on other architectures, including alphas and apples of the day (long before they switched to intel equipment).

      I'm guessing they dropped this capability with one of the newer incarnations...

      Ummm... yeah, kinda... other than the massive portions that are monolithic and definitely tied to the hardware in NT 4. XP has a HAL as well... guess which other versions do also? As a matter of fact, most OS's have a device abstraction layer. Such does not make a multi-platform OS, as both IBM (OS/2 PPC) and MS (Windows NT for certain RISC schemes) can tell you via the problems they had getting their operating systems to run on non Intel compatible hardware. Even with how modular OS/2 was (in comparison to Windows), there were still various problems due to... rewriting and/or recompiling the rest of the OS.

    14. Re:Good by perpenso · · Score: 1

      As I recall Windows NT 4.0 was independent of hardware ... I'm guessing they dropped this capability with one of the newer incarnations...

      They dropped it only in the sense that they no longer offered it to the public. Recall that Windows NT was started on MIPS, x86 came later. The goal was to make sure the code was portable between architectures. My understanding is that internally MS kept building NT (XP, Vista, 7, ...) on non-x86 platforms to maintain/verify portability.

    15. Re:Good by WrongSizeGlass · · Score: 1

      OK, finally we are moving away from x86 and toward RISC. We are only 20 years behind schedule, but hey, better late than never.

      Does this mean I'll finally be able to use my books on CHRP?

    16. Re:Good by RobertM1968 · · Score: 1

      OK, finally we are moving away from x86 and toward RISC. We are only 20 years behind schedule, but hey, better late than never.

      MS-DOS was running on ARM's x86 emulator in 1987.

      Well, that's not quite the same as running natively on it... even though somewhat similar to how things run on today's 64bit CPUs.

    17. Re:Good by Rockoon · · Score: 5, Informative

      Most (all?) 64-bit compilers produce SSE single precision and double precision code by default. It is the x87 stack that is the odd-man out, contrary to what you are making it sound like.

      All x64 CPU's support both single and double precision SSE, which is why its the default for 64-bit targets. If you are targeting a 32-bit OS, then a 32-bit binary cannot simply assume that single precision SSE is available, let alone the later double-precision support of SSE2.

      Also, the x87 FPU performs calculations in 80-bit precision, so is not directly comparable to SSE's single and double precision features.

      Finally, it is not "some compilers".. its ALL THE MAJOR ONES, both 32-bit and 64-bit.

      --
      "His name was James Damore."
    18. Re:Good by peragrin · · Score: 1

      x86 on MiPs required a secondary x86 coprocessor that changed the instruction set.

      So if it started on MIPS then it did so very poorly.

      --
      i thought once I was found, but it was only a dream.
    19. Re:Good by Anonymous Coward · · Score: 0

      Most VLIW is RISC not CISC. Also intel was not behind anything, the developers were: http://en.wikipedia.org/wiki/Intel_i860.

    20. Re:Good by LO0G · · Score: 1

      NT has always supported RISC architectures. Even today Itanium is supported on Windows Server 2008 R2.

      In fact, NT was first developed on MIPS and i860 RISC chips, the X86 port came later (seriously). Back in the 1990s, there were active NT versions for MIPS, PPC and Alpha and Itanium. There were even rumours of a Sparc port.

      The reason that most of those ports aren't alive today is that the hardware manufacturers told MSFT that they weren't interested in supporting NT for their platform any more.

    21. Re:Good by Bert64 · · Score: 1

      You used to be able to emulate x86 on the Amiga too, using applications such as PC-Task or PCX...

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    22. Re:Good by Bert64 · · Score: 1

      Exposing the micro-ops would mean they have to keep some compatibility, keeping them hidden behind x86 means they can change the micro-op functions all they like without impacting compatibility.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    23. Re:Good by Rockoon · · Score: 1

      RISC won 20 years ago, all x86 processors decode to some internal instruction set. I am certain the engineers at Intel and AMD have tested exposing the native instructions and if it could perform much faster than x86 I'm sure they'd enable applications to bypass the hardware decoder and send micro-ops directly.

      No need, as they are already exposed directly. Plenty of instructions that emit a single micro-op... for example, most of AMD's DirectPath instructions emit a single micro-op and in fact, 100% of AMD's micro-op's can be found in the set of DirectPath instructions.

      --
      "His name was James Damore."
    24. Re:Good by bhtooefr · · Score: 1

      No, it didn't require a secondary x86 coprocessor.

      It just ran on MIPS.

      The problem is, x86 userland software didn't run without being recompiled (except for a badly emulated DOS environment), so if your software vendor didn't compile for MIPS, you were screwed.

      On Alpha, DEC did a profiling recompiler for NT, and due to the speed of the Alpha, that approach nearly worked, except for Compaq getting distracted by Itanium, and cancelling Alpha stuff just as it was picking up steam into Windows 2000.

    25. Re:Good by lkcl · · Score: 1

      I've been trying to get an article through slashdot submission which describes exactly this: perhaps this article which has been accepted will trigger people to realise what i'm on about. if you put multiple RISC cores into 28nm or below, they SCREAM along at such unbelievably fast speeds that pure economics dictates that it is insane to ignore them. LEON4 by gaisler.com can do up to 8 cores, each at 1.5ghz, in 30nm. the size of the chip is so small that you can fit i believe it's around 10,000 processors onto a single 12in wafer. each wafer is $10k each, meaning that each IC is $1 each. add $1 for plastic packaging; add $1.50 for running test vectors at the plant, and you have a grand total of $3.50 for the manufacturing cost of each CPU, in mass-volume. of course, you have to amortise the NREs which are somewhere in the insane range of $5 million, but if you sell 5 million processors, that's only $1 per processor!

      and so that's what... $5 or thereabouts... for an 8 core 1.5ghz processor, with 1.7DMIPS/Mhz performance (roughly the same as an ARM Cortex A9 or the MIPS 1074k). and, because it will be an "integrated" System-on-a-Chip, it will have on-board DDR2 or DDR3 RAM controller, HDMI, SATA-II, USB2, PCIe, Gigabit Ethernet - everything that is listed on the article presented by the OP - so you could have an unbelievably powerful Desktop or Server system, consuming only about 4 watts of power for the complete system, with 12ghz of processing power and 2gb of RAM costing only around $50 in parts.

      so i have to ask - at what point does the economics become so blatantly in favour of RISC cores that people simply realise it is truly "Game Over" for Microsoft? what's it really going to take? do we _have_ to get down to 22nm or below, where 1.5ghz becomes 2.5 to 3ghz, and 10,000 cores becomes 20,000 cores on a single 12in wafer, and the price for 20ghz of processing power is $3 per CPU? really - what am i missing? i just don't get it.

    26. Re:Good by Anonymous Coward · · Score: 0

      I'd like to see evidence for that "1.7DMIPS/Mhz performance", because usually when you look closely you find out that in real world usage the truth is closer to "0.17DMIPS/Mhz performance".
      Particularly since the numbers obviously don't include any cache beyond "joke" size. Caches tend to make out 50% of a chip size so you can't really save much by simplifying the control structures, doubly so when you need _more_ (instruction) cache because your instructions are coded inefficiently.

    27. Re:Good by Anonymous Coward · · Score: 0

      you realize it's "assembly" and not "assembler" right?

    28. Re:Good by DarkOx · · Score: 1

      I am not really sure what your point about itanium is exactly. We were discussing for the most part technical realities if RISC, CISC, and micro code. Itanium is first off still in production, in fact they just released new models, and second if its a failure it is so in the marking sense more so than the technical sense. The chip performs well.

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    29. Re:Good by turgid · · Score: 2

      Not that it matters at this point. VLIW, like in high-performance DSP's and certain niche processors, is the future.

      Yes, VLIW has been the future since the 1970s.

    30. Re:Good by Mike610544 · · Score: 1

      Not that anyone even uses assembly anymore...

      Assembly's used all the time for embedded systems.

      No compiler's going to generate code as compact as a good programmer. That can be important when there's only a handful of KB for firmware. Performance is less of an issue these days, but if you're clever you can still shave off a few cycles. I don't think we've quite reached the 'John Henry' point yet in terms of optimization.

      I even know a few weirdos who find it easier to write and/or read than C.

      --
      ... also, I can kill you with my brain.
    31. Re:Good by Anonymous Coward · · Score: 0

      Exposing uops directly sounds like a great idea until you realize that nothing would run on it, and you'd probably break compatibility with every major revision of the hardware. It's kind of like saying that compilers would be faster if we wrote programs in AST directly - maybe it's true, but nobody actually wants that.

    32. Re:Good by Tubal-Cain · · Score: 1

      ...the x87 stack...
      ...the x87 FPU...

      Are you being consistent with your typo, or am I missing something?

    33. Re:Good by AvitarX · · Score: 1

      It's about ignoring the old way, and using SSE.

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

      --
      Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
    34. Re:Good by Anonymous Coward · · Score: 0

      The ARM architecture abandoned true RISC some time ago. Look up "Thumb". In the end the RISC instructions took up too much space in memory and they introduced significantly more complex instruction sets to get footprint down.

      Still less complex than x86, but somewhat short of the original RISC concept.

    35. Re:Good by Anonymous Coward · · Score: 0

      x87 floating point is deprecated for 64 bit code. Use the SSE instead.

    36. Re:Good by Anonymous Coward · · Score: 0

      On Alpha, DEC did a profiling recompiler for NT, and due to the speed of the Alpha, that approach nearly worked, except for Compaq getting distracted by Itanium, and cancelling Alpha stuff just as it was picking up steam into Windows 2000.

      Perhaps Intel should introduce a new architecture called Estonium just to distract companies from using ARM in their products. The inhabitants of Baltic nations will appreciate the irony.

    37. Re:Good by dryeo · · Score: 1

      NT was designed from the ground up to be processor agnostic. I've even got a Byte Magazine around somewhere with a little news article about Microsoft first getting OS/2 NT V3 to boot up (to text mode).
      It was a MIPS processor IIRC. This was before it booted on X86 and even before they officially switched it to Windows.
      OS/2 was (and still is) tied to X86 and the PPC version had to have a new kernel, different device driver system as well as the last of the 16 bit API ported to 32 bit. Even the object format was ELF instead of OMF. Some of it was ported to X86 OS/2 like the GRADD video driver model.
      The problem for both was applications. OS/2 was ahead in that regard as IBM wrote an excellent JIT compiler to run DOS and WIN 3.1 in with I understand comparable speed to X86.

      --
      https://en.wikipedia.org/wiki/Inverted_totalitarianism
    38. Re:Good by RzUpAnmsCwrds · · Score: 2

      No it isn't. Way to lose the whole point, which is predictability of how many cycles an instruction takes.

      Predictability does not exist on any modern CPU because of a variety of factors, including caches, super-scalar execution, out of order execution, and branch prediction.

      On a load-store (which is the precise term for what most people call "RISC") architecture, roughly 1 in every 3 instructions is either a branch or a memory instruction. On a CPU with caches and branch prediction you cannot have predictable instruction latencies with memory instructions or branches because by definition caches and branch prediction are probabilistic techniques. If you miss the cache, there is a penalty depending on exactly which caches you miss. Then there's the fact that you throw in cache coherency on shared memory multiprocessor systems and the memory access times can now depend on what *other* cores are doing.

      Most people don't understand this because their idea of what a CPU is stops at something like the classic 5-stage RISC pipeline. But the reality is that we need caches, branch prediction, multi-issue, and (in most cases) out-of-order execution to have high-performance. Modern ARM processors (Cortex A9) have all of these features, and even older designs (Cortex A8) have at least multi-issue, branch prediction, and caches.

      The problem with VLIW is that it is based on outdated ideas on where the performance problem is. VLIW works great when you have super-intelligent compilers, minimal branching, and never wait for memory. In reality, with few exceptions (like loopy scientific code) you branch a lot and spend a significant fraction of your time waiting for memory (either further caches or main memory). The primary benefit of out-of-order execution is that it hides memory latency, which is something that you can't get with VLIW. It looks great from a throughput standpoint on paper (and, for certain code, it does very well) but in practice on general code it falls flat on its face because you simply cannot keep the pipeline full.

    39. Re:Good by lkcl · · Score: 1

      http://www.gaisler.com/cms/index.php?option=com_content&task=view&id=338&Itemid=231

      "The LEON4 pipeline uses 64-bit internal load/store data paths, with an AMBA AHB interface of either 64- or 128-bit. Branch prediction, 1-cycle load latency and a 32x32 multiplier results in a performance of 1.7 DMIPS/MHz, or 2.1 CoreMark/MHz."

      there's an excellent overview from 2009 of the LEON4 architecture, even if it's just the abstract of a paper, try googling this:

      Next Generation Multi-Purpose Microprocessor
        Abstract for Presentation at MPSA, 4th of November 2009

      hope that helps.

    40. Re:Good by lkcl · · Score: 1

      the main site also reports that you can either put up to 2mb of 2nd level cache down, to get high performance, or you can put zero cache down, to save power. the usual deal, basically.

    41. Re:Good by Locutus · · Score: 1

      But one must consider that these Microsoft partners will also be locking the hardware to Windows and therefore it'll be a closed platform. The x86 platform as it has existed resulted in many different OSs running on it and we can purchase bare bones white boxes and put the OS of our choice on them. I don't think that will play forward if/when we see OEMs doing ARM boxes for the next version of Windows.

      The last hope of an open RISC platform was back in the mid `90s when the PowerPC platforms were getting tossed around.That one failed when Apple backed out of the first design and it took 2-3 years for the next and they pulled the plug on that too. It would be nice to see another open hardware platform but I would not expect to see Microsoft allow it. They know darn well how much of a pain it's been that Linux runs on standard x86 boxes out of the box.

      LoB

      --
      "Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
    42. Re:Good by Locutus · · Score: 1

      The thing about PREP and CHRP was that they provided open firmware and were designed to run different operating systems. You know darn well that any ARM hardware that'll be designed to run Windows 8 will not support any of the open firmware currently in use. It could be a step closer to the end of cheap open hardware for Linux fans.

      LoB

      --
      "Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
    43. Re:Good by qbwiz · · Score: 1

      All x86_64 compilers ouput SSE, as x87 isn't supported in 64-bit mode.

      --
      Ewige Blumenkraft.
    44. Re:Good by RobertM1968 · · Score: 1

      NT was designed from the ground up to be processor agnostic. I've even got a Byte Magazine around somewhere with a little news article about Microsoft first getting OS/2 NT V3 to boot up (to text mode). It was a MIPS processor IIRC. This was before it booted on X86 and even before they officially switched it to Windows.

      NT was intended to be designed from the ground up to be processor agnostic. In actuality, it ended up being (by the time there was more than just a text mode NT) hardly such. Things changed a LOT by the time NT 4 came out.

      OS/2 was (and still is) tied to X86 and the PPC version had to have a new kernel, different device driver system as well as the last of the 16 bit API ported to 32 bit. Even the object format was ELF instead of OMF. Some of it was ported to X86 OS/2 like the GRADD video driver model.

      Any OS that I know of, NT included, needs a different "kernel" (abstraction layer) for different hardware. OS/2's kernel *IS* much of the abstraction layer. All one megabyte of it. Oh, sorry, I mean... no, that's what I meant... one megabyte. The rest, such as the BASE device drivers, of course need to be ported... they interact with the hardware. That's nothing new on any platform. The higher level drivers, on the other hand, were largely device independent.

      The problem for both was applications. OS/2 was ahead in that regard as IBM wrote an excellent JIT compiler to run DOS and WIN 3.1 in with I understand comparable speed to X86.

      For PPC? Really? I thought they simply used a VDM technology... you know, just like they did on OS/2 Intel. The JIT was, if memory serves, being played around with for certain OS/2 executables.

    45. Re:Good by mwvdlee · · Score: 1

      You realize that in practice both terms can be, and are, used interchangeably right?
      http://en.wikipedia.org/wiki/Assembly_language#Use_of_the_term
      Ofcourse, both are wrong. It should be "assemblino".

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
    46. Re:Good by mwvdlee · · Score: 1

      The problem with modern CPU's though, it that it takes a VERY good programmer to out-optimize a good compiler. The complexity of modern CPU architecture make it much, much harder to determine an ideal solution. Cycle counts and branch distance mean very little these days.

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
    47. Re:Good by Rockoon · · Score: 1

      x87 is fully supported by the hardware in x64 mode but a kernel and drivers may willfully not save the x87 state during exceptions, interrupts, and system calls.

      The route Microsoft finally settled on after the uproar over the rumors that x87 would be to disallow (verboten) any kernel/drivers/ring0 code from using the FPU, and because that code never trashes the FPU, they also dont need to save the FPU state. The original rumor brought a fear that the OS would also not save the FPU's state during a task switch, which would have made the FPU near impossible to use in x64 mode, but that is simply not the case.

      Some OS's may not save the state during a task switch, and on those OS's the FPU wouldnt be usable. I dont believe that any of the major OS's neglect to save the state in this case, meaning that the x87 is usable in user mode on all of them.

      --
      "His name was James Damore."
    48. Re:Good by Anonymous Coward · · Score: 0

      For the things you optimize, the compiler is usually 2-4x away from "ideal". You don't have to know details of the instruction set to do better.
      If you include SIMD instruction sets liek SSE or NEON the compiler is often easily 10x away from ideal. It's really not a particular effort to be better than that.

    49. Re:Good by Anonymous Coward · · Score: 0

      Wow, they even write "performence" on that web site...
      And all there is are those purely theoretical performance numbers that have no relation to real-world performance (particularly since it does not even say with which config, with or without cache? With on-chip RAM?). The SPECfp value is either way still below that of the original Athlon, and AMD was always quite bad with floating-point (and who knows what you get once you do sin/cos etc.).
      Based on SPARC v8 probably also means: no unaligned reads/writes and no SIMD, which is going to cost you dearly in some applications.
      Sounds about as reliable as NVidia's numbers, I'm quite sure by their marketing numbers they will easily beat that one in Watt/OP, though at least there the dirty little secret is well known.
      And oi, "branch prediction" means "static branch prediction". As in "no branch prediction" for anyone not in marketing.
      This thing just doesn't work as a general-purpose CPU.

    50. Re:Good by Rockoon · · Score: 1

      Originally the FPU was only implemented in hardware via installing a co-processor alongside the CPU. Thus, there was (for instance) the 80386 and if you wanted to add an FPU, the 80387 math co-processor. These days the instruction set is simply an extension, like SSE/etc, but is still called x87.

      --
      "His name was James Damore."
  3. Opportunities by Nerdfest · · Score: 2

    I'd actually prefer they didn't. Joke as you will, it's an excellent opportunity for Linux to make inroads to the more casual user. The last one (netbooks) didn't get much time before Microsoft jumped in with XP netbooks.

    1. Re:Opportunities by Anonymous Coward · · Score: 0

      genisi has a nice $200 arm laptop, well I think they do. I'll find out later today

    2. Re:Opportunities by Desler · · Score: 2

      Yeah, I also prefer they don't cater to the wants of their customers rather than the wants of the minuscule minority that are fighting some petty OS war.

    3. Re:Opportunities by braeldiil · · Score: 0

      Nice to see that even the Linux partisans know that the only way for Linux to have desktop success is to have no competition. Given a choice, almost no one would choose linux.

    4. Re:Opportunities by pmontra · · Score: 1

      Linux is already making inroads in casual users' phones (the Android kernel). Not that they know or care about it. As a Linux desktop user I'm fine with that and I'm just happy that about all the web applications I worked on in the last years are running on Debian servers or on Debian-derivatives.

      I just don't believe that casual users will ever massively switch to Linux. Maybe they'll start to use Chrome OS tablets but they won't know about them being Linux-inside, just like almost all iPhone and iPad users don't know that those devices are Unix-inside. We might end up living in a world dominated by Unix derivatives but only a few techies like us will know it.

    5. Re:Opportunities by Anonymous Coward · · Score: 0

      Yeah, I know, right? Linux has no chance of ever succeeding when faced with any competition at all. Oh, wait...

    6. Re:Opportunities by the+linux+geek · · Score: 1

      Android isn't really Linux. Linux is basically a bootloader for it. With minimal porting, you could run it on top of FreeBSD or Mach.

    7. Re:Opportunities by RobertM1968 · · Score: 1

      I'd actually prefer they didn't. Joke as you will, it's an excellent opportunity for Linux to make inroads to the more casual user. The last one (netbooks) didn't get much time before Microsoft jumped in with XP netbooks.

      If Microsoft's track record is a good indication, I would be happy if they DID go for it... can anyone count how many versions of Windows were targeted at tablets - and failed to get anywhere except niche markets like Home Depot's inventory carts? Heck, even skip the WinMo crap that was never suited for touchscreen.

      "Everyone" wants a tablet nowadays. Apple and the various OEMs that build on Android are doing a phenomenal job. A blunder like taking iOS and Android on in markets they were designed for would do nothing except push interest even further away from any Microsoft offering. No bashing there - just a fact. Something similar happened in the smartphone arena... too little, too late, after too many broken promises of innovation and (planned) leadership in the market.If enough OEMs take the dive, then if (when?) Microsoft fails in this market again, it'll mean a bunch of vendors will be refitting overpowered devices with Android or some other Linux based option, providing us with higher end tabs at cheaper prices.

    8. Re:Opportunities by Kjella · · Score: 1

      Nice to see that even the Linux partisans know that the only way for Linux to have desktop success is to have no competition. Given a choice, almost no one would choose linux.

      Migrate to Linux. To get people to switch to something - anything, it can't be "as good as". There has to be some specific reason to do it that you're not getting anywhere else, unless you're dealing with very idealistic/cost averse people. Running on ARM while Windows didn't could be one such thing. In fact I suspect will be one such thing, because most apps will only be x86 no matter what Microsoft does.

      Personally it was the pre-SP Vista that did it, I was like "fuck if this is the way forward I'd rather grit my teeth on Linux". I stuck with it for 3.5 years too, because even though it had many quirks I kinda got used to them. But in the end I migrated back to Win7 because Microsoft fixed things while Gnome/KDE didn't. And my Windows games are now just a click rather than a reboot away.

      --
      Live today, because you never know what tomorrow brings
    9. Re:Opportunities by Desler · · Score: 1

      Android is Linux when it benefits the people pushing market share numbers that are positive to Linux. When any negative news comes out about Android it no longer is Linux and people make sure to point out that Linux is just the kernel that Android uses.

    10. Re:Opportunities by Anonymous Coward · · Score: 0

      Android isn't really Linux.

      Bullshit. What api does Dalvik use? What manages memory on an Android device? What manages the hardware on an Android device? When I open a terminal on my Droid and start rtorrent or vi or python or sshd, what api do those applications use?

      Oh, and +0.1 troll points for your nick. I bet you fool a few people with it.

    11. Re:Opportunities by Anonymous Coward · · Score: 0

      Yeah, because every person that has an opinion on either of those things is in complete and perfect lockstep. Or maybe you just need a little more straw. I'll let you know.

    12. Re:Opportunities by cyber-vandal · · Score: 1

      Who is "everyone"? Not me or most of the people I know.

    13. Re:Opportunities by UnknowingFool · · Score: 2

      If Microsoft's track record is a good indication, I would be happy if they DID go for it... can anyone count how many versions of Windows were targeted at tablets - and failed to get anywhere except niche markets like Home Depot's inventory carts? Heck, even skip the WinMo crap that was never suited for touchscreen.

      Why MS failed at tablets was all they did was shove Windows into a different form factor. And then called it done. Now other than having a touchscreen and using a stylus instead of a mouse, Windows tablets were just very expensive laptops. In the many years MS pushed tablets, they only wrote one application that truly used touch. They however left the rest of the OS very keyboard/mouse centric. So for the average consumer, why would they buy an expensive touchscreen laptop that gave them no real advantage to buying a cheaper laptop?

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    14. Re:Opportunities by Anonymous Coward · · Score: 0

      You're a fucking retard. Everyone customizes the Linux kernel they put in their products... fuck there's a GUI that comes with the kernel to do just that.

    15. Re:Opportunities by LO0G · · Score: 1

      Actually until the iPhone came out, touch was considered uninteresting in consumer devices. All the tablets I've ever seen were designed around stylus input, not touch.

      When the iPhone came out it was a game changer in more ways than one - touch became the norm, capacitive screens instead of resistive ones, etc.

    16. Re:Opportunities by RobertM1968 · · Score: 1

      Who is "everyone"? Not me or most of the people I know.

      You didnt note the use of quotation marks in my post? Nor understand their meaning?

    17. Re:Opportunities by turgid · · Score: 1

      Android isn't really Linux. Linux is basically a bootloader for it.

      That's one mighty large, over-engineered bootloader!. Why didn't they just use uBoot?

    18. Re:Opportunities by RobertM1968 · · Score: 1

      Actually until the iPhone came out, touch was considered uninteresting in consumer devices. All the tablets I've ever seen were designed around stylus input, not touch.

      When the iPhone came out it was a game changer in more ways than one - touch became the norm, capacitive screens instead of resistive ones, etc.

      Nope, and I even mentioned such touch based usages. There's plenty more like POS systems. Efforts were made to hit the consumer market, but there were no apps suitable, regardless of whether a stylus or finger was the modus operandi.

    19. Re:Opportunities by pandrijeczko · · Score: 1

      Guess what - to a non-zealot Linux user, it matters not one iota how many other people are using it on the desktop.

      All that matters to me is that I've used it for years, it's getting better & better all of the time & long may that continue.

      --
      Gentoo Linux - another day, another USE flag.
    20. Re:Opportunities by jejones · · Score: 1

      No, it's more that Microsoft will move in and compel the OEMs to ditch Linux, as they did with netbooks.

    21. Re:Opportunities by drinkypoo · · Score: 1

      It's a load of dingo's kidneys. Linux is a kernel. Anyone who says different is selling something.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    22. Re:Opportunities by Sxooter · · Score: 1

      Add that Microsoft has a poor track record for building an architecture neutral OS, and fell back so easily to the X86 architecture back in the 90s. How many versions of windows will be available for the ARM or another architecture? win8, maybe 9? Then they drop support if there aren't enough users.

      This is one place where Open Source and Free software excel. As long as the users of that architecture are willing to pony up the talent, they are guaranteed the access they need to make it work. With Windows, if MS doesn't wanna support it, it won't be supported period. If a business decision at MS says that throwing ARM users under the bus makes economic sense, then they'll do it.

      --

      --- It is not the things we do which we regret the most, but the things which we don't do.
    23. Re:Opportunities by Robert+Zenz · · Score: 1

      I just don't believe that casual users will ever massively switch to Linux.

      They will, as soon as they need to pay for Windows and Microsoft Office.

    24. Re:Opportunities by cyber-vandal · · Score: 1

      I did however I couldn't see the relevance of them since the quotes would normally imply an exaggeration whereas your following sentences sort of contradicted that impression. But I sit corrected in any case.

    25. Re:Opportunities by RobertM1968 · · Score: 1

      I did however I couldn't see the relevance of them since the quotes would normally imply an exaggeration whereas your following sentences sort of contradicted that impression. But I sit corrected in any case.

      LoL, sorry for the lack of clarification. Yeah, it's far from everybody... but a few million tablets that people seem to enjoy also does show that Apple and various Android tablet manufacturers are doing a phenomenal job in a market that's previously been a failure (while still not being the "everybody" that some reviewers allude to). Sorry, that's a bit more in line with what I was trying to say. :-)

  4. ARM Windows by devent · · Score: 5, Insightful

    How are they going to explain to the million of Windows users that no application they know will work on ARM Windows? It's the same as with Windows 64 bit and why we didn't saw much of it despite the prices for RAM are very low. I guess with Windows 7 the developers finally released some software for 64 bit. That's what, like 9 to 10 years since AMD came with the amd64 architecture?

    Well, at least I can then finally buy some ARM notebooks and put a decent Linux distribution on it.

    --
    http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    1. Re:ARM Windows by The+O+Rly+Factor · · Score: 2

      How are they going to explain to the million of Windows users that no application they know will work on ARM Windows?

      Clever marketing that appeals to yuppies.

      "Don't be left behind with slow stupid x86 Microsoft Office, upgrade to the new better more powerful Microsoft ARM Office today. It's newer so you know its better, and come on it has the word "Arm" in it, which means powerful, duh!"

    2. Re:ARM Windows by Microlith · · Score: 1

      Well, at least I can then finally buy some ARM notebooks and put a decent Linux distribution on it.

      And I expect the market for ARM-based Windows 8 devices to be just as horrible as it is now, in terms of replacing the OS, as it is for tablets and phones. Lack of drivers, binary only video drivers, and lock down to prevent people from actually removing the OS.

      And here I was hoping that the transition to ARM would get us away from Microsoft's domination. Now it could very well be enforced in hardware.

    3. Re:ARM Windows by Anonymous Coward · · Score: 0

      Emulation still works.
      Most programs they will want to use that are popular, such as browsers, media players, stuff like that, they will be ported pretty quickly.
      The others won't need too much in terms of resources to run that emulation could be done without much overhead.

      The one huge problem will be games, of course.
      Yeah, i can't think of a way around that either.
      Some older games could be emulated, but the transition to ARM will be pretty painful for those who prefer working close to the metal.

    4. Re:ARM Windows by Bert64 · · Score: 2

      Windows 64bit is different, most 32bit applications run on it just fine and the 32bit consumer versions are crippled (ie wont support more than 4gb of address space, even tho the hardware is capable of it using PAE)...

      Windows on ARM won't run x86 applications natively, and if they provide an emulation option it will be almost certainly be extremely slow.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    5. Re:ARM Windows by UnknowingFool · · Score: 3, Interesting

      It's the same as with Windows 64 bit and why we didn't saw much of it despite the prices for RAM are very low. I guess with Windows 7 the developers finally released some software for 64 bit. That's what, like 9 to 10 years since AMD came with the amd64 architecture?

      The reason 64-bit wasn't was adopted quickly was more about need vs features. The model MS choose for their 64-bit migration (LLP) meant that 32-bit programs were backwards compatible. So there was no need for a consumer to get 64-bit Office because 32-bit Office would work fine in 64-bit Windows. If all the 32-bit programs worked either way on 64-bit or 32-bit OS, there wasn't as much as a push to migrate. Unfortunately 64-bit Windows would often times require new drivers. So there were more negatives moving to 64-bit on Windows unless the consumer had a specific need like more memory addressing. For the most part, businesses were more open to using 64-bit Windows Server as there was a need in many cases to access more than 3GB of RAM.

      Software companies that wanted to take advantage of 64-bit for Windows had to maintain separate 32-bit and 64-bit binary and source code versions during the migration. While the 32-bit version would work on either Windows flavor, the 64-bit would not work on a 32-bit OS. Many companies were reluctant to maintain two versions especially if moving to 64-bit provided no real advantage.

      The Linux/Unix/OS X model (LP) took a different approach as that model focused more on forward compatibility. A 32-bit program could be made into a 64-bit program with a recompile and testing to ensure there were no special scenarios that required 32-bit addresses, etc. Software companies would have to maintain two binary versions but for the most part could maintain one version of source code. With Linux/Unix/OS X, a great deal of software was open source so that it was far easier to make this migration.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    6. Re:ARM Windows by Anonymous Coward · · Score: 0

      The 1st version of 64-bit Windows that is attractive to corporations is Windows 7 SP1, which is only about a month old. Many companies wait until at least SP1 before upgrading to a major new version of Windows.

      I don't recall Windows XP 64-bit being marketed or bundled with new PC's like Windows 7. So that XP 64-bit was an experiment. And Vista? Heck...even the 32-bit version was, IMHO, beta quality so Vista is also ruled out as a viable 64-bit Windows OS.

      So that leaves us with Windows 7 64-bit as the first viable 64-bit version of Windows. Before SP1, about half of all Windows 7 sold/bundled were 64-bit. Starting this year, 32-bit version of Windows 7 will be in the minority for new systems. When the average PC ships with more than 4 GB RAM, 32-bit market share will start falling off a cliff instead of today's gradual decline.

    7. Re:ARM Windows by CreateWindowEx · · Score: 1

      It's actually easier to recompile existing 32-bit x86 for 32-bit ARM than for 64-bit x64, especially if Microsoft released an ARM backend for the visual C compiler. As long as Windows-for-ARM came out before too many applications transitioned to 64-bit only, it's easy to imagine it could succeed.
      If they're aiming at the tablet/netbook market, then the lack of hardware drivers won't be a problem, they just need to support the on-board hardware and a few key applications (IE, Office, Flash). Ironically, if Apple's AirPrint takes off, they won't even need printer drivers. if they were able to run .NET, that would give them a lot of compatibility for free, even in-house corporate apps.

    8. Re:ARM Windows by whizzter · · Score: 1

      Actually i think you can enable PAE with a bit of hacking.

      There are however a few big problems with PAE.

      1: Pages in memory are 4mb instead of 4kb, some programs make silly assumptions about it and that decreases compability.
      2: Ever more severe, many thirdparty drivers does the same. Thus PAE mode would induce a whole world of hurt in terms of compability and system crashes.
      3: Bloat.. since most programs has code, constant, stack and data areas that usually end up on separate pages every minor app will require something like 16meg of memory. Not a big problem for a server with lots of mem and few programs but worse in desktop settings.

      So.. when you go to PAE you could as well just jump to 64bit because of the driver and app issues and that will also be more efficient since it's really only the kernel that will consume more memory due to larger pointers.

      The apps are still 32bit for most parts but can be put into separate areas with virtual mappings on a small (4k) granularity that doesn't induce bloat.

    9. Re:ARM Windows by EvanED · · Score: 1

      I guess with Windows 7 the developers finally released some software for 64 bit. That's what, like 9 to 10 years since AMD came with the amd64 architecture?

      XP 64 got off to a bit of a bad start, but I havn't run anything but 64-bit Windows on my home system for years; that goes back to the pre-Win 7 era (I was running 64-bit Server 2008 for a year or so).

      And even the XP case is overstated, at least nowadays. Until fairly recently I was running 64-bit XP at work (I've switched to Linux); several other people in my group still are. It works fine.

    10. Re:ARM Windows by EvanED · · Score: 1

      Software companies that wanted to take advantage of 64-bit for Windows had to maintain separate 32-bit and 64-bit binary and source code versions during the migration. ... A 32-bit program could be made into a 64-bit program with a recompile and testing to ensure there were no special scenarios that required 32-bit addresses, etc. Software companies would have to maintain two binary versions but for the most part could maintain one version of source code.

      Uh what? I'm curious what characteristics of the Windows model meant that the similar "recompile" model wouldn't work on Windows. Because I don't know of any.

    11. Re:ARM Windows by EvanED · · Score: 1

      Uh what? I'm curious what characteristics of the Windows model meant that the similar "recompile" model wouldn't work on Windows. Because I don't know of any.

      Actually that's not quite true; I can think of at least one difference: if you use native C types and use a long to store a pointer value. With the typical Windows model, that would result in a truncation; with the typical Linux model, that would continue to work.

      That said, that code is latently broken anyway; in some sense it doesn't deserve to work in the first place. But that doesn't mean that the Windows crew has to maintain two source trees; that's ridiculous. What it means instead is that if you have an 'int' variant that you want to hold an address, you should use 'intptr_t' instead. Which is what the Linux software should be doing anyway.

    12. Re:ARM Windows by RyuuzakiTetsuya · · Score: 1

      By releasing prototype hardware to devs before going to launch so apps do exist for the platform?

      We are no longer in the paradigm of "will my apps run?" but "will there be an app that lets me do $task with $data?"

      --
      Non impediti ratione cogitationus.
    13. Re:ARM Windows by dave420 · · Score: 1

      You can enable PAE rather easily.

    14. Re:ARM Windows by UnknowingFool · · Score: 2

      Read about LLP vs LP. MS choose LLP which introduced a new 64-bit data type: long long (that's not a typo) and kept a 32-bit type: long. In terms of backwards compatibility, LLP means you don't have to recompile or do anything to have your 32-bit program still work. However you cannot simply recompile a 32-bit program to take advantage 64-bit; you actually had to change source code and compile. In some cases, it was going to be a simple find and replace; in other cases, it wasn't that easy. This means that going forward, you would have to maintain two different source code trees thus two binary versions.

      The LP model redefines "long" to be 64-bit. Unless there was some weird code that blew up if "long" went above 32-bit, all that would be required was a recompile. You would have to maintain two binary versions but you could maintain one version of source code.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    15. Re:ARM Windows by EvanED · · Score: 1

      See my reply to myself that I wrote almost immediately.

      I was off in some fantasy world where code was actually generally well-written and didn't make architecture-specific assumptions about the size of integers.

      That said, you still have a couple things wrong. First, LLP doesn't really "introduce" long long; that's been usable even in 32-bit software for ages. Second, while you do have to do some rewriting to get your code 64-bit clean if you aren't in my magical fantasy world, it's absolutely wrong to say you then need to maintain two source trees.

    16. Re:ARM Windows by Anonymous Coward · · Score: 0

      No. They will just run slowly in emulation mode.

    17. Re:ARM Windows by UnknowingFool · · Score: 1

      That said, that code is latently broken anyway; in some sense it doesn't deserve to work in the first place. But that doesn't mean that the Windows crew has to maintain two source trees; that's ridiculous. What it means instead is that if you have an 'int' variant that you want to hold an address, you should use 'intptr_t' instead. Which is what the Linux software should be doing anyway.

      Yes they could avoid the problem if everyone wrote in standard Ansi C99 but as you are no doubt aware, C varies when factoring compiler and hardware differences. Add to that software companies coding for Windows may not code in standard C but Microsoft C++ and in one of the MS programming platforms like .NET where they use MS data types instead of the low level "intptr t".

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    18. Re:ARM Windows by cyber-vandal · · Score: 1

      The lack of a 64 bit version of Office was probably an issue too. Although Office 2010 is now 64 bit none of the previous ones were.

    19. Re:ARM Windows by UnknowingFool · · Score: 1

      That said, you still have a couple things wrong. First, LLP doesn't really "introduce" long long; that's been usable even in 32-bit software for ages.

      Not according to unix.org. What you are talking about is the C99 standard which isn't about data models but a specific programming language specification. I don't have a definite history of LP64 vs LLP64 but the paper from unix.org suggests that it predates C99 by at least a year. Also as you no doubt aware, not every compiler follows the C99 standard fully. GCC supports it mostly. And some compilers use the older C89 standard. And if you are using Windows you are not using the C99 compiler, you are using the MS Visual C++ compiler which is not compliant.

      Second, while you do have to do some rewriting to get your code 64-bit clean if you aren't in my magical fantasy world, it's absolutely wrong to say you then need to maintain two source trees.

      If you want to develop and maintain your own 64-bit data structures and coding to ensure 32-bit OS handles them correctly, then no you don't need to maintain two source trees. However you would have to maintain those data structures forever instead of relying on MS data types. Or you could the very messy task of putting in #IFDEF everywhere to separate your 64-bit/32-bit parts if you wanted to use the MS data types but keep one version of source code. You could do all of that. Or you could maintain two versions. I would think it's far easier to maintain two versions.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    20. Re:ARM Windows by Anonymous Coward · · Score: 0

      I work for a company that maintains and sells 32 and 64 bit software for Windows, Linux, Mac OS and other platforms from common source, and has been for years. I really feel like you're overblowing the significance of LP vs. LLP - anybody seriously in the business of cross-platform development should have a clean enough code base, and mature enough development practices, where this isn't really an issue at all.

    21. Re:ARM Windows by EvanED · · Score: 1

      Not according to unix.org. What you are talking about is the C99 standard which isn't about data models but a specific programming language specification.

      'long long' was a common compiler extension well before C99. It was available by at least GCC 2.7.2.3, which was released Aug 1997. That's the earliest version I have access to without compiling stuff.

      And to some extent you're right about the disconnect about the data model and C language -- but at the same extent, IMO they're so tightly coupled in Unix that I also think it's reasonable to talk about what was going on in the world of C.

      However you would have to maintain those data structures forever instead of relying on MS data types. Or you could the very messy task of putting in #IFDEF everywhere to separate your 64-bit/32-bit parts if you wanted to use the MS data types but keep one version of source code. You could do all of that. Or you could maintain two versions. I would think it's far easier to maintain two versions.

      While I'll admit that I don't have a ton of experience with coding in "the Windows way" using all their DWORD and LPVOID jazz, and I don't know exactly what effect the 64-bit switch has on them, I'm still not really seeing the problem. C provides 'intptr_t' for an address-sized integer, and Windows provides ULONG_PTR and DWORD_PTR. All of these types behave like 'long' does under Linux: it's 32-bit when compiling for a 32-bit target and 64-bit when compiling for a 64-bit target.

    22. Re:ARM Windows by UnknowingFool · · Score: 1

      Not everyone who wrote a program for Windows considered 64-bit migration when they wrote their code. Nor would they need to consider it if their code never needed to take advantage of 64-bit data structures. If they wanted to take advantage of it, there was going to be a debate of the best approach going forward and how to support both 32-bit and 64-bit Windows. The effort wasn't exactly zero.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    23. Re:ARM Windows by Bert64 · · Score: 1

      You don't typically play games on a small low power netbook anyway...

      Linux already offers browsers and media players, but selling windows on arm will probably hurt their brand more than anything because users will buy it expecting it to be the same as x86 windows, and then be sorely disappointed...
      At least if they buy linux, they wont be expecting x86 compatibility and will use it for what it is.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    24. Re:ARM Windows by LO0G · · Score: 2

      The switch from 32bits to 64bits *is* going to break some set of applications. There's simply no way to avoid it.

      If you use the LP model, you're going to break every application that assumes that sizeof(int) == sizeof(long). Call this set IntEqualsLong.
      If you use the LLP model, you're going to break every application that assumes that sizeof(int) == sizeof(void *). Call this set IntEqualsPointer.

      The question is: Is the set of applications in IntEqualsLong greater than the set of applications in IntEqualsPointer?

      If you believe that IntEqualsLong is larger than IntEqualsPointer, you want to chose LLP (because it breaks fewer applications). If you believe that IntEqualsPointer is greater than IntEqualsLong, you chose LP.

      Apparently the Windows developers thought that IntEqualsLong was greater than IntEqualsPointer. The Linux developers chose differently.

    25. Re:ARM Windows by Kjella · · Score: 1

      It's the same as with Windows 64 bit and why we didn't saw much of it despite the prices for RAM are very low.

      That's because most people don't need it. Hell, you can buy a $2000-2500 top MacBook/iMac and it doesn't have more than 4 GB standard. Me, I got 16 GB and disabled swap entirely but I don't really need it. Not even under the craziest of workloads I put on it would I break the 10 GB barrier, and that includes one app that likes to chew 2-3 GB alone + one full VM. I just like having more than enough.

      --
      Live today, because you never know what tomorrow brings
    26. Re:ARM Windows by Anonymous Coward · · Score: 0

      Why would that be an issue? 32-bit Office worked on 64-bit machines.

      I'm not sure what great advantage 64-bit gives to Office, other than a tonne more cells for Excel (might be that Access gets a boost too).

    27. Re:ARM Windows by theweatherelectric · · Score: 1

      How are they going to explain to the million of Windows users that no application they know will work on ARM Windows?

      I think they'll do two things. First, Microsoft will advocate .NET development as the one true way to build applications compatible with both ARM and x86. Second, Microsoft will deploy an app store for Windows so ARM users can easily find applications that will run on their system.

    28. Re:ARM Windows by Anonymous Coward · · Score: 0

      How are they going to explain to the million of Windows users that no application they know will work on ARM Windows?

      The CIOs dealing with thousands of seats requiring little more than Microsoft's suite, few easily ported business applications and a browser will appreciate the decreasing electricity costs. Heavy numerical lifting can be done on the server farms containing anything from x86 to GPUs and mainframes in these days. The FPS games required by the Helpdesk, tech support and the engineering to do their jobs can be run from the servers as well. The gaming companies would probably like to sell some nice corporate licences, with logging, managerial controls and corporation wide leaderboards. Education and virtual meeting spaces follow naturally from these. I see its middle of the night here and that is why I didn't stay on topic..

    29. Re:ARM Windows by fyndor · · Score: 1

      .NET is their answer I would have to assume. Drivers and legacy win32 code (the software i write :X) I would think will not work, but .NET would of course work just fine, They could do what Apple did with Rosetta which they are actually just now phasing out when they release Lion. And there is always XP mode aka virtual machines. We actually have a developer at work that is already having to run all the development software under XP mode in Win 7 because of compatibility issues with one piece of software which causes everything to have to be in XP mode for him. Having to explain XP mode to beginner will be painful though. We have been always wondering at work when a Windows release will force us into having to rewrite on .NET, and I think Windows 8 will be it.

    30. Re:ARM Windows by Locutus · · Score: 1

      they have to do it with MS .NET or some other cross-Windows compatibility layer. How do they do that you might ask. They would do it with a Microsoft MarketPlace where you purchase and download your applications and it's all controlled by Microsoft. They do it by restricting how you install your applications so there is no expectation that a CD with ProgX for Windows XP, Vista, 7 can be installed because there's no CD slot.

      The tablet market is the perfect transition to a more controlled Microsoft Windows application market and more adoption of the MS .NET SDK. You won't see standard looking PCs running ARM and Windows, nor will you see laptops doing it. Windows 8 for ARM will be for Tablets and possibly phones and only if it has success will we see anything close to standard x86 PC hardware. IMO

      LoB

      --
      "Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
    31. Re:ARM Windows by mbkennel · · Score: 2

      The CIOs dealing with thousands of seats requiring little more than Microsoft's suite, few easily ported business applications and a browser will appreciate that no application that their Windows users want (except Office, and the small number of official applications) will work on ARM Windows.

      Lack of compatibility is a feature, not a bug.

      Now they don't have to justify "why don't you let me install my XYZ" any more.

      They just say "OK go ahead and try it" to their lusers, knowing that it won't work.

      Those people with "mission critical legacy apps", well, they don't get new computers. Ever.

    32. Re:ARM Windows by mvdwege · · Score: 1

      Actually, I just did an Office upgrade (and re-fired my hatred for Microsoft), and MS still says that you should install 32-bit Office, even on 64-bit systems.

      So no, Office is still effectively 32-bit only.

      Mart

      --
      "I know I will be modded down for this": where's the option '-1, Asking for it'?
    33. Re:ARM Windows by Anonymous Coward · · Score: 0

      Lack of compatibility is a feature, not a bug.

      This sentence will be pronounced with a resounding chest voice by the CSO during an executive board meeting. "Security through incompatibility is our new motto, and everyone who don't get our motto will be mottoed!"

    34. Re:ARM Windows by Agripa · · Score: 1

      There are however a few big problems with PAE.

      1: Pages in memory are 4mb instead of 4kb, some programs make silly assumptions about it and that decreases compability.

      This can't be right.

      PAE mode is enabled by default anyway to take advantage of DEP. The limitation for the consumer versions of windows is in using more than the first 4GB of physical address space.

      PAE mode still uses 4kb pages by default:

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

      Not that Windows XP without any service packs can address more than 4GBs when in PAE mode.

    35. Re:ARM Windows by Bert64 · · Score: 1

      And as that very page says...

      PAE is enabled by default if your using DEP, which vista and xp/sp2 will by default (so much for compatibility problems)...

      There is still an artificial limit depending on what windows version your using, so 32bit desktop variants are intentionally crippled to not support more than 4gb, trying to force you to buy the more expensive versions...

      I utterly detest arbitrary limitations like this, they must have made extra effort to implement such restrictions... Linux with PAE support enabled has no such restrictions, and will happily use as much memory as the hardware can physically support.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    36. Re:ARM Windows by cyber-vandal · · Score: 1

      So there was no need for a consumer to get 64-bit Office because 32-bit Office would work fine in 64-bit Windows.

      No version of Office before 2010 was 64 bit was my point *sigh*

  5. Duh by c · · Score: 1

    Stupid question.

    Of course any system builder will tell you they'd "consider" ARM for Windows 8. They'd also "consider" building 9.6GHz 8088 systems running MS-DOS powered by the blood of virgins if that's where it looked like the market might go.

    --
    Log in or piss off.
    1. Re:Duh by RobertM1968 · · Score: 1

      Stupid question.

      They'd also "consider" building 9.6GHz 8088 systems running MS-DOS powered by the blood of virgins if that's where it looked like the market might go.

      Is there a website I can pre-order on?

    2. Re:Duh by c · · Score: 1

      > Is there a website I can pre-order on?

      No, but if you send me your credit card information I'll see if I can get you on the beta list...

      --
      Log in or piss off.
  6. Humongous Dud by Anonymous Coward · · Score: 0

    Windows for ARM is going to be a humongous dud. The whole point of using Windows is backwards compatibility. Microsoft would have to use dynamic translation techniques similar to those used by Apple in the move from 68k to PowerPC to x86/x64, but ARM cores aren't faster than the Intel chips they're replacing and any power consumption advantage that ARM may have would be more than eliminated.

    On the plus side, if manufacturers actually fall for it (as opposed to just using it as a bluff to put pressure on Intel), then we'll see more devices on which we can put Linux. I love my ARM based servers.

    1. Re:Humongous Dud by EvanED · · Score: 1

      You make a lot of assumptions here, and I don't think that they necessarily pan out in practice.

      The whole point of using Windows is backwards compatibility.

      That's part of it, but it's not the whole story. For instance, I use Windows on my home box partially because I'm one of those strange people who actually like it. (Actually that's not quite true; in reality, I tend to like Linux and Windows about the same, and I dislike both. But the important thing is that Linux and Windows annoy me in different ways, and I use Linux at work, so by running Windows at home I get some variety in my frustration instead of it always being focused on one thing.)

      Now I do have some Windows-only software that I use (a couple games and Adobe Lightroom), but 90% of the time I've just got stuff that has easy cross-platform replacements.

      Which brings me to my next point:

      Microsoft would have to use dynamic translation techniques ... and any power consumption advantage that ARM may have would be more than eliminated.

      But what if they only have to use those dynamic translation techniques 5% or 10% of the time? There are a lot of people whose use probably falls under that: most of the time they're using software they could get ARM versions of easily enough, or change to a slightly different program if they couldn't, and then once every few days they'd use a program that would need binary translation.

      Now, does that apply to everyone? No. But I think it would apply to most people. (Look at how many people have switched to doing a lot of stuff on their iPhones and iPads.) The bigger question is how savvy you'd need to be to pick up the fact that you should and could get a new version of the software. (And here again I think it'd be reasonably easy to do that.)

      Finally, who says that ARM needs to be confined to systems where battery life is important? I'm waiting with somewhat baited breath for more information about nVidia's Project Devner. Those are chips meant for desktops and servers. Will they be good enough to pick over whatever Intel and AMD have out at the time? I dunno... quite possibly not. But they may well be. And that would be very exciting.

  7. Well ... by Anonymous Coward · · Score: 0

    I just hope it won't be as bad as the current netbooks with Windows 7 Starter.
    Had to deal with those as part of a software quality assurance project and if I never have to deal with crap like that again it'll be still too soon.

  8. What kind of devices? by gmuslera · · Score: 1

    Windows won't have an interface meant for i.e. tablets till late next year. If they want an OS for a full range of devices they should go in a way or another Linux, be Android, WebOS, MeeGo, or even normal distributions like Ubuntu with the right desktop environment. Even Maemo would be a better alternative if hadnt so much closed components. Not sure which other alternatives are around, iOS? Playbook's OS? Apple/RIM won't license to others their OSs, they want to sell the devices and keep the ecosystem for themselves.

  9. Doesnt make sense. by Anonymous Coward · · Score: 0

    THe whole article simply doesn't make sense.

    Manufacturers manufacture hardware, it's up to users to decide what OS it will be on(or decline sales figures if such choice is not there). M$ made decision to have their future OS's to be compatible with ARM. Now what? Manufacturers will be on purpose create devices that are not Windows compatible?

    Quality, as per flame wars in here - has nothing to do with OS being supported or not by hardware vendors.

    1. Re:Doesnt make sense. by UnknowingFool · · Score: 1

      Manufacturers manufacture hardware, it's up to users to decide what OS it will be on(or decline sales figures if such choice is not there). M$ made decision to have their future OS's to be compatible with ARM. Now what? Manufacturers will be on purpose create devices that are not Windows compatible?

      For the most part, consumers don't care what OS they use. They just want their devices to work. Manufacturers may not care about developing software for their hardware, but they care whether their product has software. The lack of software would mean far fewer sales to consumers. In the past if Asus wanted to make an ARM based laptop, they had fewer choices on the OS and thus the software. Asus could either use Linux or BSD or come up with their own OS. And how many software makers would write software for their laptop? So Asus would have to develop some of their own software just to make it usable to consumers. As you would no doubt agree that Asus doesn't want to develop software at all. They would rather install an OS like ARM based Windows and have MS worry about the software side of things. All of this was before Android which has provided hardware makers with another choice.

      So for a hardware maker, they either have to develop an ecosystem for their ARM based hardware or simply not make the device. With Apple and RIM they have gone to the trouble of developing the entire ecosystem. Such a task is not easy nor without risk. For the most part, Apple has succeeded by slowing building their ecosystem over several years. Why Android represents a larger threat than Apple to MS is that Apple is competing with MS for consumer usage indirectly; Android competes with MS directly for OEM partnerships.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
  10. Editors, please, don't allow publish such articles by Pecisk · · Score: 1

    What's aim of this article? What's reasoning to begin with? Right, ARM is next hot cake, and Microsoft have no presence whatsoever on this platform. Therefore it must fall back to PR companies which tries to push articles like "Waiting for Windows 8", "ARM will be supported in Windows 8", "Hey, did you know Windows 8 is next best thing?" on portals like Slashdot.

    Of course manufacturers will try to support any major operational system in the market - that includes Windows - if suddenly full blown Windows on ARM becomes reality. So this is worth separate article on Slashdot?

    --
    user@ubuntubox:~$ stfu This server is going down for shutdown NOW!
  11. Not gonna happen by JamesP · · Score: 0

    MS needed to have wakened up some 10 years ago.

    Do they have a Windows version running on HW other than x86? Apart from XBOX 360, of course not

    They used to have, but they believed their own crap about Wintel blah blah blah

    Granted, they did a version for Itanic

    But MS are the ones who where ultra-sluggish with AMD64

    Apple had something like 3 versions of OS X on x86 before switching to Intel

    And then people will buy and complain their 5 year old program doesn't work anymore.

    --
    how long until /. fixes commenting on Chrome?
    1. Re:Not gonna happen by the+linux+geek · · Score: 1

      Every version of Windows since NT 3.1 has run on architectures other than x86. 3.1 ran on MIPS, Alpha, and x86. 3.5 added PPC. 2000 killed those except Alpha (which was internal-only) and added IA64. XP added AMD64. Win8 is killing IA64 and adding ARM.

    2. Re:Not gonna happen by Anonymous Coward · · Score: 0

      The problem is, the applications didnt. What good is Windows if none of the applications wont work, nor inhouse built or the ones on the market?

    3. Re:Not gonna happen by the+linux+geek · · Score: 1

      Alpha and IA64 both had compatibility modes. IIRC PPC did as well - I don't remember, not having used it, but I've spent a lot of time with Windows on IA64 and its software compatibility is both very good and very fast.

    4. Re:Not gonna happen by JamesP · · Score: 1

      I'm not sure how it was on IA64, I guess it was a virtual machine kind of thing, but I remember people not being that happy

      (guess what http://news.cnet.com/Intel-scraps-once-crucial-Itanium-feature/2100-1006_3-6028817.html)

      --
      how long until /. fixes commenting on Chrome?
    5. Re:Not gonna happen by the+linux+geek · · Score: 1

      That's obsolete. As soon as the Itanium 2 came out (~2003) the processor itself was fast enough to get reasonable performance in software mode, through a subsystem called IA-32 EL. The hardware decoder got scrapped since at that point it was useless.

      On Windows, that subsystem was totally transparent. Running a Win32 x86 binary on IA64 would happen just like running one on any other Windows system, with no special steps.

  12. MS Windows supported RISC 15 years ago ... by perpenso · · Score: 2

    OK, finally we are moving away from x86 and toward RISC. We are only 20 years behind schedule, but hey, better late than never.

    MS Windows NT 4 supported RISC 15 years ago in 1996(*), Dec Alpha, IBM/Motorola PowerPC and MIPS. All on the standard Win NT 4 retail CD. Consumer oriented PowerPC machines were available. I recall Byte magazine comparing dual PowerPC and dual x86 systems. Alpha machines were available for the more serious users. Despite better computational performance on the RISC based machines x86 won due to price and software availability. ARM could fail as well. ARM may have better battery performance but is it so much better that it will outweigh the software availability issue?

    Also as other have pointed out the x86 has a RISC core. x86 instructions are converted to RISC instruction on-the-fly, scheduled and executed. The "problem" is that we do not have direct access to this core and must go through the x86 facade.

    (*) OK you can argue 1993, day 1 for Win NT, since MIPS was supported. However I don't think there was any real push towards a consumer MIPS machine. The motivation was more internal, making sure Win NT was portable to other architectures.

    1. Re:MS Windows supported RISC 15 years ago ... by the+linux+geek · · Score: 2

      Actually, MIcrosoft pushed for a MIPS reference architecture (ARCS) to be the successor to the PC architecture. They had some substantial support onboard, but it ended up breaking up due to DEC and a couple of other manufacturers pushing for Alpha to be the processor to be used, and then Compaq leaving and returning support to PC-compatibles.

    2. Re:MS Windows supported RISC 15 years ago ... by DarkOx · · Score: 2

      The software issue might not be as big this time a round. Netbooks aside, ARM is driving today's tablets, cellphones, and embedded devices. That seems to be where computing is going in general. It simply won't make sense to bring most of the existing PC software into that world. The software that does make sense to go there is cross platform already. Hell I am running ArmedSlack on my GuruPlug and its package for package almost exactly the same as the x86 Slackware versions.

      So people are really not going to be looking to move as many legacy apps over in the first place, frew applications people are really using will prove to be prohibitively difficult to port. Its not 1985 any more and we are not worried about running our DOS apps much, few applications written in the past 10 to 15 years have blobs of assembly sprinkled in and probably fewer make assumptions about PC hardware.

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    3. Re:MS Windows supported RISC 15 years ago ... by Anonymous Coward · · Score: 0

      The supposed origin of the "NT" in Windows NT was from NTen, Intel's codename for their i860 RISC processor. NT was first supposed to be written for the i860, but when machines weren't forthcoming it was developed on MIPS instead. It was only later that it was ported to i386 and a Windows layer written for it.

      dom

    4. Re:MS Windows supported RISC 15 years ago ... by mwvdlee · · Score: 1

      I remember maintaining DEC Alpha machines back in those days.
      A good Alpha ran Photoshop emulated (I think the emulator was called "FX86!") on a native WinNT. And it ran emulated Photoshop faster than native on the best Intel CPU as the time. The performance reign only held for about a year though, at which point Alpha became pretty much a lost cause.
      Too bad, I've always enjoyed the DEC machines; they were engineered so much better than the other major brands.

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
  13. Hope the taiwanese got a big warehouse by SmallFurryCreature · · Score: 1

    MS has in the past had its problems with delivering on time and companies have gotten burned if they planned a release of a product to need a unreleased MS product while MS was dragging its feet. Early Win95 games come to mind. There was a reason Quake was a DOS game. Blue Isle took a hit on making their next Battle Isle game require Win95.

    I would be very hesistant to plan hardware yet on a completely unproven platform from a company that has never ever cared a tiny bit about its customers. See MS and the long long delay with 64 bit support until Intel and Dell were ready basically screwing AMD out of its lead advantage.

    Just be careful taiwan, you don't want to end up with a stack of hardware getting outdated while MS delays the release month after month.

    --

    MMO Quests are like orgasms:

    You may solo them, I prefer them in a group.

    1. Re:Hope the taiwanese got a big warehouse by fuzzyfuzzyfungus · · Score: 1

      I strongly suspect that(in addition to the usual "people will tell annoying pollsters whatever they want to hear" effect), the OEM/ODM guys are not going to be taking any major risks on this one:

      There is already a reasonably steady market for ARM-based android widgets, NAS devices, etc, etc. Microsoft will, presumably, have their own set of special requirements(as with tablet PCs needing a ctrl+alt+del key) and some sort of minimum spec floor; but the basic nature of the ARM SoC market means that they won't really have an option other than choosing one or more, likely the higher specced ones, as blessed platforms. At that point, producing a "Windows 8" variant will likely require nothing much more than a button layout and bootloader change...

  14. Economics rule this out. ARM/MIPS Laptops... by lkcl · · Score: 1

    he issue that you've got is that a) microsoft is not going to have windows for ARM until 2013, and even then it is impossible to get third party developers to do total rewrites of drivers b) emulation of x86, even with hardware assistance (similar to jazelle) only provides something like 30% equivalent performance. so you have a great processor, maybe 2ghz dual-core if you get the one from nufront, you smash its capabilities down to a staggering and mundane 700mhz, and you can only get up to about 1.5 gb of RAM because you need at least some memory for the Host OS.

    now, yes you could instead use the ICT's "Godson" upcoming GS464V Quad-Core MIPS processor, which will have over 200+ hardware-accelerated assistance emulation instructions, but this CPU is designed to target the Chinese Government's desire to have the fastest supercomputer in the world - it would just also so happen to make a great Desktop / Server product, too, and the target power consumption is just a tad higher than any ARM processor.

    overall, then, this is, very unfortunately, just pure wishful thinking on the part of every single taiwanese manufacturer. it's quite simple: to emulate another OS, the performance hit is so high that to compensate you might as well stick with the x86 processors, even if the higher performance ARM or MIPS processors were available they are actually significantly more expensive.

    so instead, why not accept the fact that much much cheaper systems can be made, based around such low-power high-integrated embedded ARM and MIPS processors, and let the buyers decide?

    http://lkcl.net/laptop.html

  15. WinCE + by nurb432 · · Score: 1

    Dont forget the embedded devices running windows too.

    --
    ---- Booth was a patriot ----
  16. logo? by gbjbaanb · · Score: 1

    If this is a ARM story, why is the logo set to AMDs? they haven't bought them out yet have they?

    1. Re:logo? by lizardb0y · · Score: 1

      I was about to ask the same question. I guess the word ARM wasn't quite exciting enough ;)

  17. Re:Economics rule this out. ARM/MIPS Laptops... by fuzzyfuzzyfungus · · Score: 1

    Unless MS is playing their classic "attempt to scuttle competitor's existing product with reports of what they will have Real Soon Now(tm)" game, or isn't going about this very cleverly(either is definitely possible); I would expect any push into non-x86 architecture to make heavy use of their .NET CLR stuff.

    Virtualizing any classic win32 x86 binaries on ARM is going to suck so much, in terms of performance, that they might as well not bother. By the time Windows 8 actually makes it out the door, Intel will have something that may not beat ARM in the low-power game; but will curb-stomp ARM-emulating-x86. However, if Microsoft has an ARM CLR up and going, all the outfits that have been drinking the kool-aid for the past few years should need to do little more than drop their x86 installer packages in order to be fully compatible(and even if some x86 installshield package needs to be emulated long enough for it to copy over the .NET components, that won't be the end of the world)...

  18. Is ARM the new ACE? by erice · · Score: 1

    (*) OK you can argue 1993, day 1 for Win NT, since MIPS was supported. However I don't think there was any real push towards a consumer MIPS machine. The motivation was more internal, making sure Win NT was portable to other architectures.

    On the contrary, there was a major push by the ACE consortium to replace the x86 PC with a common platform built around MIPS and Windows NT. Unfortunately, it was mostly industry hype with very little product appearing in the retail channel before the whole thing was discarded.

    1. Re:Is ARM the new ACE? by gl4ss · · Score: 1

      arm is the new 68k. no, seriously, it is.

      also, amiga is dead. one thing that binds arm platforms so far is that binary compatibility is out the window every 2 years - minimum.

      the only stuff that can still be run with a phone bought from the shop today that I compiled 7 years ago is just the java stuff.

      I don't see my high cpu needing tasks switching to arm anytime soon.

      --
      world was created 5 seconds before this post as it is.
  19. ARM Windows but not on desktop PC by erice · · Score: 1

    I don't think desktop machines will move, or at least not move easily. However, unlike 1993, desktop machines aren't quite the PC universe anymore. On the top, we have legions of rack mounted servers. Coming up from the bottom are smart phones and tablets. Neither of these segments is as tightly wedded to Windows as the desktop. Tablets today already run ARM and don't run Windows. For Microsoft, this must be very disturbing.

    With servers, the move hasn't happened yet but data centers are seriously looking at ARM. Microsoft is trying to make sure their OS and application don't get dumped along with the power hunger x86 servers they run on.

  20. Re:Economics rule this out. ARM/MIPS Laptops... by lkcl · · Score: 1

    i did hear that ARM has a jazelle-like acceleration for CLR. it is not well-understood, and, crucially as you point out, there isn't much call for it because you can't run silverlight on a non-existent OS! :)

  21. Two differences are the net and the .NET by tepples · · Score: 1

    One difference between Windows NT 4 and Windows 8 is that the latter has the .NET Framework. Once Microsoft ports the CLR and the UI toolkit, all fully managed applications are automatically ported. This includes any Silverlight application and any XNA game.

    Another difference is that since the NT 4 days, home Internet access has become ubiquitous, mobile Internet access has become practical even if at a luxury price, efficient techniques for interpreting dynamic languages such as JavaScript have become known, and even APIs to let a web application run with an intermittent connection have been introduced. Web applications have begun to take advantage of these.

    1. Re:Two differences are the net and the .NET by JamesP · · Score: 1

      Yes, but

      is Office 100% .NET? Most likely not
      MS Live Messenger?

      (apart from that IE should be easier to convert, I guess)

      At least MS has some experiences with ARM tools.

      --
      how long until /. fixes commenting on Chrome?
  22. Article incorrectly tagged with the AMD logo? by Anonymous Coward · · Score: 0

    I see the article is tagged 'amd' and also carries the AMD logo. Please fix this.

  23. ARM Windows 8 isn't about products .. by Anonymous Coward · · Score: 0

    It is about control of the OEMs.

    Microsoft OEMs live or die via the 'loyalty discounts' given to them by MS. As long as the OEM only installs Windows on a particular model of a computer then the OEM will receive discounts and promotional incentives. If they do not then they will lose _all_ discounts over all products and this will cost millions of dollars.

    With Netbooks the OEMs thought that Vista could not run on them so their business was safe with Linux. But MS reintroduced XP that could run on these and the OEM had to use it or lose discounts on all the desktop systems.

    With ARM tablets, desktops and other, Windows 8 will run (granted there will be few applications for it) and so the OEM will have to install this or lose his x86 computer discounts.

    Essentially this will kill this part of the business. You may be able to buy an ARM tablet from the OEM, but it will have a useless Windows 8 installed and the price will include the Microsoft tax. You could put Linux on it and MS won't care, they still have your money.

  24. never ever cared a tiny bit about its customers by Anonymous Coward · · Score: 0

    > never ever cared a tiny bit about its customers

    Microsoft's customers are the OEMS: Dell, HP, Lenove, etc and retailers.

    You may a customer of one of the OEM.

  25. Meh, what did they expect? by Anonymous Coward · · Score: 0

    Windows makes ARM compatible version, hardware vendors plan on building hardware that will run it. What is the story? Unless ARM gets much more powerful fast, it would likely not make a great desktop or even laptop solution (similar to netbooks), but for certain niche places it would work well. It would probably make a nice file server, but these lower power applications are exactly the places I'd rather run linux.

  26. Microsoft will obviously recompile its own apps by tepples · · Score: 1

    is Office 100% .NET?

    No, but that's not a deal killer. Microsoft Office or any other Microsoft application can and most likely will be recompiled for ARM, though the recompiled version won't work with third-party add-ons written in native code.

    MS Live Messenger?

    As far as I know, Windows Live Messenger has already been recompiled for both ARM (Windows Phone 7) and PowerPC (Xbox 360).

  27. Obvious OEM is obvious by billcopc · · Score: 1

    And since when do Taiwanese OEMs have the slightest clue about anything besides cost-cutting ? Yeah, duh, they'll jump on ARM because it'll be loads cheaper than Intel/AMD/Via, so instead of charging a 5x premium to box it and ship it overseas, they will charge a 10x premium.

    That's like asking: if you could bottle tap water and sell it to cretinous americans for $3.00 a litre, would you ?

    --
    -Billco, Fnarg.com
    1. Re:Obvious OEM is obvious by gl4ss · · Score: 1

      one thing: the taiwanese oems don't decide what they assemble together and if it's arm or x86 doesn't matter - and they don't write the sw to run on them either. they're just assembly houses for most parts. and the oems such as display unit manufacturers, they will produce what is ordered from them and there is little relevance there if it's a windows, linux or ios device the screen ends up in.

      --
      world was created 5 seconds before this post as it is.
    2. Re:Obvious OEM is obvious by billcopc · · Score: 1

      Then how that does explain Asus, Acer, and all the other brands that dominate computer shops ?

      --
      -Billco, Fnarg.com
  28. And people say.... by Arador+Aristata · · Score: 1

    ...that running Windows 8 won't cost and ARM and a leg....

  29. Wait for Microsoft, then make the hardware by inglorion_on_the_net · · Score: 1

    What I find curious is that releasing ARM-based hardware is somehow tied to Windows 8 supporting it. What happened to the ARM-based netbooks we have been hearing about? Linux supports ARM just fine, and a lot of netbooks are sold with Linux anyway, so why aren't we seeing more ARM-based netbooks? Are the netbook manufacturers waiting for Windows 8, too? What gives? And how about servers? Do we have to wait for Windows 8 before we can save energy by running Linux/*BSD/... on ARM-based servers?

    --
    Please correct me if I got my facts wrong.