RunAsX86, a tool to run AnyCPU .NET applications in X86 mode

Please let our ADS show!

This sites offers only FREE software and it’s supported by a few advertisement boxes (no intrusive popups).
Please:

• disable your AdBlocker by adding CoolSoft website to whitelist
• give the proper cookie consent
• enable JavaScript for this website

This seconds wait is to let you update your browser configuration.

When compiling a .NET application you have three available choices for the Platform target parameter:

X86: The code will run in 32bit mode both on x86 and on x64 OS.

X64: Executable will run only in 64bit mode and on x64 OS, no way to run it on x86 OS.

AnyCPU: The same executable will run in 32bit mode on x86 OS and in 64bit mode on x64 OS. It’s up to the .NET framework runtime to choose how to JIT compile it to native code.

Most of the times programmers choose the latter, because this way an application is flexible and runs everywhere.

But what if you need to force an app to run in X86 mode (i.e. it needs to interface with a 32bit only driver)?
The best way is to recompile it choosing X86 as platform target, but if you don’t have the sources you’re out of the game.

There’s a lot of documentation on the NET on how to patch an existing EXE to make it run in X86 mode, and all of them require an utility called CorFlags.exe.
The sad part is that this utility is only available within the Platform SDK (hundreds of MB for just a few KB tool. ).

That’s why I wrote RunAsX86, a really small wrapper, based on the original idea of Gabriel Schenker, to (try to) run a .NET AnyCPU application in X86 mode.
It must be compiled in AnyCPU mode and when run, it loads your .NET application into its 32bit process then starts it.
These are the changes I made:

• added a dialog for EXE file selection
• better error handling
• better command line parameters handling
• removed null reference exception

To run a .NET application in X86 mode, copy RunAsX86.exe into the folder that contains your .NET executable, then simply run it and choose your .NET exe.
If you need to pass some command line parameters to the application, open a command prompt then type:
RunAsX86 filename.exe param1 param2 .

Download RunAsX86 here.

Source code

/// Print usage infos ///

Comments

I clicked on your download

I clicked on your download link for this application, but got nothing but this webpage that says «page not found», where is this download?

Link fixed

Download link now fixed, thanks for your feedback.

ExecuteAssembly

Using AppDomain.CurrentDomain.ExecuteAssembly(..) is better solution than looking for entry point of the assembly.

ERROR: can’t find valid entry point

server2008 x64 — net cmdline exe — ERROR: can’t find valid entry point

This wrapper works only for

This wrapper works only for .NET executables.

What exe are trying to run?
Can you please write the whole command line?

How to Open and Run 32-bit Command Prompt in 64-bit (x64) Window

How to Open and Run 32-bit Command Prompt in 64-bit (x64) Windows

64-bit or x64 version of Windows operating system such as Windows Server 2003, Windows XP Professional x64 Edition, Windows Vista and Windows Server 2008 uses the Microsoft Windows-32-on-Windows-64 (WOW64) subsystem layer to run 32-bit programs, binaries or drivers without modifications, change or transition to 64-bit based binaries, as the 64-bit OS is optimized to run native 64-bit programs and does not provide support for 16-bit binaries or 32-bit drivers.

To reduce compatibility issue and prevent a 32-bit program from accidentally accessing data from 64-bit application, WOW64 subsystem isolates 32-bit binaries from 64-bit binaries by redirecting registry calls and some file system calls. Other than separate registry hive for WOW64 redirected 32-bit values, %systemroot%\System32 and Program Files folder is designated as 64-bit DLLs only too, and all access or I/O of 32-bit binaries been redirected from %windir%\System32 folder to the %windir%\SysWOW64 folder, and from Program Files to Program Files (x86) directory.

The command prompt (cmd.exe) is also affected by File System Redirection feature, where command line commands or .bat and .cmd batch script may not be able to access, install, change, modify, delete or write to “Program Files” or “%windir%\System32″ folder. The WOW64 subsystem redirects and installs 32-bit programs in the “Program Files (x86)” and “%systemroot%\SysWOW64″ folder.

To access the correct folder, programmer or developer must change the command-line script, or using Sysnative virtual directory alias to access %windir%\System32 instead of %windir%\SysWOW64. When this is not possible, or when have to access original native Program Files folder, user can type the command-line script at a 32-bit command prompt. The 32-bit command prompt automatically redirects file system calls to the correct 32-bit directory.

To start and open a 32-bit command prompt, follow these steps:

Click Start.
Type %windir%\SysWoW64\cmd.exe in Start Search box.

Alternatively, press Win + R keys (or type Run in Start Search) to open Run dialog, and type %windir%\SysWoW64\cmd.exe.
Press Enter.

32-bit Command Prompt

In 32-bit command prompt, the %programfiles% path variable will point to Program Files (x86) folder which stores all 32-bit binaries.

Install and Run 32-bit Programs on 64-bit Windows 7/8 and 10

Most of the time you will be having the 64-bit version of Windows 8.1 or Windows 10 (sometimes Windows 7 as well) if you have purchased the computer recently. If you have a program/app that is 32-bit, how to install 32-bit programs on 64-bit Windows? Follow this simple guide.

The truth is, the latest Windows 64-bit versions support 32-bit of application nicely without any issues. You can install and use them. But remember, you can’t install the 64-bit Programs on 32-bit Operating System like Windows 7 32-bit.

Run 32-bit Programs on 64-bit Windows

When you install the 32-bit application on 64-bit based OS, it creates a separate folder in root drive, called ‘Program Files (x86)’ and copy the all files required to run the program. So next time when you open the 32-bit program it accesses the executable program file from Program Files (x86) folder and runs without any issue with 64-bit Windows 7.

Also, 32-bit programs system files are installed into C:\ \WINDOWS\ \SysWOW64,

and registry keys are placed under HKEY_LOCAL_MACHINE\ \Software\ \WOW6432Node of 32-bit programs.

How to Identify the Version of the Program (64 or 32-bit) in Windows

You can identify the type of the programs by the location of the executable folder. If it placed under the 32-bit version of Program folder, then it is a 32-bit version of the program, another one is the 64-bit version on a 64-bit Windows OS.

Also, the task manager is another great place where you can find the version of the running programs. Open the task manager and click on the Processes where you are can see the all processes related to currently running programs. On 64-bit OS (in my case it is Windows 10), the 32-bit programs shown below. Other ones (which doesn’t have 32 Bit) are 64-bit applications on the computer.

In some cases, you may need to run the 32-bit version of applications/tools without installing them. Usually double-clicking the EXE file will open the application without any issues. If you face any issues, you can move these EXE files to Program folder inside Program Files (x86) folder in your root drive, then create a shortcut to the desktop to execute the program whenever wanted.

Hope this guide is useful to some extent to install and use 32-bit Programs on 64-bit Windows 7/8 and 10.

Running x86 programs in x64 windows

This is Hangover, a project started by Stefan Dösinger and André Hentschel to run x86_64/x86_32 Windows applications on aarch64/ppc64le/x86_64 Wine.

We have one Wine on the host in 64-bit only mode and two on the guest side for 64-bit and 32-bit. Inbetween sits a modified version of Qemu that runs the x86(_64) code. To glue it all together there are thunks, lots of them handwritten to understand in which situation a pointer is valid and in which situation it could point to a random address and should be ignored, and how to handle writes to resulting structures in case of errors etc.

Hangover currently runs a small number of 32 bit and 64 bit Windows applications. A list of applications the authors have tested is listed below. Other applications may work, but don’t expect too much. Direct3D is working if you have a host OpenGL implementation that supports regular desktop GL. Wine’s d3d implementation currently does not support OpenGL:ES well enough to be usable. Once this changes, Hangover will support it without any changes.

Debugger support is nonexistent and exception handling has known bugs. Due to these reasons copy protection and anti-cheat systems are likely to be in worse shape than in reguar Wine.

You can generally expect 64 bit applications to be in better shape than 32 bit applications because no data structure thunking is necessary.

3) Host system requirements

Hangover is tested on aarch64 Linux, ppc64le Linux, x86_64 Linux and x86_64 MacOS. No Intel x86 libraries are needed on the host system. No 32 bit multilib is required.

To build this project you need:

• The dependencies to build a 64 bit Wine (./configure —enable-win64)
• The dependencies to build qemu (in particular glib)
• x86_64-w64-mingw32-gcc (exactly this name)
• i686-w64-mingw32-gcc (exactly this name)
• About 5gb of disk space

Also make sure you have the submodules set up:

4.a) Linux / MacOS build:

In theory everything should be built by running make . In practise you’ll probably run into some bugs in our build system. Parallel builds should work, but if they fail try a non-parallel one first.

Some 32 bit programs and DLLs built with mingw depend on libgcc_s_sjlj-1.dll . You can symlink the DLL from your mingw installation to build/qemu/x86_64-windows-user/qemu_guest_dll32 .

4.b) Android build:

Not supported anymore, please use Hangover 0.4.0 on Android.

or in case wine64 is not built as on most supported platforms:

Wine’s programs can be found in build/wine-guest64/programs/* and build/wine-guest32/programs/* . build/wine-[guest64|guest32]/ also contain PE builds of Wine’s tests.

Don’t expect this to be fast. The main bottleneck at the moment is the speed of the code qemu generates from the input x86 code. To provide a rough comparison, my Nvidia Shield Android TV device (running a regular desktop Linux, not Android) runs games from the late 1990s to early 2000s at playable speed. The DirectX 9 SDK samples run fairly well because they contain little logic of their own and just call out of the VM into d3d, so all the heavy lifting is done natively. Warhammer 40k: Dawn of War starts a fresh game at around 30 fps but slows to a crawl as soon as a few units are built.

7) 32 bit guest support

The host Wine is always built as a 64 bit application. Hangover handles 32 bit applications by translating structures passed between the application and Wine. The LLP64 model of Windows keeps most structures compatible between 32 and 64 bit, but translating is still a big effort.

The address space is limited to 4 GB by reserving every address below 4 GB, then calling mmap to reserve remaining space until we run out of free address space and then freeing up the bottom 4 GB again. Most host Wine libraries are loaded earlier above 4 GB to keep the previous space below 4 GB as free as possible. The drawback of this is that starting a new process takes about 2 seconds.

Wine sees every process as a 64 bit process, so its WoW64 layer is not active. This will work OK for pure 32 bit or pure 64 bit applications, but it will cause problems for mixed applications that expect a distinction between e.g. C:\windows\system32 and C:\windows\syswow64.

8) 16 bit guest support

Support for Win16 does not yet exist, but should be possible by using Wine’s regular Win16->Win32 thunks and taking it from there. Some changes to the way Wine sets up 16 bit protected mode segments will be needed.

For vm86 (DOS) support install dosbox on your host. Wine will call it for you.

9) 32 bit host support

Support for 32 bit host systems is not implemented. It should not be hard to do, but you will probably have to put some effort into making sure the address space layout works OK and the load address of the main .exe file remains free until qemu loads it. There’s initial work for arm32 already.

10) Porting to other host architectures

Porting to little endian host architectures should be fairly simple. You will have to replace a few bits of host specific assembler code. The compiler will make you aware of those places through #error statements in ifdef guards.

If you want this to work on big endian platforms forget about it. It would require converting every Win32 structure, not just those with pointers or pointer sized integers in it. It will not happen.

11) Tested applications

This is a list of applications the authors tested. There is hope that they will work for you as well. If an application is marked as «installer: no» that means that the installer doesn’t work for some reason. You’ll have to install it elsewhere and copy the directory and registry keys.

• Notepad++: Works, Installer untested
• ANNO 1602: Runs with good performance, installer does not work. Videos may cause crashes
• Age of Wonders: Installer works, but 1.36 update does not install. Game version 1.36 works
• Warhammer 40k: Dawn of War: Game works, installer intested. Too slow to be playable
• The Settlers II 10th Anniversary: Installer works, updater works, game runs but is too slow to be playable. Needs native d3dx9 and d3dcompiler libs.
• Prince of Persia 3D: Installer and update work, game is playable.
• Worms 2: Installer fails because it needs Win16, game is playable. Game needs Audio CD support, otherwise it will complain that it doesn’t find the CD.
• Worms Armageddon: Works with the right Wine settings. Despite having the same graphics as Worms 2 it is noticeably slower but borderline playable.

Known not to work:

• StarCraft: Breaks because 2GB address space limit is not respected.
• Age of Empires 2: Extended exception information missing.

12) Running «make test» in Wine

To run Wine’s tests inside Hangover you can use scripts/hangover-test.sh as $WINETEST_WRAPPER. You also have to create an empty file server/wineserver (just touch it, it doesn’t need anything special) to make Wine’s tools/runtest happy. See comments in scripts/hangover-test.sh for more details

For anyone interested, ways to support at least André can be found here: