[*]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).
This is already fixed, I'll post an updated launcher a bit later.
[*]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).
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.
[*]Rather than using the system tray, why not just have the launcher sit in the taskbar? That's a lot more touch-friendly.
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.
[*]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.
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:
"c:\program files\win86emu\peloader.exe" %2 %3 %4 %5 %6 %7 %8 %9
if %errorlevel%==3134193664 goto loop
3134193664 == 0xBAD00000, a restart indicator
[*]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.
There would be no problem launching executables that contain relocations information. But most of the old EXEs does not, so I'm using this trick:
[*]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.
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.
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.
I'm really curious how you're going to implement the auto-detection.
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.
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).
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.
Smartphones are pretty high maintenance devices. No matter how impressive the spec sheets … more
XDA Developers was founded by developers, for developers. It is now a valuable resource for people who want to make the most of their mobile devices, from customizing the look and feel to adding new functionality. Are you a developer?