mirror of https://github.com/pbatard/rufus.git
70 lines
3.1 KiB
Plaintext
70 lines
3.1 KiB
Plaintext
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/
|