1
1
Fork 0
mirror of https://github.com/pbatard/rufus.git synced 2024-08-14 23:57:05 +00:00
rufus/res/hogger/readme.txt
Pete Batard ae08fe3ac2 [misc] fix an issue with Far Manager
* Closes #161
* Also fix a couple warnings from MinGW and VS
2014-05-27 02:02:50 +01:00

69 lines
3.1 KiB
Text

Rufus: The Reliable USB Formatting Utility - Commandline hogger
# Description
This little utility is intended to solve the issue of Windows applications not
being able to be BOTH console and GUI [1], leading to all kind of annoyances [2].
The basic problem is as follows:
1. You have an awesome Windows UI application that you want your users to be
able to start from the commandline (to provide parameters, etc.)
2. If an application is set to operate in UI mode, then when you launch it from
the command line, you will NOT get a command prompt freeze until it exits, as
you'd expect from any console app, but instead the prompt will return to the
user right away.
3. This means that any message that you try to output from your app to the
console will appear as ugly as:
C:\Some\Directory> Some Application Message
4. Another unfortunate effect is that, when users exit your app, they might
continue to wait for the prompt to come back, when it is already available
whilst polluted by output that looks out of place => Your user experience is
now subpar...
5. To compensate for this, you might try to be (somewhat) clever, through the
simulating an <Enter> keypress when your app exit, but lo and behold, soon
enough you start receiving complaints left and right from Far Manager [3]
users, due to the fact that this application uses the <Enter> keypress as an
"I want to launch the currently selected app" event.
6. HEY, MICROSOFT, THIS SUPER-SUCKS!!!!
# Primer
So, how far do we need to go to address this?
1. We'll create a console hogger application, that does just what you'd expect
a regular commandline app to do (hog the console prompt until the app exits)
and wait for a signal (Mutex) from the UI app to indicate that it is closed.
2. We'll embed this console hogger as a resource in our app, to be extracted
and run in the current directory whenever we detect that our UI app has
been launched from the commandline
3. Because we want this annoyance to have the least impact possible, we'll
make sure that it is AS SMALL AS POSSIBLE, by writing it in pure assembly
so that we can compile it with NASM and linking it with WDK, leaving us
with a 2 KB executable (that will further be compressed to about 1/4th of
this size through UPX/LZMA).
# Drawbacks
The one annoyance with this workaround is that our 'hogger' will appear in the
command history (doskey). This means that when when a user wants to navigate
back to the command they launched, they need to skip through an extra entry,
which they probably have no idea about. And of course, doskey does not provide
the ability to suppress this last entry.
Oh, and you also need to release the mutex so that you can delete the file
before you exit, though that's not a big deal...
# Compilation
; From a WDK command prompt
nasm -fwin32 hogger.asm
link /subsystem:console /nodefaultlib /entry:main hogger.obj %SDK_LIB_DEST%\i386\kernel32.lib
# Links
[1] http://blogs.msdn.com/b/oldnewthing/archive/2009/01/01/9259142.aspx
[2] https://github.com/pbatard/rufus/issues/161
[3] http://www.farmanager.com/