[Beta] Win86emu: Running x86 apps on WinRT devices
- Thread starter mamaich
- Start date
Tried pinball and WinRAR, even mplayer and an awful lot more. Nothing at all will install for me.
All error related to ASLR issue. I'm sure it will be sorted.
On a side note I've just tried this:
http://www.engadget.com/2013/02/12/bluestacks-brings-official-surface-pro-optimized-android-app-pl/
It runs the extractor then nothing happens, how good would it be if it ran.
All error related to ASLR issue. I'm sure it will be sorted.
On a side note I've just tried this:
http://www.engadget.com/2013/02/12/bluestacks-brings-official-surface-pro-optimized-android-app-pl/
It runs the extractor then nothing happens, how good would it be if it ran.
Last edited:
This is already fixed, I'll post an updated launcher a bit later.
I agree with you, but this would require some internal redesign. The easiest method would be to open the log file automatically on crash, and to set LogLevel=1 by default.
Launcher is just a temporary solution. Later there would be automatic detection of x86 apps without a launcher and the programs would be run transparently to end-user. You'd be able to create shortcuts, and so on.
You can place shortcut to a launcher on the desktop. If you run it while it is already running - it would popup its window.
As far as I remember, image file execution options are applied after the OS checks for the file validity. I'll be using a different method to automate running of x86 EXEs.
You may use the following script to run a program passed as a parameter:
Code:
set EMU_PROGRAM=%1
:loop
"c:\program files\win86emu\peloader.exe" %2 %3 %4 %5 %6 %7 %8 %9
if %errorlevel%==3134193664 goto loopThere would be no problem launching executables that contain relocations information. But most of the old EXEs does not, so I'm using this trick:
This is exactly what I'm doing now. peloader.exe - is a tiny loader that reserves the memory at its start. It determines the program image base and image size and reserves the memory at that address. If the address is already used - it exits complaining about ASLR. Here I abuse ASLR for my own needs - at next program start OS would be using different addresses for its data (environment block and so on), so I usually can reserve needed memory at 1-2 restarts.
There is a bug in peloader. It reserves the memory for the whole EXE file size, including the overlayed data in its end. So self-extracting archives would require too much memory to be loaded successfully.
And just found another bug in it - EXE file relocations info check was turned off for debugging and I've forgot to turn it on. So all EXEs were processed as having no relocs.
I'll fix both bugs in the next update, it should be ready this evening.
Last edited:
Great! Thanks for the update.
Agreed on the option of just opening the log by default. It would also be somewhat nice to have an option to control the program's behavior from the UI, rather than manual registry editing, but as you say it's a temporary work-around.
I'm really curious how you're going to implement the auto-detection. The only thing that comes to mind is to use the debugger to hook CreateProcess (and possibly ShellExecute, but I think that calls CreateProcess anyhow) and add a bit of code that checks the architecture flag of the PE, loading the emulation layer if it's x86. That would be per-process, though; it would work for (example) explorer.exe, but not if I used explorer to start a CMD window. Of course, you could have a long-running process or Windows Service that would apply the hook automatically to new processes, but that's a pretty ugly way to do it and would impact battery life. Other options include modifying the system libraries (not a great plan, expectially since that means those libs cant be used at all without jailbreak), modifying the program loader in the kernel (would require kernel debugger or kernel-mode driver, which we don't have), or... not sure. Setting the loader as the default handler for all EXE files (and then simply invoking CreateProcess on ARM ones) doesn't work, for multiple reasons. Maybe something involving the system event logs? Anyhow, this would obviously be the ideal behavior.
Bleh, IFEO doesn't work for this. The architecture check is performed before the IFEO check. Lamesauce. A kludgy work-around would be to change the arch characteristic in the binary and *then* use IFEO...
Yeah, files without relocs are going to be a problem. It might save some time/hassle on those which aren't /FIXED but aren't /DYNAMICBASE either, though. Of course, that doesn't help if the check for relocs isn't used...
I should have been surprised how many programs I tested that were acting like they were /FIXED, but having seen professionally the kinds of compiler flags used by all too many programs, I wasn't...
Reserving only space for the .text and .data sections will certainly help dramatically, especially for programs with a huge amount of resources. Massive statically-linked programs might still be a problem but should be rare.
Looking forward to trying it out!
Agreed on the option of just opening the log by default. It would also be somewhat nice to have an option to control the program's behavior from the UI, rather than manual registry editing, but as you say it's a temporary work-around.
I'm really curious how you're going to implement the auto-detection. The only thing that comes to mind is to use the debugger to hook CreateProcess (and possibly ShellExecute, but I think that calls CreateProcess anyhow) and add a bit of code that checks the architecture flag of the PE, loading the emulation layer if it's x86. That would be per-process, though; it would work for (example) explorer.exe, but not if I used explorer to start a CMD window. Of course, you could have a long-running process or Windows Service that would apply the hook automatically to new processes, but that's a pretty ugly way to do it and would impact battery life. Other options include modifying the system libraries (not a great plan, expectially since that means those libs cant be used at all without jailbreak), modifying the program loader in the kernel (would require kernel debugger or kernel-mode driver, which we don't have), or... not sure. Setting the loader as the default handler for all EXE files (and then simply invoking CreateProcess on ARM ones) doesn't work, for multiple reasons. Maybe something involving the system event logs? Anyhow, this would obviously be the ideal behavior.
Bleh, IFEO doesn't work for this. The architecture check is performed before the IFEO check. Lamesauce. A kludgy work-around would be to change the arch characteristic in the binary and *then* use IFEO...
Yeah, files without relocs are going to be a problem. It might save some time/hassle on those which aren't /FIXED but aren't /DYNAMICBASE either, though. Of course, that doesn't help if the check for relocs isn't used...
I should have been surprised how many programs I tested that were acting like they were /FIXED, but having seen professionally the kinds of compiler flags used by all too many programs, I wasn't...Reserving only space for the .text and .data sections will certainly help dramatically, especially for programs with a huge amount of resources. Massive statically-linked programs might still be a problem but should be rare.
Looking forward to trying it out!
The same trick that is used by lots of tools on x86 windows. I'll hook CreateProcessInternalW in every running process except for WinLogon.exe and alike. This is easy - inject my DLL (OpenProcess, VirtualAllocEx, CreateRemoteThread), patch that function in memory, and do my stuff. But I'll patch only the "return error" part of the function - so that normal ARM executables would be run even if my hook would have heavy bugs or my DLL would be unloaded by some paranoid antivirus.
This would have minimal impact on battery life as I'll hook CreateProcessInternalW only when a new process is created. And I don't need to constantly monitor for new processes - WMI would notify me automatically, all other time my code would be sleeping.
Updated the first post with a new build. It supports spaces in file names (such file names should be in quotes). Now there is no console window of peloader.exe (recompiled it as a GUI app). EXE files with relocations and overlays are processed correctly. Launcher now opens log file if emulated EXE does not run. Now default Log level is "Warnings+Errors", so you'll get names of non-present DLLs in log without having to edit registry. And of cause there are some bugfixes in API emulation.
No new emulated WinAPI DLLs added yet, this would be done later, as I'm rewriting a stub generator to simplify their development.
I use relocations only in EXE files compiled for windows 2000 and above (OS == 5.0 in PE header). Some executables targeted for 4.0 have broken relocs - Heroes of Might and Magic 1 as an example.
Last edited:
Ah, I'd forgotten about WMI. My bad. Yeah, that method should work well.
Time to see if the improved peloader lets me run some of the files that always failed before...
EDIT: Well, they fail differently now. The ASLR problems are gone, as expected. However...
MSIMG32.dll appears to be required for all GOG.com installers.
DPLAYX.dll required for Total Annihilation.
WININET.dll required for Irfanview installer.
Tons of installers fail with a popup messagebox "NSIS Error: Error launching installer".
Lots of games demand opengl, no surprise.
MSVCP80.dll required for FTL.
Some programs (such as Baldur's Gate) just fail mysteriously ("... exit code 0" but nothing happened, sometimes exit code 1 or 2 instead for other programs).
Many programs (typically installers, sometimes standalone) fail with "The system cannot find the path specified"
Running programs over the network using UNC paths (\\servername\share\path\to\file.exe) acts like it will work, but copying locally works better in some cases (i.e it errors sooner over the network).
Time to see if the improved peloader lets me run some of the files that always failed before...
EDIT: Well, they fail differently now. The ASLR problems are gone, as expected. However...
MSIMG32.dll appears to be required for all GOG.com installers.
DPLAYX.dll required for Total Annihilation.
WININET.dll required for Irfanview installer.
Tons of installers fail with a popup messagebox "NSIS Error: Error launching installer".
Lots of games demand opengl, no surprise.
MSVCP80.dll required for FTL.
Some programs (such as Baldur's Gate) just fail mysteriously ("... exit code 0" but nothing happened, sometimes exit code 1 or 2 instead for other programs).
Many programs (typically installers, sometimes standalone) fail with "The system cannot find the path specified"
Running programs over the network using UNC paths (\\servername\share\path\to\file.exe) acts like it will work, but copying locally works better in some cases (i.e it errors sooner over the network).
Last edited:
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.
Last edited:
My vivotab rt is being delivered today. So, forgive me for my question. Will this allow starcraft (the original) to run? Please don't kill me.
As far as I can tell yes, but not yet and maybe not ever at the speeds required to play properly. Lots of dlls would need implementing etc...
I'll be honest, SC is on my list as well. The current version doesn't support it though, so I can't say.
The minimum requirements are ludicously low: Pentium chip, 90 MHz. That's actually within reach for the x86 dynamic recompiler; we *might* already be there.
The bigger problem is the legacy compatibility. SC is better than a lot of other games from its era becuase it was actually written to support running on NT (most games from 98 - yes, SC has been out for 15 years now - only ran on 9x) but it still uses a ton of APIs that have been deprecated over the years. It's quite likely that RT doesn't provide at least one of its dependencies. Hell, ever since WIndows 2000, it's had occasional problems with graphics weirding out; Vista and later have freeze problems due to a bug in the compatibility layer used for supporting the ancient DirectX version SC is written for. If you look at Task Manager while it's running, you'll see there's also a program called CompatibiltyLayer.exe (or similar) running as well; RT almost certainly doesn't have that.
I remain hopeful, though. I don't expect this to run Supreme Commander or EVE Online (at least not playably), but Total Annihilation and StarCraft are possible.
The minimum requirements are ludicously low: Pentium chip, 90 MHz. That's actually within reach for the x86 dynamic recompiler; we *might* already be there.
The bigger problem is the legacy compatibility. SC is better than a lot of other games from its era becuase it was actually written to support running on NT (most games from 98 - yes, SC has been out for 15 years now - only ran on 9x) but it still uses a ton of APIs that have been deprecated over the years. It's quite likely that RT doesn't provide at least one of its dependencies. Hell, ever since WIndows 2000, it's had occasional problems with graphics weirding out; Vista and later have freeze problems due to a bug in the compatibility layer used for supporting the ancient DirectX version SC is written for. If you look at Task Manager while it's running, you'll see there's also a program called CompatibiltyLayer.exe (or similar) running as well; RT almost certainly doesn't have that.
I remain hopeful, though. I don't expect this to run Supreme Commander or EVE Online (at least not playably), but Total Annihilation and StarCraft are possible.
Please help. I accidentally chose ie when it asked for which type of file to run. In android I can wipe out default. Don't know what to do with windows.
In an effort to curtail the sudden deluge of "what can I run?/Why can't I run.../It doesn't work!" posts on here (which I admit I may have contributed to), it may help to start up a second thread for win86emu app compatibility. Leave this thread for development and bug reports. Use the other thread to list compatible apps and help people solve incompatibilities, and to give people a place they can request support for certain DLLs or entire apps.
I could create this thread if you wish, although the "ported apps" thread already takes up a noticeable amount of time what with testing things.
I could create this thread if you wish, although the "ported apps" thread already takes up a noticeable amount of time what with testing things.
Would it be possible to support The Sims 1/2 in the future?
HTML:
[092DF098]W: 051B0000-05201000 : D:\The Sims 1\IMM32.dll
[092DF0A7]E: Import User32InitializeImmEntryTable not found in C:\Program Files\win86emu\System32\USER32.86.dll
[092DF0A7]E: Import WCSToMBEx not found in C:\Program Files\win86emu\System32\USER32.86.dll
[092DF0D6]W: 05210000-05214000 : D:\The Sims 1\API-MS-Win-Core-LocalRegistry-L1-1-0.dll
[092DF0E6]E: PeLdr can't open file: API-MS-Win-Security-Base-L1-1-0.dll
[092DF0E6]E: Import dll API-MS-Win-Security-Base-L1-1-0.dll not found
[092DF0E6]E: Import dll IMM32.dll not found
[092DF0F6]E: Error loading program: 1168
[092DF0F6] Logger unloadedSimilar 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.
