5 ms·

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

by 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.
      - jiggy2011 12y ago
        I was thinking more of trying to translate an entire heavyish weight x86 application on a mobile phone, probably not pleasant. You're right that the API issue is basically orthogonal, but I can't see how this could be done without having either a very bloated phone OS or an overly restricted desktop OS.

by personZ 12y ago

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.
    - jiggy2011 12y ago
      I was thinking more of trying to translate an entire heavyish weight x86 application on a mobile phone, probably not pleasant. You're right that the API issue is basically orthogonal, but I can't see how this could be done without having either a very bloated phone OS or an overly restricted desktop OS.