37 ms·

Windows 8 to support ARM, System on a chip, architectures

81 points by ajg1977 16y ago

runjake 16y ago
Interesting that Microsoft's answer to "Why?" seems to be "Because we can." by journalists. Hopefully they have a better strategy than that. That said, I'm all for more ARM support in the world. It looks like it will run .NET apps with little or no reworking. They probably borrowed a lot of the work of the .NET Compact Framework team for a reverse port. Expect native SDKs later, after the initial launch.
- rbanffy 16y ago
  I hope they can modulate Windows 8 OEM licensing price in order to convince some OEM to launch an 8 GB of RAM, SATA SSD ARM-based netbook with a x86-sized battery that gives it 48 hours of operation on a single charge. Then I can install a decent OS on the machine and be happy. Unfortunately, I'll have to live with an unsupported hardware. I have no illusion this fad won't be a short-lived one.
  - runjake 16y ago
    Can the current ARM implementations even utilize 8GB of RAM at this point? I recall some OMAP issues with even 512 MB not too long ago.
    - wmf 16y ago
      Regular ARM should support 4 GB and LPAE supports terabytes (although each app is limited to 4 GB). Current SoCs probably have much smaller limits, like 1 GB. Nvidia's core may be 64-bit, though, which would eliminate these restrictions.
    - timthorn 16y ago
      The Nvidia part at least will be based on the A15 processor, which includes Large Physical Address Extensions to allow up to 1TB memory.
  - kenjackson 16y ago
    I think this no fad, and I think Intel must've seriously screwed up. Everyone knew that Intel was promising MS, "we're going to match ARM on performance per watt in the coming years". That roadmap must have disintegrated, as MS would not have come public otherwise. The batteries will be a little smaller, to reduce weight, but 24 hours of operation on a single charge... that might becomes the standard.
    - rbanffy 16y ago
      In order for Windows on RISC to succeed, Microsoft and all 3rd parties will have to leave the x86 comfort zone and really support it. Last time MS tried to be multi-architecture, they failed miserably. They couldn't even be bothered to port Office to non-x86 machines. And nobody buys a PC to run only Windows and Office. They'll have to do a whole lot more than they did and I don't think they would be capable of.
      - kenjackson 16y ago
        The x86 comfort zone is always by your side. With virtualization (and app virtualization) you can run x86 apps seamlessly. Fortunately Office apps aren't CPU bound. Right, this has always been the play on virtualization for the OS. Don't get stuck in legacy mode, virtualize, and move on. MS may finally be doing what everyone said they should do.
        wmf 16y ago
        With virtualization (and app virtualization) you can run x86 apps seamlessly. Not on ARM. Emulation is possible but will be really slow.
        kenjackson 16y ago
        How slow? I did some quick profiling of Word and Excel doing basic stuff (text entries, making charts, but no hardcore calculations). Avg CPU utilization: 1%. Peak CPU utilization: 4%. A factor of 10x slowdown would probably be reasonable. Is the current state of the art on ARM able to get it below 10x?
- wtracy 16y ago
  MS has learned from their experience with Windows on Alpha. Even when they released XP for x86-64, they initially wouldn't sell it at retail for fear that people would get confused and buy the wrong one. I'm betting they have some compatibility magic cooked up that we haven't seen yet. Emulation has already been suggested. How about the possibility of having a launch hook that recompiles x86 machine code to ARM machine code? MS is on the short list of companies with the necessary resources to pull that sort of trick.
  - mishmash 16y ago
    Although IBM seems to own them now, it could be the same Rosetta technology that Mac OS X used. The parent company had many public licensees and MS could have been one, but not announced. http://en.wikipedia.org/wiki/Rosetta_(software) http://en.wikipedia.org/wiki/QuickTransit edit: formatting
  - runjake 16y ago
    Their "magic" is .NET and MSIL.They explicitly stated they aren't virtualizing or emulating x86 code during the session.
    - contextfree 16y ago
      The real magic is probably the Windows app store and new app packaging format that are also expected to be introduced with Windows 8. I'd imagine apps will be required to support both ARM and x86.
    - brudgers 16y ago
      Right. They have ten years of .NET penetration into the corporate world, the web, and 3rd party application developers - plus four years of .NET integration right into their operating systems. It is running on everything from embedded systems, to phones, to desktops, to clusters. Throw in that all the hardware vendors who are interested in "the Next Windows" and Microsoft has just laid out a roadmap for the next ten years.
    - Niten 16y ago
dmethvin 16y ago
If this is true, then Windows 8 is not a true successor to Windows 7. Current desktop/server apps assume binary compatibility with x86. This sounds much more like a scaled-up version of Windows Phone.
- bonzoesc 16y ago
  That's a crazy thing to say. The UI, the APIs, etc. will all be based on Windows 7, and any all-CLR apps should run without change. On Windows 8 running on x86, current apps (and Windows 3.1 apps, and maybe DOS apps?) will undoubtedly still run. It's just like the Mac Intel transition, but without an emulator to fill in the gaps.
  - kijinbear 16y ago
    Who knows? MS might be obsessed enough with backwards compatibility to pack an emulator in there, like they did with WOW64 (though it would be more difficult to write an x86 emulator for ARM).
    - rbanffy 16y ago
      > it would be more difficult to write an x86 emulator for ARM Building an x86 emulator is easy. Building one that can run Windows 8 software at speeds comparable to then current Intel or AMD x86 processors will probably be impossible. There is no such performance gap between ARM and x86.
      - TeHCrAzY 16y ago
        Would the opposite be easier? It might make sense to offer comparability for Windows|ARM executables on Windows|x86, so if you want to hit both platforms, you'd be doing it in ARM. I can see ARM being great for corporate desktops: .net LOB apps work, IE will work, Office will work etc.
        rbanffy 16y ago
roc 16y ago
So Microsoft sees a real threat in Chrome OS netbooks then? That's the only place I see this being relevant. Windows in any form that can meaningfully execute legacy x86 code is not going into a non-PC device. (dashboard computers, pocket computers, pmps, phones, tablets, etc) So the only thing left is netbooks. Is that really a relevant play in 2011? Do they think this isn't a feature Google can match and beat them to market on? Do they think the legacy of Windows will be a compelling alternative to the relative simplicity and security of Chrome OS in that market?
- discreteevent 16y ago
  I know that the "news" in this announcement is about ARM. But Soc itself is also about making existing PC software run faster. At the moment there is little argument for purchasing new hardware because multiple cores are failing to significantly improve actual performance of desktop apps for reasons with which we are all familiar.
maguay 16y ago
So how long will it take hackers to get Windows 8 running on an iPad? Will definitely be interesting...
- redthrowaway 16y ago
  Why? Putting Android on the iPhone I get, but I don't see too many hackers out there wanting to flip off Apple by installing Windows, of all things. To put it another way, how many macbook pros are running Win7 solo, aka w/o bootcamp or VMware?
  - scdlbx 16y ago
    Why? For the sole purpose of getting Win8 running on an iPad.
    - redthrowaway 16y ago
      Fair enough.
  - te_chris 16y ago
    Flip off apple? Really? Apple sell them a device, they own it and do what they like with it. I don't think achieving something non-trivial like getting windows 8 running on an ipad is flipping off apple.
    - redthrowaway 16y ago
      I think it's more thumbing their noses at Apple's propensity to lock down their devices. There's no challenge putting windows on an unlocked device, but putting apple's traditional competitor's os on a product that apple's best and brightest had supposedly locked down must carry some kind of thrill.
  - Hacktivist 16y ago
    When the Intel Macs were initial released there was a contest to install Windows XP on it natively (before bootcamp was even announced.) Enough people donated to the prize pool that the winner walked away with 14,000 dollars.
ssp 16y ago
There is the idea that Windows is such a terrible system that the only reason people are staying with it is that they need their legacy applications. It's not entirely without merit, but for a lot of people and businesses, Windows actually works rather well. The importance of x86 is overstated too. Many applications will be pretty close to a recompile away. There is of course the usual chicken-and-egg issue that all platforms have, but if Windows/ARM (WARM?) takes off, they will be recompiled.
- kenjackson 16y ago
  Enterprise LOB is almost all .NET and web now. Native apps are increasingly just consumer apps.
  - dmethvin 16y ago
    If Microsoft ported Office/SharePoint to native ARM I might be able to believe this.
    - contextfree 16y ago
      They are porting Office to native ARM, it was mentioned in Sinofsky's presentation.
      - kenjackson 16y ago
        From the CES demo it appears that they've already done the port. I was really impressed they had IE9 with GPU acceleration on ARM working already too.
    - zmonkeyz 16y ago
      It doesnt run that bad on my Windows Phone 7 :) We'll see how far they go with it.
  - ssp 16y ago
    It isn't clear to me how portable .NET is in practice, but then I don't think it's a problem either way. Enterprises would not want to run some old .NET binary on a new system with a new operating system unless there was vendor support for it. And if there is vendor support, then they would probably just get something certified for the ARM systems.
iuguy 16y ago
I've noticed a lot of speculation about how they will translate code between X86, X86_64 and ARM. Well, the simple answer is not to translate at all. MS have been pushing managed code via things like Silverlight and .NET for some time. My tuppence worth: Windows 8 on ARM won't support legacy x86 code, but will run .NET, Silverlight and any other managed code shamalamadingdong it needs to run. I can see Windows 8 on x86 supporting legacy code, but just as 16-bit support is gone completely in x86_64 Windows now, I'm expecting no support for unmanaged x86 code in the ARM version. Where all this gets interesting is with things like Mono and Moonlight. If MS goes down this route, they could really be exposed as Mono and Moonlight mature.
- jallmann 16y ago
  > Windows 8 on ARM won't support legacy x86 code, but will run .NET. I can see Windows 8 on x86 supporting legacy code Hmm, I don't believe so. That'd introduce fragmentation that Microsoft's typical users (mom and pop) should not have to deal with. Also that'd be a pretty drastic policy shift for Microsoft seeing the pains they've gone to maintain compatibility with older software. My guess is that, at the very least, Win8 apps running native code will be packaged into a universal binary of some sort. I find that half-hearted though, since it requires recompilation of the original software. wtracy suggested the possibility of JITing x86 to ARM, that's ballsy and it'd be awesome if Microsoft pulls that off.
  - iuguy 16y ago
    > wtracy suggested the possibility of JITing x86 to ARM, that's ballsy and it'd be awesome if Microsoft pulls that off. JITing x86 - ARM might not even be fully necessary for most modern apps. It might be possible to do some sort of interception and JIT-style translation for certain parts of code but it might also be possible to provide a DLL level compatibility layer as fallback. That way when DLL functions are called they're called natively, and the main module executes via JIT. I'm not suggesting that would be easy, it'll be balls to the wall hard, but that's the only thing I that immediately springs to mind that wouldn't come with a massive performance penalty. The fragmentation argument is valid and an excellent point to make, however we don't really know who this is being targeted at or the defined primary use cases at this point. If Microsoft can fck up the user experience so badly with Vista and Windows 7 Starter, they can fck up the user experience with ARM and not worry too much. It might also be worth bearing in mind that if a recompile is needed, it's going to be in the next Visual Studio, which will support a lot more managed code features through the CLR than unmanaged code on x86_64 (by which I mean the CLR supports more languages and has fairly tight integration - if you use C++ in Visual Studio you're probably using less of Visual Studio overall than if you're writing ASPX in C#).
brianwillis 16y ago
Can one of you clever people explain what is meant by the term "system on a chip"? Is it just a marketing buzzword, or is there more to it than that? I've tried wikipedia, but just got even more confused.
- jdabney 16y ago
  A system on a chip is a single chip that integrates all or almost all other chips on a motherboard into one chip. So this chip will have a cpu, graphics, memory controller, network controller, io such as usb. That way you can have basically one chip that is all or most of the computer. Sometime RAM and normally storage is separate chips but you basically end up with just a few chips on a very small, normally low power motherboard. It is great for system integrators as they don't need to spend as much development time to build new machines.
  - jmtulloss 16y ago
    It's also great for power and size constraints.
- forgottenpaswrd 16y ago
  Instead of having a motherboard with the RAM, CPU, GPU on different components, you integrate them on a single die or chip. It is going to cost you a lot of money to do it right(you can use multiples dies inside a die but the real thing is just using one single die), but if you can sell enough(like Apple) you win on price per unit, reliability, mount cost, size volume and weight.
maximilianburke 16y ago
I wonder how much effort will be required to port native applications to Windows/ARM. I imagine it won't be too onerous since both x86/x64 and ARM are little-endian. Excepting bits of inline assembly and use of compiler intrinsics I don't think it would be too difficult. I also wonder if there will be a FAT binary extension to PE/COFF, or if applications will have to have separate builds per platform.
Hoff 16y ago
Porting an OS onto a new box can be technically quite interesting, but is only a fraction of the aggregate effort involved. It's the business issues that matter. Whether you can recoup the costs, and when. Application availability, third-party support, hardware vendor support, testing, and whether there's enough of a draw (coolness, compelling price advantage, better battery efficiency, whatever) to pull your user bases to the new platform, and pull in new customers. There's the additional risk with whether and when key vendors will move. It might well technically be a recompile and go for the applications, though the vendors of key applications are probably going to need to see a sufficient market, or they may want some funding for porting. Vendors tend to be (reasonably) loathe to accept this porting and testing and support load without some form of revenue plan. Emulation and translation are technically possible, though that too can be problematic; various vendors can tend not to support emulated or translated code. For understandable reasons, more than a few vendors wouldn't support their applications on Windows on Alpha via FX!32, for instance. I'm also surprised that Microsoft is discussing this now; whether this is a cudgel on some providers, a palliative for their partners considering adding other OS platforms (Android, WebOS or otherwise), customers that are accepting other OS platforms, or whether they're really (seriously?) talking about a project and a potential product that's two years out. Wondering what their particular motivation(s) here might be, still.

81 points by ajg1977 16y ago

Interesting that Microsoft's answer to "Why?" seems to be "Because we can." by journalists. Hopefully they have a better strategy than that. That said, I'm all for more ARM support in the world. It looks like it will run .NET apps with little or no reworking. They probably borrowed a lot of the work of the .NET Compact Framework team for a reverse port. Expect native SDKs later, after the initial launch.

rbanffy 16y ago
I hope they can modulate Windows 8 OEM licensing price in order to convince some OEM to launch an 8 GB of RAM, SATA SSD ARM-based netbook with a x86-sized battery that gives it 48 hours of operation on a single charge. Then I can install a decent OS on the machine and be happy. Unfortunately, I'll have to live with an unsupported hardware. I have no illusion this fad won't be a short-lived one.
- runjake 16y ago
  Can the current ARM implementations even utilize 8GB of RAM at this point? I recall some OMAP issues with even 512 MB not too long ago.
  - wmf 16y ago
    Regular ARM should support 4 GB and LPAE supports terabytes (although each app is limited to 4 GB). Current SoCs probably have much smaller limits, like 1 GB. Nvidia's core may be 64-bit, though, which would eliminate these restrictions.
  - timthorn 16y ago
    The Nvidia part at least will be based on the A15 processor, which includes Large Physical Address Extensions to allow up to 1TB memory.
- kenjackson 16y ago
  I think this no fad, and I think Intel must've seriously screwed up. Everyone knew that Intel was promising MS, "we're going to match ARM on performance per watt in the coming years". That roadmap must have disintegrated, as MS would not have come public otherwise. The batteries will be a little smaller, to reduce weight, but 24 hours of operation on a single charge... that might becomes the standard.
  - rbanffy 16y ago
    In order for Windows on RISC to succeed, Microsoft and all 3rd parties will have to leave the x86 comfort zone and really support it. Last time MS tried to be multi-architecture, they failed miserably. They couldn't even be bothered to port Office to non-x86 machines. And nobody buys a PC to run only Windows and Office. They'll have to do a whole lot more than they did and I don't think they would be capable of.
    - kenjackson 16y ago
      The x86 comfort zone is always by your side. With virtualization (and app virtualization) you can run x86 apps seamlessly. Fortunately Office apps aren't CPU bound. Right, this has always been the play on virtualization for the OS. Don't get stuck in legacy mode, virtualize, and move on. MS may finally be doing what everyone said they should do.
      - wmf 16y ago
        With virtualization (and app virtualization) you can run x86 apps seamlessly. Not on ARM. Emulation is possible but will be really slow.
        kenjackson 16y ago
        How slow? I did some quick profiling of Word and Excel doing basic stuff (text entries, making charts, but no hardcore calculations). Avg CPU utilization: 1%. Peak CPU utilization: 4%. A factor of 10x slowdown would probably be reasonable. Is the current state of the art on ARM able to get it below 10x?
wtracy 16y ago
MS has learned from their experience with Windows on Alpha. Even when they released XP for x86-64, they initially wouldn't sell it at retail for fear that people would get confused and buy the wrong one. I'm betting they have some compatibility magic cooked up that we haven't seen yet. Emulation has already been suggested. How about the possibility of having a launch hook that recompiles x86 machine code to ARM machine code? MS is on the short list of companies with the necessary resources to pull that sort of trick.
- mishmash 16y ago
  Although IBM seems to own them now, it could be the same Rosetta technology that Mac OS X used. The parent company had many public licensees and MS could have been one, but not announced. http://en.wikipedia.org/wiki/Rosetta_(software) http://en.wikipedia.org/wiki/QuickTransit edit: formatting
- runjake 16y ago
  Their "magic" is .NET and MSIL.They explicitly stated they aren't virtualizing or emulating x86 code during the session.
  - contextfree 16y ago
    The real magic is probably the Windows app store and new app packaging format that are also expected to be introduced with Windows 8. I'd imagine apps will be required to support both ARM and x86.
  - brudgers 16y ago
    Right. They have ten years of .NET penetration into the corporate world, the web, and 3rd party application developers - plus four years of .NET integration right into their operating systems. It is running on everything from embedded systems, to phones, to desktops, to clusters. Throw in that all the hardware vendors who are interested in "the Next Windows" and Microsoft has just laid out a roadmap for the next ten years.
  - Niten 16y ago

dmethvin 16y ago

If this is true, then Windows 8 is not a true successor to Windows 7. Current desktop/server apps assume binary compatibility with x86. This sounds much more like a scaled-up version of Windows Phone.

bonzoesc 16y ago
That's a crazy thing to say. The UI, the APIs, etc. will all be based on Windows 7, and any all-CLR apps should run without change. On Windows 8 running on x86, current apps (and Windows 3.1 apps, and maybe DOS apps?) will undoubtedly still run. It's just like the Mac Intel transition, but without an emulator to fill in the gaps.
- kijinbear 16y ago
  Who knows? MS might be obsessed enough with backwards compatibility to pack an emulator in there, like they did with WOW64 (though it would be more difficult to write an x86 emulator for ARM).
  - rbanffy 16y ago
    > it would be more difficult to write an x86 emulator for ARM Building an x86 emulator is easy. Building one that can run Windows 8 software at speeds comparable to then current Intel or AMD x86 processors will probably be impossible. There is no such performance gap between ARM and x86.
    - TeHCrAzY 16y ago
      Would the opposite be easier? It might make sense to offer comparability for Windows|ARM executables on Windows|x86, so if you want to hit both platforms, you'd be doing it in ARM. I can see ARM being great for corporate desktops: .net LOB apps work, IE will work, Office will work etc.
      - rbanffy 16y ago

roc 16y ago

So Microsoft sees a real threat in Chrome OS netbooks then? That's the only place I see this being relevant. Windows in any form that can meaningfully execute legacy x86 code is not going into a non-PC device. (dashboard computers, pocket computers, pmps, phones, tablets, etc) So the only thing left is netbooks. Is that really a relevant play in 2011? Do they think this isn't a feature Google can match and beat them to market on? Do they think the legacy of Windows will be a compelling alternative to the relative simplicity and security of Chrome OS in that market?

discreteevent 16y ago
I know that the "news" in this announcement is about ARM. But Soc itself is also about making existing PC software run faster. At the moment there is little argument for purchasing new hardware because multiple cores are failing to significantly improve actual performance of desktop apps for reasons with which we are all familiar.

maguay 16y ago

So how long will it take hackers to get Windows 8 running on an iPad? Will definitely be interesting...

redthrowaway 16y ago
Why? Putting Android on the iPhone I get, but I don't see too many hackers out there wanting to flip off Apple by installing Windows, of all things. To put it another way, how many macbook pros are running Win7 solo, aka w/o bootcamp or VMware?
- scdlbx 16y ago
  Why? For the sole purpose of getting Win8 running on an iPad.
  - redthrowaway 16y ago
    Fair enough.
- te_chris 16y ago
  Flip off apple? Really? Apple sell them a device, they own it and do what they like with it. I don't think achieving something non-trivial like getting windows 8 running on an ipad is flipping off apple.
  - redthrowaway 16y ago
    I think it's more thumbing their noses at Apple's propensity to lock down their devices. There's no challenge putting windows on an unlocked device, but putting apple's traditional competitor's os on a product that apple's best and brightest had supposedly locked down must carry some kind of thrill.
- Hacktivist 16y ago
  When the Intel Macs were initial released there was a contest to install Windows XP on it natively (before bootcamp was even announced.) Enough people donated to the prize pool that the winner walked away with 14,000 dollars.

ssp 16y ago

There is the idea that Windows is such a terrible system that the only reason people are staying with it is that they need their legacy applications. It's not entirely without merit, but for a lot of people and businesses, Windows actually works rather well. The importance of x86 is overstated too. Many applications will be pretty close to a recompile away. There is of course the usual chicken-and-egg issue that all platforms have, but if Windows/ARM (WARM?) takes off, they will be recompiled.

kenjackson 16y ago
Enterprise LOB is almost all .NET and web now. Native apps are increasingly just consumer apps.
- dmethvin 16y ago
  If Microsoft ported Office/SharePoint to native ARM I might be able to believe this.
  - contextfree 16y ago
    They are porting Office to native ARM, it was mentioned in Sinofsky's presentation.
    - kenjackson 16y ago
      From the CES demo it appears that they've already done the port. I was really impressed they had IE9 with GPU acceleration on ARM working already too.
  - zmonkeyz 16y ago
    It doesnt run that bad on my Windows Phone 7 :) We'll see how far they go with it.
- ssp 16y ago
  It isn't clear to me how portable .NET is in practice, but then I don't think it's a problem either way. Enterprises would not want to run some old .NET binary on a new system with a new operating system unless there was vendor support for it. And if there is vendor support, then they would probably just get something certified for the ARM systems.

iuguy 16y ago

I've noticed a lot of speculation about how they will translate code between X86, X86_64 and ARM. Well, the simple answer is not to translate at all. MS have been pushing managed code via things like Silverlight and .NET for some time. My tuppence worth: Windows 8 on ARM won't support legacy x86 code, but will run .NET, Silverlight and any other managed code shamalamadingdong it needs to run. I can see Windows 8 on x86 supporting legacy code, but just as 16-bit support is gone completely in x86_64 Windows now, I'm expecting no support for unmanaged x86 code in the ARM version. Where all this gets interesting is with things like Mono and Moonlight. If MS goes down this route, they could really be exposed as Mono and Moonlight mature.

jallmann 16y ago
> Windows 8 on ARM won't support legacy x86 code, but will run .NET. I can see Windows 8 on x86 supporting legacy code Hmm, I don't believe so. That'd introduce fragmentation that Microsoft's typical users (mom and pop) should not have to deal with. Also that'd be a pretty drastic policy shift for Microsoft seeing the pains they've gone to maintain compatibility with older software. My guess is that, at the very least, Win8 apps running native code will be packaged into a universal binary of some sort. I find that half-hearted though, since it requires recompilation of the original software. wtracy suggested the possibility of JITing x86 to ARM, that's ballsy and it'd be awesome if Microsoft pulls that off.
- iuguy 16y ago
  > wtracy suggested the possibility of JITing x86 to ARM, that's ballsy and it'd be awesome if Microsoft pulls that off. JITing x86 - ARM might not even be fully necessary for most modern apps. It might be possible to do some sort of interception and JIT-style translation for certain parts of code but it might also be possible to provide a DLL level compatibility layer as fallback. That way when DLL functions are called they're called natively, and the main module executes via JIT. I'm not suggesting that would be easy, it'll be balls to the wall hard, but that's the only thing I that immediately springs to mind that wouldn't come with a massive performance penalty. The fragmentation argument is valid and an excellent point to make, however we don't really know who this is being targeted at or the defined primary use cases at this point. If Microsoft can fck up the user experience so badly with Vista and Windows 7 Starter, they can fck up the user experience with ARM and not worry too much. It might also be worth bearing in mind that if a recompile is needed, it's going to be in the next Visual Studio, which will support a lot more managed code features through the CLR than unmanaged code on x86_64 (by which I mean the CLR supports more languages and has fairly tight integration - if you use C++ in Visual Studio you're probably using less of Visual Studio overall than if you're writing ASPX in C#).

brianwillis 16y ago

Can one of you clever people explain what is meant by the term "system on a chip"? Is it just a marketing buzzword, or is there more to it than that? I've tried wikipedia, but just got even more confused.

jdabney 16y ago
A system on a chip is a single chip that integrates all or almost all other chips on a motherboard into one chip. So this chip will have a cpu, graphics, memory controller, network controller, io such as usb. That way you can have basically one chip that is all or most of the computer. Sometime RAM and normally storage is separate chips but you basically end up with just a few chips on a very small, normally low power motherboard. It is great for system integrators as they don't need to spend as much development time to build new machines.
- jmtulloss 16y ago
  It's also great for power and size constraints.
forgottenpaswrd 16y ago
Instead of having a motherboard with the RAM, CPU, GPU on different components, you integrate them on a single die or chip. It is going to cost you a lot of money to do it right(you can use multiples dies inside a die but the real thing is just using one single die), but if you can sell enough(like Apple) you win on price per unit, reliability, mount cost, size volume and weight.

maximilianburke 16y ago

I wonder how much effort will be required to port native applications to Windows/ARM. I imagine it won't be too onerous since both x86/x64 and ARM are little-endian. Excepting bits of inline assembly and use of compiler intrinsics I don't think it would be too difficult. I also wonder if there will be a FAT binary extension to PE/COFF, or if applications will have to have separate builds per platform.

Hoff 16y ago

Porting an OS onto a new box can be technically quite interesting, but is only a fraction of the aggregate effort involved. It's the business issues that matter. Whether you can recoup the costs, and when. Application availability, third-party support, hardware vendor support, testing, and whether there's enough of a draw (coolness, compelling price advantage, better battery efficiency, whatever) to pull your user bases to the new platform, and pull in new customers. There's the additional risk with whether and when key vendors will move. It might well technically be a recompile and go for the applications, though the vendors of key applications are probably going to need to see a sufficient market, or they may want some funding for porting. Vendors tend to be (reasonably) loathe to accept this porting and testing and support load without some form of revenue plan. Emulation and translation are technically possible, though that too can be problematic; various vendors can tend not to support emulated or translated code. For understandable reasons, more than a few vendors wouldn't support their applications on Windows on Alpha via FX!32, for instance. I'm also surprised that Microsoft is discussing this now; whether this is a cudgel on some providers, a palliative for their partners considering adding other OS platforms (Android, WebOS or otherwise), customers that are accepting other OS platforms, or whether they're really (seriously?) talking about a project and a potential product that's two years out. Wondering what their particular motivation(s) here might be, still.