Windows-on-Arm won't support win32
According to http://www.zdnet.com/blog/perlow/the-long-kiss-goodbye-for-x86-desktop-windo... Microsoft is not letting developers use win32 on arm (although Microsoft is probably using it themselves for Office on arm). Instead, native apps have to use WinRT, a C++-based class library. According to http://en.wikipedia.org/wiki/Windows_Runtime, the WinRT libraries are built on top of win32 internally. If it takes off, and someone feels like supporting it in Wine, they would probably have to start by implementing the first bits in C like wine's msvcp support. Eventually, if and when llvm gets Visual C++ ABI support, maybe wine could start allowing C++ source code. (FWIW, I see Charles Davis was working on that, http://code.google.com/p/google-summer-of-code-2010-llvm/updates/list http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-March/014305.html https://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/MicrosoftCXXABI.c... ).
I think it's way too early for this sort of speculation. I don't know where you're getting the idea that C++ is the primary way of accessing WinRT APIs. It's apparently a way of doing so, but that doesn't mean it'll be the way most developers choose. We also don't know whether the distribution model for WinRT apps even makes it possible for us to obtain many such apps. Presumably, we won't have a way to just download the files from the Win8 store. Sideloading will most likely (but might not) be possible, but if so Wine's usefulness will be limited to apps that can be obtained in that way. I've also been told that "not supported" doesn't necessarily mean "won't run", though even if Microsoft isn't signing all their win32 arm binaries it's likely that the arm desktop does not provide a fully-featured win32 api. We just have to see what win8-on-arm looks like when it comes out.
On Mon, Feb 13, 2012 at 2:38 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote:
I don't know where you're getting the idea that C++ is the primary way of accessing WinRT APIs.
? I was talking about implementing WinRT, not using it. But it's true, if all apps talk to it via COM, the language it's implemented in shouldn't matter. (I guess I'm having trouble imagining not using C++ to implement a large class library, but that's just my bias.)
We also don't know whether the distribution model for WinRT apps even makes it possible for us to obtain many such apps. Presumably, we won't have a way to just download the files from the Win8 store. Sideloading will most likely (but might not) be possible, but if so Wine's usefulness will be limited to apps that can be obtained in that way.
Yup. I guess my subject line was the main point of my post: we shouldn't expect there to be many plain old arm win32 apps. - Dan
On 13 February 2012 22:20, Dan Kegel <dank(a)kegel.com> wrote:
According to http://www.zdnet.com/blog/perlow/the-long-kiss-goodbye-for-x86-desktop-windo... Microsoft is not letting developers use win32 on arm (although Microsoft is probably using it themselves for Office on arm). Instead, native apps have to use WinRT, a C++-based class library.
WinRT consists of: 1. a cutdown set of the Win32 API (including subsets of DirectX 11, DirectWrite, etc); 2. an extension to COM that provides .NET-style metadata about objects via IInspectable and other APIs (akin to IDispatch); 3. a set of APIs that build on top of (2), including a Metro-specific XAML API; 4. bindings to the WinRT COM API via (a) C++ extensions (think _bstr_t and friends or ATL with language extensions similar to C++/CLI, but compiling to native COM code), (b) .NET (through the .NET runtime) and (c) HTML/JavaScript via the IE10 JavaScript platform. So C++ code is not needed to implement the WinRT API: it can be handled through the existing COM in C mechanisms that Wine uses. - Reece
On Feb 13, 2012, at 3:20 PM, Dan Kegel wrote:
According to http://www.zdnet.com/blog/perlow/the-long-kiss-goodbye-for-x86-desktop-windo... Microsoft is not letting developers use win32 on arm (although Microsoft is probably using it themselves for Office on arm). Instead, native apps have to use WinRT, a C++-based class library. As others have pointed out, that's not entirely true. Yes, it's probably written in C++. Yes, two of the interfaces to this are C++ class libraries, one of which requires a special version of C++ (dubbed C++/CX by MS). But WinRT itself is not a C++ class library; it's a COM library with a few extensions to COM. And that means...
If it takes off, and someone feels like supporting it in Wine, they would probably have to start by implementing the first bits in C like wine's msvcp support. ...our implementation can be written purely in C the same way all our COM DLLs are.
But that's if it takes off. And I don't see that happening. Personally, I think we should be putting our already strained resources into improving compatibility with Win32. With Microsoft apparently ready to all but abandon Win32, Wine will be more important than ever as a way to run legacy apps that aren't based on WinRT.
Eventually, if and when llvm gets Visual C++ ABI support, maybe wine could start allowing C++ source code.
(FWIW, I see Charles Davis was working on that, http://code.google.com/p/google-summer-of-code-2010-llvm/updates/list http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-March/014305.html https://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/MicrosoftCXXABI.c... ). As an aside, I actually started working on that precisely so Wine could use it :).
Chip
On Mon, Feb 13, 2012 at 4:36 PM, Charles Davis <cdavis(a)mymail.mines.edu> wrote:
If it takes off, and someone feels like supporting it in Wine, they would probably have to start by implementing the first bits in C like wine's msvcp support. ...our implementation can be written purely in C the same way all our COM DLLs are.
Or, come to think of it, we could write in Mono.
Eventually, if and when llvm gets Visual C++ ABI support, maybe wine could start allowing C++ source code.
(FWIW, I see Charles Davis was working on that, http://code.google.com/p/google-summer-of-code-2010-llvm/updates/list http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-March/014305.html https://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/MicrosoftCXXABI.c... ). As an aside, I actually started working on that precisely so Wine could use it :).
How far along is it? - Dan
On Feb 13, 2012, at 7:09 PM, Dan Kegel wrote:
On Mon, Feb 13, 2012 at 4:36 PM, Charles Davis <cdavis(a)mymail.mines.edu> wrote:
...our implementation can be written purely in C the same way all our COM DLLs are.
Or, come to think of it, we could write in Mono. True, but do we really want a hard dependency on Mono? (I know we already have a soft one, but from what I can tell from wine-users, it doesn't seem to work very well for running .NET apps.)
As an aside, I actually started working on that precisely so Wine could use it :).
How far along is it? Not very far at all, actually. I worked a bit on name mangling and 64-bit EH, and someone else is working on class layouts, but it's far from usable. Part of the problem is that I haven't had much time to work on it.
Chip
participants (4)
-
Charles Davis -
Dan Kegel -
Reece Dunn -
Vincent Povirk