As I've promised earlier - I've updated the first post with a new build.
[Beta] Win86emu: Running x86 apps on WinRT devices
- Thread starter mamaich
- Start date
Glad to hear this has finally reached beta, but every time I try to run anything other than the H3 Demo file provided in previous versions, I get the "Error in the emulated program" message. Including HOMM3 Complete with the 32-bit patch or the HD patch set to 32-bit. I enabled full logging in the registry, and the file literally says "Logger initialised" and "Logger unloaded"
Last edited:
"Error in the emulated program" means that there is a problem with a program you are trying to execute and emulator can't even start running it.
Here are the reasons: emulated EXE cannot be found or somehow is inaccessible (for example due to NTFS permissions), there is error in the file format (not x86 PE), loader can't find peldr.nt.dll (broken installation), or loader can't reserve memory. In the last case the peloader.exe would be relaunched 100 times and you'll see that it writes the line "Failed to reserve memory (0x%08x, %d) due to ASLR, please rerun the application". Normally it needs 1-3 peloader.exe restarts depending on the size of a program.
I've attached an updated launcher.exe that provides exact reason of the error. Replace the old one and try again.
One more note. If you don't specify log file name in registry - the log would be created in %temp% and there would be 2 log files. One for launcher and the second for the actual emulator.
edited: attached the file to the first post. Also fixed the no sound problem in pinball and some other programs.
Last edited:
Edit: actually, after closing the launcher in the notification area and re-running it, I get "Can't open emulated EXE file."
Edit2: Could it be spaces in the location of the exe? Going to test in a moment...
Edit2: Yep, that was the issue. New issue now though:
HOMM3:
Though _HD3_.dll does exist.
AOE2:
edit4:
These are the four dll's it requested before finally crashing
And here's a log file: http://txt.wizrd.tk/yact_0014dc.log
Hope it helps, it's almost 3am here. I'm heading to bed.
Last edited:
Strange, after I installed this program, my tablet became very buggy: screen resolution is dropping periodically to 1024x768, metro IE crashes, sudden freezes with black screen, even after reboot(without launching jailbreak, even). I realize, that its very improbable that it is your app, that causes this, but since yesterday, it was the only thing that changed. Also, nothing seems to run, keep getting infinite command prompts opening and then error, or the error alone. Will try logging and reinstalling.
You are right - spaces and quotes in the EXE file name are not supported - I'll fix that.
This means that _HD3_.dll can't be loaded due to PSAPI.DLL not found. There is a mistake in the error message, it should be "import dll xxx or some of its dependencies not found".
You may try to get psapi.dll from NT4 or 2K, but I don't think that it would work as it probably would depend on the not implemented kernel functions. I'll check that myself.
HD mod 2.98 is working.
I'll try to run AOE myself, would post the progress here.
Yes, it cannot be my app as it just can't run without jailbreak. And even after a jailbreak it does not make any changes in OS at all even in RAM.
Theoretically it is possible that some of the emulated apps may break something in the host OS registry - but registry redirection should prevent that from happening.
Try simple and old programs first. More modern ones may require the DLLs I have not implemented yet.
Regarding AOE and similar old games. Most of them require 256-color mode that is not supported on RT. After adding the missing DLLs, I'll need to emulate that mode manually, the work is in progress, but unfinished yet.
So anyway, reinstalled the app, created a loglevel setting, tried running some programs that I miss from x86. Halite: requires msimg32.dll and probably some other ones, tried adding it to win86emu\system32, got errors("Import GdiTransparentBlt not found in" and some other GDI-related stuff) and another dll missing - WS2_32.dll. uTorrent: Can't open emulated .exe, no logs created.
old build of foobar2000:
mplayer: WS2_32.dll, avformat-53.dll not found
It would be great if you'd have ported WS2_32.dll and msimg32.dll. And thanks for the contribution to the winrt development, if you get this thing working, it would be super-awesome.
old build of foobar2000:
XnView: MSVFW32.dll not found.
mplayer: WS2_32.dll, avformat-53.dll not found
It would be great if you'd have ported WS2_32.dll and msimg32.dll. And thanks for the contribution to the winrt development, if you get this thing working, it would be super-awesome.
XnView and media player - they use OS codecs that are not present on RT. Ir is theoretically possible to use them through emulation - but speed would be too slow.
Regarding other apps - I'll test them, thank you for the list.
Regarding other apps - I'll test them, thank you for the list.
xnview, mplayer and foobar2000 are on the list just because there's no decent alternative to them, I still couldn't find the store app that handles .gif files well, for example. Also, tried launching leaked beta build of half-life, but it requires opengl which is, as I've read in other thread, is very improbable to run well enough.
Half-life has a software renderer too, though it may still require OGL libs for some reason.
New version is great! However, a few things that I noticed, no particular order:
- Since one of the easiest ways to get a full file path is to Shift+Right-Click a filename and select "Copy as Path" (which quotation-wraps the path), it would really help to have quotation marks handled correctly (I know you're working on it).
- Although the latest launcher is better about providing failure messages, it would still help a lot to have it show something in all failure cases. For example, if a required DLL can't be found, it exits silently right now (ideally, it would mention the specific file needed).
- Similarly, it would be good to have it say something like "Can't open EXE file: File not found" or "Can't open EXE file: Access denied" or similar, based on the errors received.
- Rather than using the system tray, why not just have the launcher sit in the taskbar? That's a lot more touch-friendly.
- Taking that point further: jump lists! Recent EXEs, pinned EXEs, etc. I think you could actually just do it using the recently used file list functionality already found in Windows. This would make it a lot easier to launch programs.
- Please implement passing EXE paths as parameters (either to launcher or peloader). This would make it easy to script the launcher, would allow drag-and-drop on the launcher EXE or right-click-> Send To if a shortcut to the launcher was added there, or automatically launching the emulation layer using filetype associations (.exe_x86 or similar) or possibly Image File Execution Options. Might be required MRU lists to work right anyhow.
- Non-ASLR large programs (for example, many installers) can be really hard to start. The thing is, most of those programs are perfectly compatible with ASLR, they just don't know it (it's just a flag in the binary); having an option to force the dynamic base behavior would be good just to see if it will work anyhow.
- Lacking that / as an alternative solution to the ASLR problem, it might work to create a really tiny launcher program that temporarily reserves a bunch of memory at the default load address, then dynamically loads the actual launcher code to help ensure that the launcher code doesn't get loaded into the default space.
- Required DLL that I found a few programs complaining about: wininet.dll. I tried copying it from syswow64 on my Win8 box, but that didn't work; an older version might perhaps.
- Stretch goal: OpenGL compatibility layer by translating to DirectX (sort of like what Wine does to run D3D code on *nix). This would obviously be a huge project, but it would be very cool...
Alright, so following your mention of HD mod 2.98 working, I started with a fresh setup of HOMM3 Complete, patched it, and tried running it. A few times it wouldn't launch at all, and peloader.exe would stop responding and close, but I was able to get it to actually launch twice. However, those two times the game window closed after the 3DO logo, with the peloader.exe still open (which I then had to close myself).
Here's the log file from one such launch: http://txt.wizrd.tk/yact_000f1c.log
Here's the log file from one such launch: http://txt.wizrd.tk/yact_000f1c.log
Disabling ShowIntro (in the registry, under the emulated HKLM) let me get past that. Alternatively, run the un-color-patched version; it looks awful and runs slowly, but once you sit through the into once you can skip it in future bit hitting Esc during the "3DO" video.
Yep, with that fix and a few relaunches (from the instant crashing) it works perfectly. I'd rather not do one where I need to skip it because I have no ESC key and don't want to be time limited.
Now the only thing limiting gameplay is the lag in map view. Would there be a way to lower the quality or something, or does it simply need more work?
Rebooting will change the ASLR-caused memory layouts, which are the cause of this error and might be fixed with a reboot. It's pretty random though; there's no guarantee. Sometimes it will work if you just try enough, other times it won't work at all.
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
96The project is abandoned.
As I no longer own a Windows RT device and I'm not willing to use Windows RT anymore, unless Microsoft would make it more open (at least to run your own desktop apps) - I've decided to stop working on this project.
As usual I'm publishing complete sources of this tool. Feel free to use them in your own projects or to continue developing this one - only leave my copyrights somewhere.
Don't ask me how to build the sources or to explain anything in them. Figure that out yourself.
The project is abandoned. Sorry.
I'm presenting a tool that allows running a set of x86 Windows applications on Windows RT (ARM) tablets. Its goal is to support all apps except for those that:
- require much CPU power,
- use complex features that were cut out from WinRT like D3D9 extensions or OpenGL,
- require drivers or specific services,
- make heavy use of COM interfaces,
- use undocumented windows internals,
- apps that use .NET framework,
- x86 Metro apps,
- 16 or 64 bit Windows programs,
- buggy apps that require special workarounds.
The tool is currently on a beta stage, so don't expect much from it. It is far from being complete, but at least it runs something.
Current version: 0.061
Just a minor update. The project is not dead, I just had no time to continue the development.
Attached the fixed ntdll.nt.dll that works under Windows RT 8.1 (Microsoft removed some NTDLL exports, so I had to add more stubs). This fix is not needed on RT 8.0.
To install it: extract the attached 0.061-ntdll.nt.dll.zip to c:\x86node\windows\SystemNT\ overwriting the existing file.
Autostarting x86 programs does not work on RT 8.1 ("can't install CreateProcessInternal hook"). I'll look on this later.
Don't ask on jailbreaking the 8.1 beta in this thread - there is a good progress on it, more info would be on release (in october or when WZOR would leak the RTM).
Current version: 0.06
Seems that archive is too big to be attached, so I've uploaded it to google drive and here
Installation: extract the archive on your unlocked Windows RT device, run the MSI file and follow the instructions.
Note: Uninstall the previous version before installing a new one.
List of compatible apps is in this post: http://xdaforums.com/showthread.php?p=40924456
Trademarks
Windows is a registered trademark of Microsoft Corporation. ReactOS is a registered trademark or a trademark of ReactOS Foundation. All other trademarks are the property of their respective owners.
Disclaimer
This software is provided "as is". Use it on your own risk. I make no warranties as to performance, merchantability, fitness for a particular purpose, or any other warranties whether expressed or implied. No oral or electronic communication with me shall create a warranty of any kind. Under no circumstances should I be liable for direct, indirect, special, incidental, or consequential damages resulting from the use, misuse, or inability to use this software, even if I has been advised of the possibility of such damages.
I'm trying my best to make the software working, but I can't guarantee that it is free from defects.
All beta versions of this tool would be freeware. You may freely use it for your own, embed it into your tool, but you can't use it commercially without my confirmation. You can disassemble, analyze or modify this tool for yourself - later I'll provide SDK and document its internals. The only thing that is prohibited is changing embedded copyright notices. I reserve the right of making the project commercial, but this does not mean that this would ever happen.
This software contains unmodified binaries from the ReactOS project: a registry editor, cmd.exe, ole32.dll to name the few. Those binaries are left unmodified and are covered by LGPL license. Future versions may contain redistributable binaries provided by Microsoft and/or other companies.
Some more information may be found in my blog. If you want to support development - use the link or press the button on the left side of the post.11Changes:
15 may 2013: DInput and DInput8 changes for Fallout2 keyboard compatibility.
12 may 2013: A minor update. Fallout 2 now works, tested on Russian version from 1C.
01 may 2013: Added the ability to automatically launch x86 applications. Added the shell32 interfaces - so that installers now work (at least NSIS and InstallShield installers are known to be working).
05 apr 2013: Fixed a few bugs.
04 apr 2013: Uploaded a new build after a long delay. Now emulator supports 256-color modes. But due to a limitation on an updated Nvidia driver - 640x480 and 800x600 display modes are no longer supported on Windows RT. You'll see the black lines to the right and bottom of the screen if the program tries to set such mode.
25 feb 2013: The tool now outputs its version to log. Now one x86 program may launch another - so some of the installers and, for example, 7Z GUI frontend can now run under emulation. Added ~80 DLLs. Some of them are stubs (like D3D9.DLL), others are mostly untested. I have not done all that I've planned for this build, publishing it just as an update to show that the work is going on. Do not expect it to run much more than the previous build.
13 feb 2013: more informative errors from launcher. Emulator now supports program paths with spaces. EXE files with relocations are now processed correctly. Some bugfixes in kernel32 and advapi32.
11 feb 2013: fixed a typo in winmm.dll emulation, now pinball has sound. Also updated the launcher.
10 feb 2013: now the program reached the beta stage.
Known problems
No D3D and most of COM interfaces. Lots of programs would crash, don't run or have different issues.
Notes:
The program keeps its settings in the HKCU\Software\x86node\Settings registry key. Supported REG_SZ (string) values are:
DosboxCore: "dynamic", "simple" or "normal". Dynamic is the default as it is the fastest, but the most buggy core.
LogFile: path to the log file. If not present - log file is %temp%\win86emu.log
Supported REG_DWORD values:
LogLevel: 0=no log (default), 4=max logging
added 13 feb 2013: now default log level is 2: warnings+errors, so you don't need to edit registry
There are several compatibility hacks that may be useful. Compatibility settings are stored in HKCU\Software\x86node\Compatibility\[filename.exe] key. "filename.exe" - a name of the emulated EXE file without path. All values are DWORD:
SetProcessAffinityMask = bitmask. Specify which CPUs to use for running a program, read SetProcessAffinityMask description in MSDN. 0 or unset == run on all cores.
NoRaiseException = 1. RaiseException would just return. Now exceptions are emulated correctly, so this hack is no longer needed.
UseDirectRegistry = 1. Do not redirect emulated registry keys to HKCU\Software\x86node. Be careful when using it.
MaxProcessorFeaturePresent = max processor feature number that is "supported". See the IsProcessorFeaturePresent function in MSDN. All requests for the value above specified would return 0. Default: 0 (IsProcessorFeaturePresent always returns 0).
SimulateAdminRights = 1. Lie to installers that call OpenSCManager function to determine that it is running as administrator, allowing these programs to run without elevation. Redirect the "common start menu" and similar folders to the per-user folders.
You can fake the OS version to a running program. Default XP SP3:
OSVersionLo=dword:00000001
OSVersionHi=dword:00000005
OSVersionBuild=dword:00000a28
OSServicepackLo=dword:00000000
OSServicepackHi=dword:00000003
Some information on the project internals may appear in my blog: http://mamaich-eng.blogspot.ru, but this thread on XDA would be the main discussion place.3
It is better to port free download manager as is is opensource.
FDM may be compatible with some of the future versions, but there would be no internet explorer integration. I'm not going to support all those COM interfaces, at least in the foreseeable future.
I'll pause publishing updates for some time as I'm adding several dozens of new system DLLs to the emulator, and need to make them working before making them public. Ws2_32, msimg32 and other requested DLLs are among them. uTorrent 2.x is working now, though with some problems.
You may see it on the Screenshot
NSIS installers are working too (checked with 7Zip official installer), though they can't create shortcuts as I have not implemented that interface yet.3
Not exactly a port, it is a clean remake based on the old ideas.
The idea is very simple:
- a PE file loader (load files, process relocs, run TLS callbacks in an emulation mode). Support import loops (DLL A imports B while B imports A), ordinals, etc.
- a set of wrapper x86 DLLs (kernel32_stub.dll and so on) that "look like" the corresponding Win API functions for an emulated program:
- a 32-bit x86 emulation engine (currently 2 engines: from bochs and from dosbox, planning on adding my own) that intercepts the command "in eax,0xe5", determines which API is needed by a program and passes it to a handler.Code:#define DEFINE_FUNC1(name) \ static const ModuleDef str_##name={DLL_NAME,#name}; \ EXTERN_C DW STUB_EXPORT stub_##name(DW p1) \ { \ DW *p=&p1; \ __asm { mov eax,p } \ __asm { jmp f1 } \ __asm { mov eax,offset str_##name } \ f1: __asm { in eax,0xe5 } \ __asm { mov p,eax } \ return (DW)p; \ } ..... #define DEFINE_FUNC3(name) \ static const ModuleDef str_##name={DLL_NAME,#name}; \ EXTERN_C DW STUB_EXPORT stub_##name(DW p1,DW p2,DW p3) \ { \ DW *p=&p1; \ __asm { mov eax,p } \ __asm { jmp f1 } \ __asm { mov eax,offset str_##name } \ f1: __asm { in eax,0xe5 } \ __asm { mov p,eax } \ return (DW)p; \ } .... DEFINE_FUNC1(AddAtomA) DEFINE_FUNC1(AddAtomW) DEFINE_FUNC7(CreateFileA) -- number in macro == number of parameters to a __stdcall WinAPI function. Compiler automatically generates "ret N*4" at the end of such function. I've decided to use such c+asm approach instead of making a tiny assebler stub, as I can easily implement some of such functions in C directly in a stub DLL plus it simplifies debugging. And the functions have a usual C prologue/epilogue, so that the emulated program may even patch them in runtime, for example for hooks. ...
- native (arm) API handler DLLs (kernel32_yact.dll and so on). They are mostly autogenerated too:
Some of the functions require complex emulation due to their absence in ARM or due to the callbacks to x86 code:Code:#define DEFINE_FUNC1(name) \ EXTERN_C DW STUB_IMPORT name(DW); \ -- this behaves like a function prototype to compiler EXTERN_C DW STUB_EXPORT yact_##name(DW *R) \ -- R - pointer to the x86 stack { \ DW r=name(p1); \ // call the func passing it paramers from the emulated stack, p1==R[0], p2==R[1] and so on LEAVE(1); \ // empty macro, as the stack is unwinded in x86 stub DLL now return r; \ } ... #define DEFINE_FUNC3(name) \ EXTERN_C DW STUB_IMPORT name(DW,DW,DW); \ EXTERN_C DW STUB_EXPORT yact_##name(DW *R) \ { \ DW r=name(p1,p2,p3); \ LEAVE(3); \ return r; \ } ... DEFINE_FUNC1(AddAtomA) DEFINE_FUNC1(AddAtomW) DEFINE_FUNC7(CreateFileA) // as you see - implementation part is identical to an x86 stub, so I can use the same stub-generator tool
Some of the COM interfaces are already implemented, for example DirectDraw and DirectSound, though not heavily debugged. On a desktop emulator build I can already run "Heroes of might and magic 3" and old WinRAR, but there are several RT-specific OS limitations I need to bypass before making them run on ARM. Current work in progress is: overcoming the RT limitations, manually implementing the API functions that callback to a program code (like CreateThread, RegisterClassA and so on), adding stubs for other system DLLs/COM objects.Code:static DWORD WINAPI ThreadProc( LPVOID lpParameter // [0] == orig func, [1] == orig param ) { __EXCEPTION_REGISTRATION_RECORD R; DWORD *Parm=(DWORD*)lpParameter; DWORD *TEB=(DWORD*)PeLdrGetCurrentTeb(); R.Next=(__EXCEPTION_REGISTRATION_RECORD*)-1; R.Handler=(void*)CbReturnToHost(); TEB[0]=(DWORD)&R; // in case of unhandled exception - just return PeLdrNotifyNewThread(NULL,DLL_THREAD_ATTACH); DWORD Ret=EmuExecute(Parm[0],1,Parm[1]); // 1 == number of parameters to the emulated function delete Parm; return Ret; } EXTERN_C DW STUB_EXPORT yact_CreateThread(DW *R) { DWORD* Parm=new DWORD[2]; Parm[0]=p3; // TODO: no out-of-memory checking for now Parm[1]=p4; DWORD StackSize=p2; if(StackSize) StackSize+=1024*1024; // I reserve some space for my own needs (debugging) else StackSize=2*1024*1024; // TODO: I don't support autogrow stacks, so reserve 2 Mb DWORD t=(DWORD)CreateThread((LPSECURITY_ATTRIBUTES)p1,StackSize,ThreadProc,Parm,p5,(LPDWORD)p6); LEAVE(6); return t; }
Manually thrown SEH exceptions are fully supported, but access violation, int3 and similar OS-generated exceptions would cause program to crash. Some of the TEB fields (TLS and the fields required by the Borland compilers) are implemented too.
I don't make pointer translation in an emulated code nor make parameter checks passed to API. As a side-effect - the emulated program may trash the emulator in memory, but this greatly increases speed.
Most of the x86 EXE files don't contain relocations section and need to be loaded on the specific addresses (typically 0x400000). This is not a problem on a desktop, as I can rebase my emulator's EXE to any address I need, and free the corresponding RAM addrs for emulated program, but on ARM - this is a main problem. So currently only EXEs with relocs are supported for emulation, but there are ways to overcome this problem. And some EXEs produced by old Borland compilers contain "broken" relocs, this is a small problem too.
