Author Topic: problems programming a new text window for cmd.exe/4os2.exe  (Read 38704 times)

Martin Vieregg

  • Sr. Member
  • ****
  • Posts: 278
  • Karma: +2/-0
    • View Profile
problems programming a new text window for cmd.exe/4os2.exe
« on: December 30, 2019, 01:02:08 am »
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?
« Last Edit: December 30, 2019, 10:44:58 am by Martin Vieregg »

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
Re: problems programming a new text window for cmd.exe/4os2.exe
« Reply #1 on: December 30, 2019, 01:43:49 am »
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

  • Sr. Member
  • ****
  • Posts: 331
  • Karma: +23/-0
  • ONU! (OS/2 is NOT Unix!)
    • View Profile
Re: problems programming a new text window for cmd.exe/4os2.exe
« Reply #2 on: December 30, 2019, 08:38:53 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?

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

  • Sr. Member
  • ****
  • Posts: 278
  • Karma: +2/-0
    • View Profile
Re: problems programming a new text window for cmd.exe/4os2.exe
« Reply #3 on: December 30, 2019, 11:18:29 am »
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

  • Hero Member
  • *****
  • Posts: 1024
  • Karma: +24/-0
    • View Profile
    • Blonde Guy
Re: problems programming a new text window for cmd.exe/4os2.exe
« Reply #4 on: December 30, 2019, 03:50:33 pm »
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.
Expert consulting for ArcaOS, OS/2 and eComStation
http://www.blondeguy.com

Rich Walsh

  • Sr. Member
  • ****
  • Posts: 331
  • Karma: +23/-0
  • ONU! (OS/2 is NOT Unix!)
    • View Profile
Re: problems programming a new text window for cmd.exe/4os2.exe
« Reply #5 on: December 30, 2019, 06:01:34 pm »
User->SYS_DLLS->LoadPerProcess

This only applies to PM apps. None of the DLLs listed in SYS_DLLS are loaded into VIO apps.

Bogdan

  • Jr. Member
  • **
  • Posts: 93
  • Karma: +1/-0
    • View Profile
Re: problems programming a new text window for cmd.exe/4os2.exe
« Reply #6 on: December 30, 2019, 11:44:20 pm »
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.
This may only work for programs that don't use the following calls:
  • KbdRegister, KbdDeRegister
  • MouRegister, MouDeRegister
  • VioRegister, VioDeRegister, VioGetFont, VioSetFont, VioGetPhysBuf, VioGetState, VioSetState, VioModeUndo, VioModeWait, VioSavRedrawUndo, VioSavRedrawWait, VioScrLock, VioScrUnLock
Most likely, session management calls are affected also.

Alex Taylor

  • Sr. Member
  • ****
  • Posts: 387
  • Karma: +5/-0
    • View Profile
Re: problems programming a new text window for cmd.exe/4os2.exe
« Reply #7 on: January 01, 2020, 02:56:06 am »
Maybe a dumb question, but have you taken a look at KShell?  If I understand what you're describing, KO seems to have done something similar there.
http://hobbes.nmsu.edu/h-viewer.php?dir=/pub/os2/util/shell&file=kshell081.zip

Martin Vieregg

  • Sr. Member
  • ****
  • Posts: 278
  • Karma: +2/-0
    • View Profile
Re: problems programming a new text window for cmd.exe/4os2.exe
« Reply #8 on: January 02, 2020, 01:27:24 pm »
kshell has no editor functionality. The main interest is to have full editor functionality, to resize the window and having an endless buffer to restore old outputs.

Meanwhile, the basic functionality works. I want to implement now colors with ESC codes. Where is a documentation about VIO ESC codes?

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: problems programming a new text window for cmd.exe/4os2.exe
« Reply #9 on: January 02, 2020, 04:37:25 pm »
They're just standard ANSI colour codes and seem to work the same on most all platforms so should be lots of documentation around, just search for ANSI Escape Code.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: problems programming a new text window for cmd.exe/4os2.exe
« Reply #10 on: January 02, 2020, 04:46:05 pm »
Have you looked at x86sup.sys ftp://ftp.netlabs.org/pub/xfree86/sources/xf86sup.zip ? It allowed creating PTTY's and TTY's and was used for the xterm in XFree/2. Unluckily it is a device driver, guess needed to be to access the VIO buffer.

Martin Vieregg

  • Sr. Member
  • ****
  • Posts: 278
  • Karma: +2/-0
    • View Profile
Re: problems programming a new text window for cmd.exe/4os2.exe
« Reply #11 on: January 08, 2020, 10:12:46 pm »
Meanwhile, I could program the basic functionality. It basically works fine already. I needed to program several threads: One for stdin, one for stderr, one for cmd.exe itself. stdout commands (the commands the user enters) are sent via main thread. It was only a few hundred lines of new code, but very tricky and nervy. It works now both with cmd.exe and 4os2.exe. Colors are already working. The problem with the unknown output end of a cmd.exe command is not a real problem. The user always can enter input while cmd.exe output is running but that doesn't matter because noone will do so. The problems above are solved. The next jobs is to implement a selection of editor functionality which I have already programmed for ME Editor which will be quite easy.

But I didn't manage to send a Ctrl-C character/message to cmd.exe to stop execution of a current command output. I tried ASCII #3 and ESC[Cm and ESC#3. Any idea how to send the break command to cmd.exe /4os2.exe? Has anyone studied the 4os2 source code?

Then I wonder if the fine working command to execute cmd.exe via my program
program: 'cmd.exe'
parameters: '/C cmd.exe /K <\pipe\mshelloutpipe >\pipe\mshellinpipe 2>\pipe\mshellerrpipe"

which starts cmd.exe twice is really necessary. Any ideas? Can I use pipenames in the OS/2 STARTDATA structure?

Andreas Schnellbacher

  • Hero Member
  • *****
  • Posts: 827
  • Karma: +14/-0
    • View Profile
Re: problems programming a new text window for cmd.exe/4os2.exe
« Reply #12 on: January 09, 2020, 12:54:10 am »
But I didn't manage to send a Ctrl-C character/message to cmd.exe to stop execution of a current command output.
Not knowing any details, I can only say that there exists something. The EPM command line window uses SUE_break of ETKR603.DLL. Unfortunately it's closed source. Other functions are SUE_new, SUE_free, SUE_write, SUE_readln. I don't even have a clue what 'SUE' means.

After having found a function, you probably have to assign a key def for Ctrl+Break (and Ctrl+C) to that, either WM_Char or accelerator.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: problems programming a new text window for cmd.exe/4os2.exe
« Reply #13 on: January 09, 2020, 01:17:15 am »
Wonder if sending a SIGINT would work? That's what CTRL-C sends in most operating systems. SIGBREAK for CTRL-Break

Laurence Pithie

  • Jr. Member
  • **
  • Posts: 62
  • Karma: +1/-0
    • View Profile
Re: problems programming a new text window for cmd.exe/4os2.exe
« Reply #14 on: January 09, 2020, 01:27:18 am »
The function to send the break signal to a process is DosSendSignalException, using the pid of the process and XCPT_SIGNAL_INTERRUPT  or XCPT_SIGNAL_BREAK as the second argument. The Ctrl-C character combination or scancode(3) won't work. Ctrl-C is intercepted by the OS and a signal is sent to the process that has focus. You'll need to set a signal handler for the signal in your main process and within that send the signal to the child process using DosSendSignalException.