Got Application cross-compiled with msvc11 for ARM running
Hi, I cross-compiled a simple Application with the preview of MSVC 11 to ARM. After some minor changes to Wine i was able to run it on my Pandaboard using the native msvcr110.dll. One thing i noticed in the cross-compile environment is that there are much less libraries available for ARM, that's mostly because the win32 API isn't meant to be ported entirely, instead ARM Apps should be based on WinRT. Still i was able to dynamic load functions from dlls available in Wine beside static loaded functions that also worked. In short: The good news: The ABI is compatible (to armel gnueabi) The bad news: no fully win32 API on ARM Maybe my small changes to Wine will make it into 1.5.1 :) At least i hope so. -- Best Regards, André Hentschel
On 03/08/2012 05:40 PM, André Hentschel wrote:
Hi, I cross-compiled a simple Application with the preview of MSVC 11 to ARM. After some minor changes to Wine i was able to run it on my Pandaboard using the native msvcr110.dll. One thing i noticed in the cross-compile environment is that there are much less libraries available for ARM, that's mostly because the win32 API isn't meant to be ported entirely, instead ARM Apps should be based on WinRT. Still i was able to dynamic load functions from dlls available in Wine beside static loaded functions that also worked.
In short: The good news: The ABI is compatible (to armel gnueabi) The bad news: no fully win32 API on ARM Bad news? Quite the contrary. Good use case for Wine on Windows.
Maybe my small changes to Wine will make it into 1.5.1 :) At least i hope so. 1.5.1 or 1.4.1?
bye michael
Am 08.03.2012 17:52, schrieb Michael Stefaniuc:
On 03/08/2012 05:40 PM, André Hentschel wrote:
Hi, I cross-compiled a simple Application with the preview of MSVC 11 to ARM. After some minor changes to Wine i was able to run it on my Pandaboard using the native msvcr110.dll. One thing i noticed in the cross-compile environment is that there are much less libraries available for ARM, that's mostly because the win32 API isn't meant to be ported entirely, instead ARM Apps should be based on WinRT. Still i was able to dynamic load functions from dlls available in Wine beside static loaded functions that also worked.
In short: The good news: The ABI is compatible (to armel gnueabi) The bad news: no fully win32 API on ARM Bad news? Quite the contrary. Good use case for Wine on Windows. If we get that running, true.
Maybe my small changes to Wine will make it into 1.5.1 :) At least i hope so. 1.5.1 or 1.4.1? I don't decide that :) Maybe both ;)
-- Best Regards, André Hentschel
On 03/08/2012 05:54 PM, André Hentschel wrote:
Am 08.03.2012 17:52, schrieb Michael Stefaniuc:
On 03/08/2012 05:40 PM, André Hentschel wrote:
Hi, I cross-compiled a simple Application with the preview of MSVC 11 to ARM. After some minor changes to Wine i was able to run it on my Pandaboard using the native msvcr110.dll. One thing i noticed in the cross-compile environment is that there are much less libraries available for ARM, that's mostly because the win32 API isn't meant to be ported entirely, instead ARM Apps should be based on WinRT. Still i was able to dynamic load functions from dlls available in Wine beside static loaded functions that also worked.
In short: The good news: The ABI is compatible (to armel gnueabi) The bad news: no fully win32 API on ARM Bad news? Quite the contrary. Good use case for Wine on Windows. If we get that running, true. I don't mean the full Wine, just the missing libs and headers for people to easily port their Windows apps to ARM.
Maybe my small changes to Wine will make it into 1.5.1 :) At least i hope so. 1.5.1 or 1.4.1? I don't decide that :) Maybe both ;)
bye michael
Am 08.03.2012 22:15, schrieb Stefan Dösinger:
Am Donnerstag, 8. März 2012, 17:59:48 schrieb Michael Stefaniuc:
I don't mean the full Wine, just the missing libs and headers for people to easily port their Windows apps to ARM. What libraries are missing? Or is this still under NDA?
Easier to tell what's available: ActiveDS.Lib evr.lib PortableDeviceGuids.lib AdvAPI32.Lib Gdi32.Lib RpcRT4.Lib ComDlg32.Lib kernel32.Lib shell32.lib d2d1.lib Mfcore.lib strsafe.lib d3d11.lib Mf.lib twinapi.lib d3dcompiler.lib Mfplat.lib UIAutomationCore.lib dcomp.lib mfreadwrite.lib User32.Lib deviceaccess.lib mfuuid.lib Uuid.Lib DhcpCSvc6.Lib mmdevapi.lib WebServices.lib DhcpCSvc.Lib msxml6.lib windowscodecs.lib dloadhelper.lib normaliz.lib WinSpool.Lib dwrite.lib odbc32.lib Xinput.lib dxgi.lib odbccp32.lib xmllite.lib ElsCore.lib Ole32.Lib esent.lib OleAut32.Lib (That's the build environment, can't tell what will be available in WOA) -- Best Regards, André Hentschel
Without opengl, we won't be able to run wined3d. Msi also seems like an important gap. In theory, we can cover that, but I have to wonder about the consequences of putting Wine's msi in a WOA system. It looks like a good base for the rest of Wine to me. It helps that all our sound now goes through mmdevapi, and all our imaging goes through windowscodecs. Let's hope opengl/msi appear in the final WOA, or can be replaced somehow.
Am Donnerstag, 8. März 2012, 18:38:16 schrieb Vincent Povirk:
Without opengl, we won't be able to run wined3d. Yeah, that's unfortunate. d3d9.dll is a big gap in the dll list we could fill.
Depending on the 3D driver, we may be able to call into the vendor ICD if microsoft doesn't provide a opengl32.dll. André, can you check if gdi32 has wgl exports like wglCreateContext and wglMakeCurrent?
Am 09.03.2012 08:24, schrieb Stefan Dösinger:
Am Donnerstag, 8. März 2012, 18:38:16 schrieb Vincent Povirk:
Without opengl, we won't be able to run wined3d. Yeah, that's unfortunate. d3d9.dll is a big gap in the dll list we could fill.
Depending on the 3D driver, we may be able to call into the vendor ICD if microsoft doesn't provide a opengl32.dll.
André, can you check if gdi32 has wgl exports like wglCreateContext and wglMakeCurrent?
sadly not...as expected -- Best Regards, André Hentschel
On 9 March 2012 01:38, Vincent Povirk <madewokherd(a)gmail.com> wrote:
Without opengl, we won't be able to run wined3d.
It also makes it a bit harder for browsers to support WebGL, which seems to be one of the things that's currently considered shiny, terrible idea as it may be. I guess they'll port ANGLE to d3d11.
participants (5)
-
André Hentschel -
Henri Verbeet -
Michael Stefaniuc -
Stefan Dösinger -
Vincent Povirk