• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

[Beta] Win86emu: Running x86 apps on WinRT devices

Search This thread

mamaich

Retired Recognized Developer
Apr 29, 2004
1,150
224
mamaich-eng.blogspot.ru
The 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://forum.xda-developers.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.
 

Attachments

  • changelog.txt
    1.8 KB · Views: 23,329
  • 0.061-ntdll.nt.dll.zip
    26 KB · Views: 54,195
  • Sources.7z
    5.5 MB · Views: 36,694
Last edited:

mamaich

Retired Recognized Developer
Apr 29, 2004
1,150
224
mamaich-eng.blogspot.ru
Changes:
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.
 
Last edited:

madamimadam

Senior Member
Jan 23, 2011
125
15
Atlanta
I don't have an ARM tablet to test this on, but this type of development is what will get me onto an ARM tablet for the next go-round. I love my S7S, but I really hated paying the price.
 

no2chem

Senior Member
Jul 18, 2007
276
102
I'm presenting a prototype of a tool that allows running Windows programs compiled for a desktop PC (x86) on an unlocked Windows RT (arm) tablet. The tool emulates x86 instructions and passes Windows API calls to WinRT kernel with necessary modifications.

This build is an early alpha version. It can run only very simple apps that use rather small subset of Win32 API that I've already implemented. Archive contains clock.exe from NT4 distribution as an example of such app. As I'll continue work on the project - the list of supported applications would grow up.

This tool would support only 32-bit windows native applications. It would not allow running drivers or .NET apps that were written for old .NET versions nor Win16 or DOS apps. And current version supports emulation only of EXE files that contain relocations section (this would be fixed later).

Instructions:
1. Unlock your device with this tool: http://forum.xda-developers.com/showthread.php?t=2092158
2. Unzip the archive to any directory
3. Run _start_clock.cmd
This would execute the clock.exe from NT4 in the emulation mode.

This post would be updated as I'll make more progress.

Note: This is an early alpha version, and do not expect that it would run anything except the provided file. Do not ask me what programs would be supported and when the next builds would appear - I don't know, as I work on this project only on spare time. I would not publish the complete sources of the tool, but it would be extensible by users, and some plugins (at least bochs/dosbox emulation engines and some of the API wrappers) would be opensource.
"Yact" in the file names stands for "yet another code translator", it was the original name of the project.

Edited 13.01.2012:
- added a few ARM WinAPI workarounds, added calc.exe as a second example (run _start_calc.cmd).

heh, is this a port of the app you showed off back in the CE days? -awesome getting that ported over
 

mamaich

Retired Recognized Developer
Apr 29, 2004
1,150
224
mamaich-eng.blogspot.ru
heh, is this a port of the app you showed off back in the CE days? -awesome getting that ported over
Not exactly a port, it is a clean remake based on the old ideas.
Would you mind giving a technical explanation?
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:
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.
...
- 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.
- native (arm) API handler DLLs (kernel32_yact.dll and so on). They are mostly autogenerated too:
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 functions require complex emulation due to their absence in ARM or due to the callbacks to x86 code:
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;
}
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.
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.
 
Last edited:

rheza02

Senior Member
May 20, 2006
482
12
HI mamaich, sorry for disturbing you, may i know how do you compile visual studio project for arm ?, i already change windowsarmdesktop to true. But i can't find arm options in build settings. Any suggestion ?
 

netham45

Inactive Recognized Developer
Jun 24, 2009
886
567
Denver
HI mamaich, sorry for disturbing you, may i know how do you compile visual studio project for arm ?, i already change windowsarmdesktop to true. But i can't find arm options in build settings. Any suggestion ?

This is completely unrelated to the topic and has been covered in at least 3 threads, multiple times in each, in the past couple days. Use the search function.
 

GoodDayToDie

Inactive Recognized Developer
Jan 20, 2011
6,066
2,931
Seattle
Wow, this is awesome work! While recompiling (for native speed, lower memory footprint, launch time, lower battery usage, script transparency, etc.) is still obviously preferred, this finally offers a way to run closed-source or otherwise un-recompilable legacy apps. Well done; I'll be watching this closely.

A thought for making it easier to run the apps (including the aforementioned script transparency): Windows (at least on x86 and x64, and I'm pretty sure on ARM too) supports specifying executable names that, when they would be executed, are instead passed as a parameter to another executable. This is usually used for testing or debugging purposes (for example, always load a given app under a debugger or have Application Verifier hook into it at launch) but it can be used for other purposes too. One, which would be fantastic here, is to always run a program through a compatibility layer... I've never before seen it used for a full instruction set translation compatibility layer, but why not?

Create the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<IMAGE FILE NAME>
i.e. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\starcraft.exe
Then create a REG_SZ (String) value under that key called "Debugger" and set the value to the full path of the program you want to host the executable.
i.e. C:\Program Files\x86_peldr\peldr.exe

Source: http://support.microsoft.com/kb/824344

I can't promise that this will work for executable images that wouldn't be loadable normally, but it's probably worth a shot. Another, slightly less seamless option: change the extension of the executables (for example, starcraft.ex86) and register your app as the handler for that file type.
 

netham45

Inactive Recognized Developer
Jun 24, 2009
886
567
Denver
Wow, this is awesome work! While recompiling (for native speed, lower memory footprint, launch time, lower battery usage, script transparency, etc.) is still obviously preferred, this finally offers a way to run closed-source or otherwise un-recompilable legacy apps. Well done; I'll be watching this closely.

A thought for making it easier to run the apps (including the aforementioned script transparency): Windows (at least on x86 and x64, and I'm pretty sure on ARM too) supports specifying executable names that, when they would be executed, are instead passed as a parameter to another executable. This is usually used for testing or debugging purposes (for example, always load a given app under a debugger or have Application Verifier hook into it at launch) but it can be used for other purposes too. One, which would be fantastic here, is to always run a program through a compatibility layer... I've never before seen it used for a full instruction set translation compatibility layer, but why not?

Create the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<IMAGE FILE NAME>
i.e. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\starcraft.exe
Then create a REG_SZ (String) value under that key called "Debugger" and set the value to the full path of the program you want to host the executable.
i.e. C:\Program Files\x86_peldr\peldr.exe

Source: http://support.microsoft.com/kb/824344

I can't promise that this will work for executable images that wouldn't be loadable normally, but it's probably worth a shot. Another, slightly less seamless option: change the extension of the executables (for example, starcraft.ex86) and register your app as the handler for that file type.

What I was thinking of for doing that was hooking the 'This doesn't run on this PC' error that explorer gives and making it call this instead of the error.
 

GoodDayToDie

Inactive Recognized Developer
Jan 20, 2011
6,066
2,931
Seattle
Nice... but that doesn't cover things like launching a program from the command line (script or manually), or one program launching another, or launching Windows services (although I'm not sure you'd want to emulate those anyhow... the battery hit would suck), or so on. Still an interesting goal.

One other thought for the "it'd-be-awesome" list (not even really a wish-list): support doing this for DLLs loaded into other processes (i.e. somehow get between LoadLibrary and the x86 binary, and interpose your translator). Why, you ask? Plugins. Browser plugins, media codecs (which are DLLs, whatever their extension), Control Panel files, COM objects in general, etc.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 93
    The 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://forum.xda-developers.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.
    11
    Changes:
    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
    Sorry for the long delay.

    AOE is already working in my private build. But there are some issues I have to resolve before publishing it.
    3
    I'm not at home...... somebody can try to install FDM ?

    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
    heh, is this a port of the app you showed off back in the CE days? -awesome getting that ported over
    Not exactly a port, it is a clean remake based on the old ideas.
    Would you mind giving a technical explanation?
    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:
    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.
    ...
    - 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.
    - native (arm) API handler DLLs (kernel32_yact.dll and so on). They are mostly autogenerated too:
    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 functions require complex emulation due to their absence in ARM or due to the callbacks to x86 code:
    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;
    }
    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.
    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.