Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Martin Vieregg

Pages: 1 ... 8 9 [10] 11 12 ... 17
136
Quote
Are you issuing a DosClose call on the pipe from the server application?
The server app (the PM editor) calls:
DosCreateNPipe
DosConnectNPipe (waits for DosOpen on client)

Meanwhile, the client (the helper which executes cmd.exe) calls DosOpen

Then the server continues. I do not use DosOpen in the server.

When the program gets finished, the client runs DosClose first. Then the server calls DosDisconnectNPipe.

I assumed that in the server I only have to use DosCreateNPipe, then Connect and Disconnect which is a substutute for DosOpen and DosClose. So do I have to use both DosOpen and DosClose in the server app or only DosClose?

------------
Quote
Isn't the user seeing the contents of stdout?
Yes, the user sees stdout in the PM editor immediately. But the PM editor has to know whether to send each keyboard user input character to cmd.exe immediately (within a sub program) or (prompting/idle) to wait until the user presses Enter.

137
- Problem with named pipes error 231 "pipe busy" when DosOpen
- Problem with cmd.exe idle state (program running or waiting for user input with prompt)

I thought that all OS-specific programming works fine now, but I still have got a problem with named pipes. When the helper program opens the named pipe, I sometimes get an error 231 (pipe busy). I cannot reproduce the problem regulary. It even occurs if I run only one instance of my program. I checked all named pipe API call returns. All works fine up to the DosOpen call. DosDisConnectNPipe returns 0 when exiting the last program session and DosCreateNPipe in the current session also returns 0. DosClose in the helper program of the previous session also returns 0. The problem does not occur when running the first session of the program after booting the computer. So it seems that the previous cmdme session did not clean up all properly. Any ideas?

Then I have got another problem. I have realized that the editor has to know whether cmd.exe is in idle state (waiting for user input) or not. Because if cmd.exe is exeuting a program and e.g. the user has to enter "Y" or "N", for example, a user input has to be sent immideately to cmd.exe. If there's a prompt and the user wants to enter a new command, the finished complete line of the new command with an ending Return character is sent and before, the user can change the input, has tab completion support and so on. I can read the prompt, but the prompt can change with the PROMPT command. A program which is executed by cmd.exe could generate a similar input. Any ideas how to query this state is appreciated. (I have got the session ID of the helper which executes cmd.exe. Perhaps I can query this state by querying the current session? Or I need a very intelligent interpretation of the proposed prompt string?)

138
Quote
This is simpler, check for a .cmd extension then load the cmd file into a buffer and interpret it line by line

Yes. Then I have only to interpretate my commands like mode and cls and I have to interpretate call to open cmd files recursive. That's not difficult to program. But I will introduce the rule that .cmd has to be added, otherwise cmd.exe executes the cmd file directly. (The user has the choice. It would be possible, but difficult to check whether a command is a cmd file or not.)

But this concept will fail with REXX scripts. I tried to copy a REXX script into the clipboard, then I copied it to the cmd.exe window, and it fails. So REXX scripts have to be executed directly by cmd.exe. If the user tries to type myrexxscript.cmd, then cmd.exe has to exeute the file directly nevertheless. REXX programs awas begin with /*, so they are easy to identify.

139
I want to capture the VIO calls cmd.exe sends to the PM window or to the screen (fullscreen) when e.g. a user types "mode" or "cls".
The problem I have is that I see the user input in the editor of course and the editor can interpretate these command by itself, but when cmd.exe executes a cmd file which holds "mode" or "cls", it won't get interpretated by the editor.

140
Laurence,

(5) works now. I have indeed to pass the argument "cmd.exe /K\0" instead of "/K". The error message has vanished now. Does that mean that two instances of cmd.exe are executed?

(4) "help KEYS" fits my purpose, thank you.

(1) Of course I can read stdout, and this works fine already. My query relates to the other stuff which is sent to the PM window like changing the size with "mode" or deleting the screen buffer with "cls" and so on.

141
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.

142
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 ?

143
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.

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

145
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.

146
> 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.

147
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...

148
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.)

149
Wim,
that sounds very plausible. Your description means, exceptions can only be sent from a non-PM process to a non-PM process?

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

Quote
DosSendSignalException sends either an XCPT_SIGNAL_INTR (Ctrl+C) or an XCPT_SIGNAL_BREAK (Ctrl+Break) signal exception to another process.
But I tried to run os4users parent and child exe from different sessions and the post does not reach the "child" anymore. So it indeed seems that a relationship is necessary.

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.

Meanwhile, I have tried that both non-pm programs are childs of my PM program and are started via DosExecPgm (asynchronous to get the PID). The parent can tell the helper the PID of the brother/sister. This doesn't work, too. That means, the editor has to execute the helper and the helper has to execute cmd.exe. So my editor gets a grandparent. I'll try this and report here.

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.

What is a good tutorial for semaphores with OS/2 ? In my german OS/2 programmers book, semaphores are missing.

150
I think that DosStartSession is the wrong way because Sessions can include several processes and we need to get the two processes as close as possible.

It tried your sample programs and they indeed work.
The differences to my program are:

- They are running in one single cmd window. I have got a PM app (the parent editor) and a child (cmd.exe) which is not a PM program.
- I am starting DosExecPgm from a thread, your sample program has no theads.

I will now modify your parent send program to a PM app and I will see what happen.
Then I will try to execute the child from the main thread in my program.

Hope we find the reason why your program works and mine not.

Pages: 1 ... 8 9 [10] 11 12 ... 17