Originally Posted by GoodDayToDie
[*]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.