With a few edits, \Masm32\examples\exampl01\qikpad\qikpad.asm can be transformed into a GUI for the DOS prompt, with the ability to copy & paste directly, and to save sessions:
include \masm32\MasmBasic\MasmBasic.inc ; line 12 - download here (http://www.masm32.com/board/index.php?topic=94.0)
; .386
; .model flat, stdcall ; 32 bit memory model
; option casemap :none ; case sensitive
...
Launch "cmd.exe", SW_MINIMIZE, cb:hEdit ; line 285: start the commandline interpreter, send output to edit control
...
; -------------- lines 609-615: send strings to cmd.exe --------------------
.elseif wParam == VK_RETURN
void Rinstr(Win$(hEdit), Chr$(62)) ; find the prompt
lea ecx, [eax+1] ; set ecx on start of string to send
.Repeat
inc eax
.Until byte ptr [eax]<=13 ; find end of string
WritePipe Left$(ecx, eax-ecx)
That's all - full source & exe attached.
Hi Jochen,
Very nice work :t Your tool can be used as a console replacement. Kindly, could you add an option to modify the console font?
i seem to recall a nice little editor written long ago
let me see - who wrote that - oh ! - it was Erol :shock:
Hi Dave,
My apologies, maybe I am wrong but I didn't code an editor. Maybe, that was the autotype example.
maybe it was Ketil :P
Good work Jochen. 8)
Quote from: Vortex on December 27, 2012, 05:56:52 AM
Hi Jochen,
Very nice work :t Your tool can be used as a console replacement. Kindly, could you add an option to modify the console font?
Hi Erol,
For the QikPad demo this would be an overkill, but I can offer a more advanced version that does have this option - see attachment, in the menu. Attention, work in progress - the usual disclaimers apply.
P.S.:
@Andy: This one has a history of 99 lines max., and you can store it to disk with Ctrl H; note that some commands need
start whatever.exe
@Frank: Thanks :biggrin:
now, if we could just figure out how to emulate for 16-bit programs :lol:
we could be rid of the console altogether
i have installed "PowerShell", but i haven't tested much code under it, yet
nice, Jochen :t
I have run into a problem:
The CmdGUI.exe posted above launches cmd.exe and then communicates with it through an anonymous pipe. That works like a charm, except that some commands behave strangely:
- all DOS commands seem to work fine (cd.., dir, ...)
- test.txt <enter> launches notepad
- notepad.exe <enter> shows strange behaviour:
1. it is launched, i.e. you can see it in task manager
2. but not visible
3. until you send one more command, e.g. echo ciao <enter>
Any idea what is the logic of that? Fumbling with CreateProcess DETACHED_PROCESS flag does not solve the problem...
weird :P
maybe the command shell is using ShellExecute instead of CreateProcess ???
Weird indeed. The new process, e.g. notepad.exe is already in the process list and uses memory, has page faults etc, but has not started execution. I tested that with a
.code
start:
<print something to a file>
Olly can't attach itself to the process, it tries but then hangs.
Same pattern for all windows GUI apps but apparently no problem for console apps. And services.msc or similar works directly.
Now perhaps this gives a clue:
start notepad.exe works.
I am pretty sure it's something very simple ::)
P.S.: No such problem in Win7-64 - everything works smoothly there...
My first guess would be that it's created as a child of the (hidden) cmd window, and inherets its handles and attributes as a result. For console processes, this is what you want - so the text is directed through the console and into your pipe.
Try playing with the values in STARTUPINFO.
Thanks, Tedd. I have been playing a while, no success in XP, but it just works fine on Win7-64...
AutoIt (http://www.autoitscript.com/forum/topic/12417-simple-gui-wrapper-for-cmdexe/)seems to have a similar problem:
QuoteSo, at the bottom of things, there's some disparity in the way that STDIN is handled for @COMSPEC /k depending whether it's spawned by the shell (a-la double-clicking a BAT file) or whether it's spawned from AutoIt
What is most annoying is that sending a second CrLf (or any other command, e.g. blabla) is sufficient to make the window show. Or type echo and hit Enter...
Hi Jochen,
Thanks for your work. Much appreciated. A last feature request : the option to select the font and background color.
maybe it's not the command execution, itself
maybe there are flags to play with when the pipe is created
hard to say, as it is somewhat buried in the masmbasic macros
i don't know if you use CreateNamedPipe or if you redirect standard handles
another possibility is the CMD.EXE window, as well
you may be using AllocConsole to create the console
it can also be created with CMD.EXE and a number of switches - some are pipe-related
C:\>cmd /?>cmd.txt
will get you a lot of text to read :P
Dave,
Programs Run Through Xp_cmdshell Have No User Interface (http://support.microsoft.com/kb/323411) tells a similar story:
QuoteIf you run a program through the xp_cmdshell extended stored procedure, the program only runs in the background. The xp_cmdshell extended stored procedure does not display the user interface of the programs that run in its context. If an application that is run through xp_cmdshell does needs user interaction from a user interface (for example, the application tries to create a dialog box or a message box that needs user input) it will stop responding because it is waiting for input. However, xp_cmdshell will never display the user interface; therefore, the user cannot provide any input.
That is confirmed by my tests: As soon as the GUI app has also a console (/Subsystem:Console), it pops up immediately. That does not explain, though, why
- launching notepad from the DOS prompt works fine
- an additional echo <Enter> in CmdGUI works, too
- start notepad.exe works.
@Erol: font colours will be added soon.
seems like one of the CreateNamedPipe flags addresses that
QuotePIPE_WAIT 0x00000000
Blocking mode is enabled. When the pipe handle is specified in the ReadFile, WriteFile, or ConnectNamedPipe function, the operations are not completed until there is data to read, all data is written, or a client is connected. Use of this mode can mean waiting indefinitely in some situations for a client process to perform an action.
PIPE_NOWAIT 0x00000001
Nonblocking mode is enabled. In this mode, ReadFile, WriteFile, and ConnectNamedPipe always return immediately. Note that nonblocking mode is supported for compatibility with Microsoft LAN Manager version 2.0 and should not be used to achieve asynchronous I/O with named pipes. For more information on asynchronous pipe I/O, see Synchronous and Overlapped Input and Output.
Dave,
Thanks, this looks interesting although some tests showed no change. Use start notepad for GUI apps...
In the meantime, I have polished the app and added the font & colour features. Hope it is useful for somebody.
Note that if some text is selected, only the selection will be saved with the Ctrl S feature. This is by design :biggrin:
Hi Jochen,
Once again, very nice work :t Many thanks.
Well done, Jochen. Thank you. :t
Gunther
Thanks, Erol and Gunther.
Attached version 3 offers a context menu (i.e. right-click popup) with the current history.
The format of the two dat files has not changed, so: if you saved your history or changed colours with the previous version, do NOT extract the dat files.
\Masm32\CmdGUI\CmdGUI.asc is the source in RichMasm (\Masm32\RichMasm\RichMasm.exe) format - work in progress, the usual disclaimers apply.
Version 4 of CmdGUI attached.
You may like autocompletion with TAB, e.g.
>t<TAB> displays all documents that start with t
>*.exe<TAB> displays all executables
etc
Again, if you saved your history or changed colours with the previous version, do NOT extract the dat files. Feedback on handling and design is highly welcome, of course.
Press F1 once CmdGUI is running to see a warning regarding executables that use inkey - they must be launched as start MyApp.exe
The usual disclaimers apply - use at your own risk bla bla.