Author Topic: Observing if a program uses vio calls  (Read 2356 times)

Laurence Pithie

  • Jr. Member
  • **
  • Thank You
  • -Given: 0
  • -Receive: 3
  • Posts: 57
    • View Profile
Re: Observing if a program uses vio calls
« Reply #30 on: March 07, 2020, 11:55:44 am »
Quote
- but the invisible and empty VIO window now expects a keystroke!
No, the process running in that session is expecting a keystroke, it's the MORE command that's expecting the keystroke on stdin, not the vio window. 
Quote
In the editor I distinguish between "prompt state" and "not prompt state"
What you've got is a "not a cmd prompt state", You've got the prompt for the interactive program that's running in the command shell, in the example that's the MORE command. That prompt is being displayed in the editor, so the user knows that input is expected. The named pipe will be empty because the PM program has read the output, including the prompt, from the process running in the cmd shell.

Calling DosPeekNPipe will show that there is no data available in the pipe because the process is waiting for input on stdin. Use that check to indicate that the user's input should be piped to the process awaiting input. I'm assuming that you are checking the return from DosRead for an ERROR_MORE_DATA return code, in order to ensure that there is no data left in the pipe from a partial read.

The user will still need to press return in the editor to actually send the input, which may result in the process receiving an additional keystroke. If the process is expecting single character i/o the process should be flushing the keyboard buffer between prompts, if it isn't that's not your bug, it's the program that you're running in the shell that's buggy.

« Last Edit: March 07, 2020, 12:15:41 pm by Laurence Pithie »

Andi B.

  • Sr. Member
  • ****
  • Thank You
  • -Given: 1
  • -Receive: 22
  • Posts: 487
    • View Profile
Re: Observing if a program uses vio calls
« Reply #31 on: March 07, 2020, 07:49:57 pm »
LarsonCommander does fire up a new cmd window in case | more is used with dir.

Martin Vieregg

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 5
  • Posts: 200
    • View Profile
Re: Observing if a program uses vio calls
« Reply #32 on: March 07, 2020, 10:47:33 pm »
Laurence, it 's all right what you have written, but it does not target my problem. Indeed, the user (not my program) sees that keyboard input is expected. But if the user presses a key on the keyboard, my program does not know how to handle it: sending it to the VIO window via WM_CHAR messages (hope this works) or sending it to cmd.exe via STDIN. In the STDIN variant, a whole line is collected in the editor and is sent in a whole line after the user has pressed ENTER. This problem is independent from the MORE and the empty VIO window problem. I have solved recognizing VIO output, but not recognizing VIO input yet. In most cases, the problem does not occur at the surface, because before expecting VIO input, a VIO output has been recognized and the VIO window has popped on top so it catches the keyboard input anyway. It is only the very specific problem if no VIO output has been generated from a VIO program and a user input via VIO is expected. Perhaps we can simply classify MORE as a bug.

With the speical MORE case, it would be perhaps the best option that the editor itself interpretates the "| more" input and stops with output after one page has been written. Or we write a MORE substitute which is identical to the original one, but does not wait for a VIO keypress and instead, it waits for a stdin line (so the user has to press ENTER instead of any key:

---more---- press Enter to continue

The case of
Code: [Select]
more <filename.txthas the same problem/behaviour.

Can we get the original MORE.EXE source code? (I assume it is quite short.) The usage of MORE is quite variable, so an own executable is perhaps more useful than implementing in the editor (which again forces problems when using in cmd files).

Laurence Pithie

  • Jr. Member
  • **
  • Thank You
  • -Given: 0
  • -Receive: 3
  • Posts: 57
    • View Profile
Re: Observing if a program uses vio calls
« Reply #33 on: March 08, 2020, 12:38:10 am »
The problem with sending a WM_CHAR, or indeed any sort of message is that the cmd process doesn't have a message queue. The frame window does, but that's handling messages for the frame window, the system menu etc.

I have to say that, given the purpose is to get the output of a command into the text editor, I can't see a use case that requires it to be piped through a paginator in the cmd shell. There's no relationship between the dimensions of the cmd shell and the text editor, so it'll end up looking odd,  and, presumaby, the user wants to do some editing of the output text in which case piping the output through a paginator is pointless.

There are a number of implementations of the MORE command, it's one of the GNU utilities, along with LESS, so getting access to source code isn't a problem. LESS is part of the coreutils available via ANPM, and is a far better pager.

An alternative approach would be to deal with piping the output from one command into another within the editor. Instead of passing a line of commands containing pipes to the shell parse the command line and pass each command seperately, collecting the output of each command and using that as the input for the next command in the pipeline. That lets you do your own paginationin the editor, where it makes more sense.

Martin Vieregg

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 5
  • Posts: 200
    • View Profile
Re: Observing if a program uses vio calls
« Reply #34 on: March 08, 2020, 03:47:53 pm »
Quote
The problem with sending a WM_CHAR, or indeed any sort of message is that the cmd process doesn't have a message queue. The frame window does, but that's handling messages for the frame window, the system menu etc.

Can I perhaps send a message to the helper (the way I have already programmed via Semaphores and Shared Memory) that a user has pressed a key on the keyboard and the helper program writes the character to the keyboard buffer of its own session?

Thinking about my problem has resolved that if no VIO output happened and the user presses SPACE (SPACE is no useful answer for a menu or Y/N query), it is most likely, that the SPACE has to be sent to the VIO window and not to STDIN. This should cover the majority of cases.

Laurence Pithie

  • Jr. Member
  • **
  • Thank You
  • -Given: 0
  • -Receive: 3
  • Posts: 57
    • View Profile
Re: Observing if a program uses vio calls
« Reply #35 on: March 08, 2020, 03:51:02 pm »
Quote
Can I perhaps send a message to the helper (the way I have already programmed via Semaphores and Shared Memory) that a user has pressed a key on the keyboard and the helper program writes the character to the keyboard buffer of its own session?
What you did in that instance was use the semaphore to trigger sending a signal to the helper precisely because the helper didn't have access to the keyboard to get the break signal triggered by pressing ctrl-c on the keyboard. Writing to the screen isn't a keypress, the process running in your shell is waiting for a keypress, Vio programs use KbdCharIn, KbdStringIn or KbdPeek to read key presses and they only have access to the keyboard when they're in focus. For a non PM session you can use a character device monitor to insert data into the character stream from the keyboard.
http://www.edm2.com/index.php/PDDREF:Character_Device_Monitors
Quote
Thinking about my problem has resolved that if no VIO output happened and the user presses SPACE (SPACE is no useful answer for a menu or Y/N query), it is most likely, that the SPACE has to be sent to the VIO window and not to STDIN. This should cover the majority of cases.

It's not the Vio Window that's waiting for input, it's the process that's running in the shell that's running in the client area of the Vio Frame Window that's waiting for a key press. Even if you subclassed the client window to process a message, that's still not going to send a keypress to the process running in the shell that's running in the client window, because that process will be using KbdXXXXXX functions to read a physical key press, it knows nothing about messages.

What might work is to switch focus to the Vio Frame Window before showing the prompt in the editor window using WinSetFocus, that way the Vio Window gets the keypress and not the editor window. However, if that works at all, it's incredibly fragile, a simple alt-tab by the user breaks it.

I still can't see a use case for this feature in a text editor. I can see the user wanting to be able to transform text using complex pipelines and batch processing, but why would they be processing text through either another full screen interactive text editor or a pager as part of that process? The output is going to be appearing in the text editor, so I don't need a paginator when I can scroll backwards and forwards through the output text and I'm in a full screen interactive text editor, why would I want to run another one as a subprocess? It seems to be a misfeature that nobody would use except by accident, and that's what the interrupt or break signals  are for.
« Last Edit: March 08, 2020, 05:18:34 pm by Laurence Pithie »

Martin Vieregg

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 5
  • Posts: 200
    • View Profile
Re: Observing if a program uses vio calls
« Reply #36 on: March 08, 2020, 09:35:26 pm »
At the moment, my program is already very useful. But I do not want that a user always has to think of if my program fits his purpose or not. So I have to add basic VIO switch functionality. The user often does not know which commands are VIO relevant and which not, even I have to try some programs to see what happens. So the behaviour of my editor should be usable, it does not need to be perfect. It is clear for me that we discuss perhaps 3% of the normal commandline usage, because the majority of commands is stdout-based only and the problems we discuss here do not appear.

Another simple solution of the MORE problem is to create a warning message in the editor. Because the more command depends on the size (line count) of the VIO window, MORE is not a good solution. I have got already a silder where you can reduce the output speed. The leftmost value could generate a pause after one visible page has been written with stdout output. This solution would be completely in the editor. Another option is that this behaviour can be set for one single command by using MORE. So my editor interpretates the MORE command and the rest of the command gets transformed to the command without MORE which is sent to cmd.exe.

An important question for me is if MORE is the only program which requires single keystrokes without creating VIO output before. Does anyone know a second program? If noone knows a second program, this internal editor solution would be perfect.

Anyway, when I publish the first version, everyone can report specific problems.


Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 169
  • Posts: 2425
    • View Profile
Re: Observing if a program uses vio calls
« Reply #37 on: March 08, 2020, 10:55:48 pm »
Well there's various more replacements such as less, which is recommended to use instead of more.
What about if a program pipes output, something like "dir | tee dir.log"? or input, "\usr\bin\patch.exe < foo.patch"?

Laurence Pithie

  • Jr. Member
  • **
  • Thank You
  • -Given: 0
  • -Receive: 3
  • Posts: 57
    • View Profile
Re: Observing if a program uses vio calls
« Reply #38 on: March 09, 2020, 12:02:25 am »
There are a host of pagers, including variants which pop up PM windows. Another common scenario is piping text through troff into a postscript viewer.  It's not just Vio programs, most *nix derived utilities if you don't supply a filename will read from stdin by default, and in that scenario if you forget to provide a filename you will not get a prompt returned from the helper program to indicate in the PM program that it's waiting for input.

Andreas Schnellbacher

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 26
  • Posts: 503
    • View Profile
Re: Observing if a program uses vio calls
« Reply #39 on: March 09, 2020, 01:34:23 am »
What about if a program pipes output, something like "dir | tee dir.log"? or input, "\usr\bin\patch.exe < foo.patch"?
Both already work with EPM. The current discussion is about VIO apps that don't use STDOUT or STDERROR but use VIO functions to write something in the console. Unfortunately there exist a few.

BTW: I don't see the necessity to support these cases, even against the background that there exist a few famous .exes and REXX .cmds that use VIO functions to write to the console or to place the cursor.

Martin Vieregg

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 5
  • Posts: 200
    • View Profile
Re: Observing if a program uses vio calls
« Reply #40 on: March 09, 2020, 09:23:36 am »
When the "|" command is used to send data to another stdin/out program, I see no problems with my program. Only more and less and its derivates  (which names are also common?) can make problems. But these programs are helpers in a small text window where the output runs into Nirvana. This is the main functionality of my frontend to scroll back without limit. So these helpers are obsolete. I only have to find a useful way how to handle it. Like described above, I could support "| more" in the editor to enable the page-keypress functionality in my editor. In the ME editor when typing
[C:\] dir /s | me in
the default behaviour is not to scroll while output gets received, and this behaviour should be an option in my commandline frontend. My program has already a LED which glows red while the command is compiled and green when a prompt is shown. With ESC, you can easy jump to the prompt.

Our discussion here is very helpful for me. It helps me sorting my own ideas and it prevents me from programming something which does not fit the real purpose of my program.

I will publish a first version in 1-2 weeks. I have decided to name it MeShell.
« Last Edit: March 09, 2020, 02:25:00 pm by Martin Vieregg »