4 ms·

Microsoft previously had Win8 , RT and Windows Phone. The latter two needed to be distinct because they were ARM based so there would be software compatibility

by jiggy2011 12y ago

Microsoft previously had Win8 , RT and Windows Phone. The latter two needed to be distinct because they were ARM based so there would be software compatibility issues with software that was developed for Win8. The plan here seems to be to build all Windows phones and tablets with x86 chips to eliminate that issue.

eat 12y ago
>The plan here seems to be to build all Windows phones and tablets with x86 chips to eliminate battery life. FTFY
personZ 12y ago
The plan here seems to be to build all Windows phones and tablets with x86 chips to eliminate that issue. That was an analyst guessing, not Microsoft setting a strategy. It is extraordinarily doubtful that Microsoft would go all in on x86 like that, and it would be somewhat archaic if they did. I would surmise that Microsoft is speaking from a development/management perspective. If WinRT had all of the APIs available in Win32/64, for instance, whether it's ARM or MIPS or AMD64 shouldn't really matter that much for cross-targeting apps like Office (which I doubt has much assembly in it): If the compiler supports it, it's an option. And from an internal perspective we know from a post yesterday that they laid off a Windows test engineer, probably because their plan going forward is that the major services (and obviously teams) of all of the platforms combine, which makes a lot of sense. Instead of teams forking off bits of Windows and then creating their own silos, it makes sense that the active development copy of many subsystems for all of the products is shared live.
- jiggy2011 12y ago
  But surely anything else would be a disaster from a messaging point of view considering that the Windows lineup is already confusing enough as it is. Unless you can somehow force developers to produce binaries for all platforms and have that include all legacy applications which is doubtful.
  - personZ 12y ago
    If it supported the same APIs, a platform encountering native code from another platform could simply do binary translation (where simply means "enormously complex and difficult, but a solved problem"). This is exactly what x86 Android phones do when they encounter APKs with native ARM and no equivalent x86, via Intel's "Houdini" solution: The performance is actually surprisingly good, and far exceeds most expectations. And of course Microsoft could do this en masse in their application store. And really, if cross compiling a rich desktop application was simply a matter of picking a different target configuration in Visual Studio, everyone would target ARM(v8) as well, because it costs close to nothing. As is, however, that is not the case- WinRT is a very special snowflake, with a subset API. Even if you went purely virtualized with .NET, you still have the special restrictions and constraints of WinRT that mean that you have to generally specifically develop for it. Microsoft is in such a strange place. Well over a decade ago they tried to move everything to higher layers, abstracting themselves from the underlying hardware. Today they seem to be in a worse place that they even were then.
    - jiggy2011 12y ago
      Wouldn't that necessitate all phones to ship with complete Win32 API (complete with all backwards compatibility stuff) as well as the translation software, I can't imagine what that would do to battery life, let alone storage.
      - personZ 12y ago
        The binary translation happens on install of apps, and unused APIs consume no CPU time. As for storage, if a unified platform supported every legacy API, the same problem exists whether it is x86 or ARM, so that seems orthogonal to this discussion. Regardless it's worth considering how mobile and tablet devices have exploded in capabilities (my smartphone has 2GB of RAM. Windows XP required 64MB). Would it support every legacy API? Not necessarily. Being unified doesn't necessarily mean that, and Microsoft has threatened Win32 and friends for time eternal (e.g. http://www.windowsdevcenter.com/pub/a/windows/2004/07/13/winfx.html http://www.windowsdevcenter.com/pub/a/windows/2004/07/13/win...). Unified can simply mean that from this point forward, WinXX is unified, or the .NET platform is holistic and all-encompassing (which has always been the goal of that platform, but somehow keeps getting screwed up), or whatever.

eat 12y ago

>The plan here seems to be to build all Windows phones and tablets with x86 chips to eliminate battery life. FTFY

personZ 12y ago

The plan here seems to be to build all Windows phones and tablets with x86 chips to eliminate that issue. That was an analyst guessing, not Microsoft setting a strategy. It is extraordinarily doubtful that Microsoft would go all in on x86 like that, and it would be somewhat archaic if they did. I would surmise that Microsoft is speaking from a development/management perspective. If WinRT had all of the APIs available in Win32/64, for instance, whether it's ARM or MIPS or AMD64 shouldn't really matter that much for cross-targeting apps like Office (which I doubt has much assembly in it): If the compiler supports it, it's an option. And from an internal perspective we know from a post yesterday that they laid off a Windows test engineer, probably because their plan going forward is that the major services (and obviously teams) of all of the platforms combine, which makes a lot of sense. Instead of teams forking off bits of Windows and then creating their own silos, it makes sense that the active development copy of many subsystems for all of the products is shared live.

jiggy2011 12y ago
But surely anything else would be a disaster from a messaging point of view considering that the Windows lineup is already confusing enough as it is. Unless you can somehow force developers to produce binaries for all platforms and have that include all legacy applications which is doubtful.
- personZ 12y ago
  If it supported the same APIs, a platform encountering native code from another platform could simply do binary translation (where simply means "enormously complex and difficult, but a solved problem"). This is exactly what x86 Android phones do when they encounter APKs with native ARM and no equivalent x86, via Intel's "Houdini" solution: The performance is actually surprisingly good, and far exceeds most expectations. And of course Microsoft could do this en masse in their application store. And really, if cross compiling a rich desktop application was simply a matter of picking a different target configuration in Visual Studio, everyone would target ARM(v8) as well, because it costs close to nothing. As is, however, that is not the case- WinRT is a very special snowflake, with a subset API. Even if you went purely virtualized with .NET, you still have the special restrictions and constraints of WinRT that mean that you have to generally specifically develop for it. Microsoft is in such a strange place. Well over a decade ago they tried to move everything to higher layers, abstracting themselves from the underlying hardware. Today they seem to be in a worse place that they even were then.
  - jiggy2011 12y ago
    Wouldn't that necessitate all phones to ship with complete Win32 API (complete with all backwards compatibility stuff) as well as the translation software, I can't imagine what that would do to battery life, let alone storage.
    - personZ 12y ago
      The binary translation happens on install of apps, and unused APIs consume no CPU time. As for storage, if a unified platform supported every legacy API, the same problem exists whether it is x86 or ARM, so that seems orthogonal to this discussion. Regardless it's worth considering how mobile and tablet devices have exploded in capabilities (my smartphone has 2GB of RAM. Windows XP required 64MB). Would it support every legacy API? Not necessarily. Being unified doesn't necessarily mean that, and Microsoft has threatened Win32 and friends for time eternal (e.g. http://www.windowsdevcenter.com/pub/a/windows/2004/07/13/winfx.html http://www.windowsdevcenter.com/pub/a/windows/2004/07/13/win...). Unified can simply mean that from this point forward, WinXX is unified, or the .NET platform is holistic and all-encompassing (which has always been the goal of that platform, but somehow keeps getting screwed up), or whatever.