5 ms·

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

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

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.