problems programming a new text window for cmd.exe/4os2.exe

[Wim Brul]

Your description means, exceptions can only be sent from a non-PM process to a non-PM process?

Establishing an exception handler for Ctrl+C and Ctrl+Break is only supported for vio-window and full-screen sessions.
The pmshell session exception handler has its own way to deal with exceptions and DosSendSignalException has no effect.
See Figure1 - Proposed for working implementation. Shows the barrier between pmshell session and screen group session.

If I understand the DosSendSignalException docu right, the relationship between the processes (child or not) does not matter.

Exceptions are handled within a screen group on a Last-In-First-Out basis. Therefore a process within a screen group can always establish its own exception handler, which it might need, whether or not it is the parent, child or grandchild etc. within that screen group session.     

So I could start two non-pm programs, the cmd.exe and a text-based helper exe which simply sends the message forward to cmd.exe.

When you start two non-pm programs from you pm program then your helper process runs isolated from the command processor process.
See Figure2 - Proposed NOT working implementation. Shows barrier between pmshell session and both screen group sessions.

Wim, why do you think that I need to implement a new session? Cmd.exe currently runs in the same session as the parent editor.

I don't know how to explain it better. It is because DosSendSignalException() used by your PM program cannot affect cmd.exe then.

[Martin Vieregg]

Thank you Wim for the further explanations and figures. So the "grandfather" concept should work:

Grandfather (my PM editor) starts parent (cmdhelper.exe commandline program) via DosExecPgm - synchronous or asynchronous, with own session or not makes no difference at this point, because PID is not needed. I can send basic information from the grandparent to the parent when starting the parent via commandline parameters (name of the semaphore, cmd.exe or 4os2.exe to start). (The name of the semaphore need to have a counter because perhaps several instances of my program are running, or I use WinQueryWindowProcess and use the grandfather PID for a unique semaphore name.)

The parent executes the child (cmd.exe) via DosExecPgm in asynchronous mode and remembers the PID of the child.

If a user presses Ctrl-C in the grandfather PM program, the parent cmdhelper.exe program gets informed via Semaphores.  Then the parent sends the exception to the child via DosSendSignalException.

GO.EXE will show the structure:
  cmdme.exe (PM editor)
       cmdhelper.exe
               cmd.exe

Hope this concept is OK now ? (I can start the parent in a new session, no problem, but don't understand it, because if I use the same session as in the PM program, both cmdline programs are still in the same session.)

[Wim Brul]

Grandfather (my PM editor) starts parent (cmdhelper.exe commandline program) via DosExecPgm - synchronous or asynchronous, with own session or not makes no difference at this point, because PID is not needed.

The use of DosExecPgm() is incorrect at this point. DosStartSession() must be used to start the child session with different SSF_TYPE_WINDOWABLEVIO session type.

Hope this concept is OK now ? (I can start the parent in a new session, no problem, but don't understand it, because if I use the same session as in the PM program, both cmdline programs are still in the same session.)

Almost correct. Have a close look at Figure1 again. You will notice DSS written vertically to indicate that the editor uses DosStartSession() to start the helper. You need to use SSF_RELATED_CHILD to establish a parent session/child session relationship. A parent process/child process relationship is not established.

[Martin Vieregg]

Thank you, especially Wim, Laurence and OS4USER for your comments. Now I think I will manage it without help.

Programming is like real life. I send signals to my childs, and they did not receive the messages... Make your homework now, come to dinner, go to sleep, and no response...

[OS4User]

Thank you, especially Wim, Laurence and OS4USER for your comments. Now I think I will manage it without help.

Martin, I have to admit that I tested your cmdme.exe  in a wrong way  -  I started new cmd  with  "start cmd" command from command line provided by cmdme.exe  and a new process was not a direct child of cmdme  -  that is what I stated.

Now I traced this case  with proper scope (I hope ) and I can see  that cmdme.exe  is delivering new process "cmd"  automatically after start. Yes,  this "cmd"  is a direct child of cmdme.exe.

If I press Cntr-C  in cmdme.exe  window  it generates DosSendSignalException with a proper PID and signal.

DosSendSignalException returns you ERROR_NO_SIGNAL_SENT because cmd.exe does not report itself as "receiver of signals".

From  an example  I posted earlier   you may see   how  a potential child ("DosSetExceptionHandler.exe")  is organized to be a  "receiver of signals".

Please recheck it   - but it looks like  it is working in this way.

Regards

[Martin Vieregg]

> you may see  how  a potential child ("DosSetExceptionHandler.exe")  is organized to be a  "receiver of signals"

Even if I can send an exception from the PM parent to a cmdline child, the child has to be prepared. So a helper program would be necessary nevertheless. I think I will program Wims concept, I am tired of trials... I cannot re-organize cmd.exe. Wims concept is not really compilicated. I have only to lern semaphores. The helper program will be only a few lines of code.

[Lars]

Why do you need an intermediate process ? Why don't you just use "DosStartSession" in your PM app to run cmd.exe, catch the Ctrl-C combination in your PM app (just look for that Ctrl-C key combination in your window procedure) and then do a "DosStopSession" in your PM app. That should work as long as you started cmd.exe as RELATED.

[Martin Vieregg]

Yes, killing and restarting cmd.exe would work, too. I could also start with DosExecPgm and kill the process with the PID. But it is not a gentleman solution. Files could rest open (when for example copying files). The sub processes/programs cmd.exe would also get killed or can hang. Sending Ctrl-C to cmd.exe and a correct interrupt is strongly recommended. Cmd.exe always finishes a file copy when pressing Ctrl-C, for example. My program will have one limitation I cannot omit (that direct Screen IO buffer output is not supported), and this should really be the only limitation. Wim and OS4user sample programs showed us that it will be possible with a helper program of a few lines code which will have a size of 30 kB.

[Martin Vieregg]

Meanwhile, I found the programming tutorial and description of semaphores:
IBM OS/2 Warp Development Manuals, especially the document cp3.inf.

[Martin Vieregg]

I have written now the communication between the PM editor and the helper program via unnamed semaphores and shared memory. When the PM editor runs the helper, the command parameters hold the pointer values of the shared memory and the semaphores. This all works fine already.

I tried to run the program in the grandfather - parent - child variant and it did fail - Wim was absolutely right with his forecast, when he said, I need a separate session for the helper and the cmd.exe program. The parent cannot send exeptions to the child if it has been executed as a process from another program (grandfather) - I indeed get an error when calling DosSendException to cmd.exe in the helper program.

Because the editor has to start the helper program in a separate session (DosStartSession), the inheritance of stdin, stdout und stderr via DosExecPgm is not available. So I do not use DosDupHandle in the PM editor. Instead, I use DosCreatePipe and inform the helper program about the file handle values of the three pipes via commandline parameters.

But now the helper program has to set stdin, stdout and stderror to the values which are received from the PM editor via commandline parameters. In Windows, there's a function SetStdHandle, and I cannot use DosDupFile, because DosDupFile (parampipehandle, &STDIN_HANDLE) does not work of course (because STDIN_HANDLE has the fix value 0). How can I set stdin, stdout and stderr to my specific handle values before executing cmd.exe and inheriting stdin, stdout and stderr? I am sure that the solution is simple, but I have no idea anyway.

[Martin Vieregg]

I have found the solution in the sample code popen.c again:

Code: [Select]

   #define STDIN 0
    HFILE Tmp;
    Tmp = STDIN;
    DosDupHandle (stdin_from_editor, &Tmp);

and similiar with stdout and stderr. It seems that DosDupHandle handles the values 0, 1 and 2 different from a memory pointer. But it is necessary to use a Tmp file handle variable.

But it does not work yet. It seems that unnamed pipes are only allowed between processes in one single session. This is not documentated, but in the documentation I found: "Unnamed pipes are useful to transfer data between related processes".

So it seems that I need to switch to named pipes again. To preclude a programming failure, does someone know it definitely ?

[Wim Brul]

So it seems that I need to switch to named pipes again. To preclude a programming failure, does someone know it definitely ?

With DosStartSession() a parent process/child process relationship is not established. Hence named pipes must be used between editor and command processor.

[Martin Vieregg]

Meanwhile, the new concept of the cmdme editor with a cmdhelper exe works! Thanks to Wim especially. So I have managed all the programming close to OS/2. Ctrl-C and Ctrl-Break (I see no difference) works now. Ctrl-S pause is implemented directly in the editor (cmd.exe runs straight on until the pipe buffer is full), because I assume that I can only suspend threads but not sessions.

There are some additional questions left for further programming:

(1) It would be interesting to see the communication between cmd.exe and the PM window where cmd.exe is executed. Is there any way to read/redirect this information? (I have no idea what to do with this information yet, but it could be useful.)

(2) If a user executes a crt VIO program (like DFSEE) which does not support stdout and directly writes into the screen buffer, can I recognize these programs by examining the binary? So there are three different types of OS/2 programs: PM, commandline with standard IO, commandline which writes directly to the screen buffer. Then I would turn the hidden cmdhelper/cmd.exe window to front when exeuting the last program type.

(3) I have found an old OS/2 1.X program which simply shows a colored directory tree (see attachment). This program does not generate ANSI ESC sequences, but has normal stdout. In cmdme, it is shown without colors. I do not understand how it can show colors, support stdout and does not generate ANSI ESC sequences.

(4) Where do I find a description of cmd.exe keyboard input? (E.g. cursor up restores old input, Ctrl-C breaks and so on). "help cmd" shows only the commands you can type.

(5) When starting cmd.exe from helper exe, it is always shown:

Code: [Select]

SYS1034: The system cannot find the command processor in the path specified.
OS/2 Command Interpreter version 4.5
But cmd.exe runs and all works fine. It does not matter if I start cmd.exe with or without full path name. 4os2 writes 'Unknown command "Program" ' instead and also works.

[Laurence Pithie]

) It would be interesting to see the communication between cmd.exe and the PM window where cmd.exe is executed. Is there any way to read/redirect this information? (I have no idea what to do with this information yet, but it could be useful.)

As you are reading and writing texts strings to/from the pipe do an additional write of the same strings to a log file after reading/writing them to/from the pipe is probably the simplest method.

(3) I have found an old OS/2 1.X program which simply shows a colored directory tree (see attachment). This program does not generate ANSI ESC sequences, but has normal stdout. In cmdme, it is shown without colors. I do not understand how it can show colors, support stdout and does not generate ANSI ESC sequences.

It's probably mixing standard i/o and vio calls. and overlaying one on top of the other. So you would get colour output on a terminal and plain text if the output was redirected.

(4) Where do I find a description of cmd.exe keyboard input? (E.g. cursor up restores old input, Ctrl-C breaks and so on). "help cmd" shows only the commands you can type.

The KEYS command implements command line editing.

SYS1034: The system cannot find the command processor in the path specified.
OS/2 Command Interpreter version 4.5

The first of the ASCIIZ strings passed as an argument to DosExecPgm should be the name of the command interpreter, "cmd\0" of "40s2\0"  for the os2 command intepreter and 4OS2 respectively. Otherwise it treats the first command you pass as the name of the program to load, which, if it an internal command or an option paramter (DIR or /K for example) you'll get a command not found error

[Laurence Pithie]

Here's a hello world example of overlaying vio and std i/o