OS/2, eCS & ArcaOS - Technical > Programming
problems programming a new text window for cmd.exe/4os2.exe
Martin Vieregg:
One year ago, I wrote about my desire to get a substitute for the limited VIO window when using cmd.exe or 4os2.exe without 8000 character limit and with all editor functionality.
https://www.os2world.com/forum/index.php/topic,1859.msg18588.html#msg18588
The last year, I was very busy with other things, but meanwhile I began to program. I am the author of ME Editor and other editors. The editor is an OOP (wdsibyl) project where I can easy manage modifications.
I managed now to excute the original cmd.exe with pipes for stdout, stdin and stderr. The basic input/output functionality works already. But I need your help with some sophisticated problems.
The editor gets first executed, starts the pipes and executes cmd.exe in the background via
cmd.exe /K >outpipe 2>errorpipe <inpipe
For specific commands like mode, cls the commands will be interpretated by the editor and not cmd.exe, or gets interpretated by both. The current directory will be hold both in the editor and in cmd.exe. I will manage to turn the 4os2 escape codes into colors. All these things seem to make no problems to program (all not programmed yet).
But for three problems I have no solution yet:
(1) While cmd.exe is busy, the editor has to turn into read-only mode. The time period begins with an <ENTER> after typing the command, so the editor knows this moment. But when is the job finished and cmd.exe turns to idle state, the editor should turn to read/write and should accept the next command. I have no idea how the editor can get the information that cmd.exe is in idle state again.
A dirty solution would be to wait for [C:\] or a simular string. But this is not possible. And this is the next problem.
(CHANGED: Problem (2) is non-existant. It was a bug in my editor code.)
(2) A stdout output of cmd.exe waits until the line is finished with an carriagereturn. This has got a strange effect to my program: When starting the program, I do not see [C:\] at the moment. Then I type my command, e.g. "dir", press ENTER and the editor shows the "dir" output. But the last line with the command prompt [C:\] is not shown. It is only shown after entering the next command. Programs with an success indication with dots ...... are invisible while exeuting and waiting. So my question is: Is it possible to force stdout output in cmd.exe when the line is not terminated by a carriagereturn? Or do you have another idea how to sailing round the problem? The only idea for me at the moment is to simulate this output by adding a prompt and to swallow the first line output. Not a pretty solution. And the success dot problem is still not solved.
(3) Not all textmode programs do write into stdout, but there is text output shown nevertheless. This output gets shown in the hidden cmd.exe VIO window and not in my editor window. Can someone explain what this means and perhaps how to get this text in stdout nevertheless?
Pete:
Hi Martin
For problem 1 could you not start a thread to execute cmd.exe and monitor that thread? - DosCreateThread, DosWaitThread maybe...
Regards
Pete
Rich Walsh:
--- Quote from: Martin Vieregg on December 30, 2019, 01:02:08 am ---(3) Not all textmode programs do write into stdout, but there is text output shown nevertheless. This output gets shown in the hidden cmd.exe VIO window and not in my editor window. Can someone explain what this means and perhaps how to get this text in stdout nevertheless?
--- End quote ---
A VIO window is not a virtual TTY device. It's an emulation of a full-screen text mode session. In these sessions, the screen is accessed via the Vio API functions which can write anywhere on the screen independent of stdout/stderr. When an application like cmd.exe wishes to write stdout/stderr to the screen, it probably uses an internal version of VioWrtTTY().
To capture Vio API output, you would need access to the actual screen buffer used by full-screen apps or the virtual screen buffer used by VIO windows. Unfortunately, these buffers belong to other processes, so your app has no way to get at them.
Martin Vieregg:
Meanwhile, I have changed the first post: Problem (2) was my failure. The editor has read the input data line by line. This is now fixed.
Problem (3): I remember that in former times, I have programmed text applications where I used a "goto" command. Of course this is not stdout. I fear that this is a general limitation of my program. Perhaps I can add a list of these programs and then a conventional VIO window gets started, or I define a command /VIO where the user can start a VIO window in a command.
Problem (1): Wenn running cmd.exe in a thread (I have got already an input thread in my editor because waiting for input blocks the process), I still have no access to cmd.exe. But it would be possible to restart cmd.exe for every command the user types into the editor in a specific execution thread. While cmd.exe is running, the thread is frozen, and after finishing cmd.exe, the thread code continues. This could be a clean solution. The current directory is only hold in the editor and every time I execute cmd.exe, I have to hand over the current directory. But this should not be a problem.
Neil Waldhauer:
I think Vio output is not defined for a larger screen window. So to really do this right, you would need to extend the Vio family. But if some programs write to the buffer themselves, you would need to monitor that, too.
Both of these things could be done by code inserted into the program's space using the registry entry User->SYS_DLLS->LoadPerProcess. You write your code into a DLL and gain control using the DLL initialization code.
Navigation
[0] Message Index
[#] Next page
Go to full version