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 - Laurence Pithie

Pages: 1 [2] 3 4 5
16
Programming / Re: Observing if a program uses vio calls
« 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.

17
Programming / Re: Observing if a program uses vio calls
« 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.

18
Programming / Re: Observing if a program uses vio calls
« 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.

19
Programming / Re: Observing if a program uses vio calls
« 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.


20
Programming / Re: Observing if a program uses vio calls
« on: March 03, 2020, 07:05:06 pm »
 
Quote
But anyway, I wonder why I cannot access directly to the buffer address buf_addr of VioGetMode.
There appears to be two distinct versions of the VioGetBuf  call, and some others. The version with the length parameter as a USHORT appears to be the FAPI version, the version with the length parameter as a ULONG appears to be the 32 bit API, which was never distributed as part of the toolkit. It was available as the 32TEXT beta on the developers connection, however it has some fairly serious bugs. The 32 bit Unicode console API from JdeBP is built upon the 32 bit Vio, Kbd and Mou API, but is bundled with dll's which have had the bugs fixed. It can be found on Hobbes as conapi.zip.

The FAPI has some fairly significant limitations.
Quote
Real Mode
    max. 640K memory
    no virtual address space
    no multitasking
    no undocumented OS services
    If the filename of an executable produced by BIND is changed, then it will not run under DOS 2.1.

Protected Mode
    16 MB memory
    1GB virtual address space
http://www.edm2.com/index.php/Family_API

21
Programming / Re: Observing if a program uses vio calls
« on: March 03, 2020, 09:55:28 am »
Quote
I want to copy the screen buffer to compare with an ancient state.
If all you want to do is see if new output has been writtten to the screen then VioReadCharStr will do what you want.
1. Calculate the length of the before buffer you require from the number of rows and columns returned from VioGetMode.
2. Allocate memory for the before buffer
3. Call VioReadCharStr to read the entire screen

Do stuff with command shell

4.  Calculate the length of the after buffer you require from the number of rows and columns returned from VioGetMode.
5. Allocate memory for the after buffer
6. Call VioReadCharStr to read the entire screen

7. Compare the before buffer with the after buffer

8. Clean up.

It's ugly, but it should work..

22
Programming / Re: Observing if a program uses vio calls
« on: March 02, 2020, 08:11:58 pm »
You can check the current mode using VioGetMode, Vio programs can change the mode using VioSetMode.

The length of the buffer returned by VioGetBuf is calculated as the product of the number of columns, rows and cell size. So, if the mode command changes the number of columns or rows the length of the buffer will also change.

23
Programming / Re: Observing if a program uses vio calls
« on: March 01, 2020, 10:38:31 am »
From the IBM Toolkit 4.5 Control Program Guide and Reference
Quote
#define INCL_VIO
#include <os2.h>

PULONG     Row;        /*  Row return data. */
PUSHORT    Column;     /*  Column return data. */
HVIO       VioHandle;  /*  Presentation-space handle. */
APIRET     rc;         /*  Return code. */

rc = VioGetCurPos(Row, Column, VioHandle);

24
Programming / Re: Observing if a program uses vio calls
« on: February 28, 2020, 03:06:27 pm »
Quote
2. A continous query via thread loop: "Please observe the VIO window and tell me immediately if VIO has changed."

The continous query is only sent to the helper if no stdout is shown for a specific time, e.g. 300 or 400 ms.
Can you tell  me what the use case for this is? When would the Vio cursor change other than when there is output from a command. In which case what you're doing in 1, covers this case.

Recreating the thread is probably simpler, suspending and resuming it means you have to implement some way of checking that the values of any variables haven't changed behind the threads back while it was suspended. If it turns out that recreating the thread becomes a performance bottleneck then you can revisit the question. Given that you're processing commands that are being typed by the user it's unlikely that anyone can type fast enough to make that an issue.

The receiver creating the semaphore is the most sensible way to do this in this context. Think of it in terms of the first process, the PM application,  setting up the environment in which the helper process will execute rather than which process posts and which process waits on the semaphore.

25
Programming / Re: Observing if a program uses vio calls
« on: February 27, 2020, 09:26:33 pm »
You shouldn't be continously polling the Vio cursor position, it's uneccessary. The only time you need to know if the Vio cursor has moved is following the completion of a command that produces no output on stdout. The helper program should do the checking and indicate to the PM application that there is Vio output so the PM application can pop up the Vio window.

The helper application should
1) check the position of the Vio vursor
2) write the command to stdin
3) Check for output from the command on stdout
4) Indicate to the PM app that the command has completed
5) If there is output on stdio send it to the PM app for display
6) If there is no output on stdio check if the Vio cursor position has changed
7) If the Vio cursor position has changed indicate to the PM app that there is Vio output.

The PM app should
1) Send the command to the helper app.
2) Await indication that the command has completed
3) Check if output has been sent from the helper program. If there is display it. You're done
4) If there's no output check if the helper has indicated that there's Vio output. If there is pop up the Vio window.

For 4) in the PM app this could be done by either the helper app writing a sentinel value to the pipe (something like "**vio_output**" would probably work) or posting an event semaphore. If you use a sentinel value then it's simply a check for that value at the start of the display routine which forks to popping up the vio window instead of displaying the text read from the pipe. If you use an event semaphore then you need a thread waiting on the event semaphore that  pops up the vio window when the helper posts the event semaphore.

The PM app shouldn't be doing anything with the Vio cursor, it shouldn't be going near it, and polling it  using a timer is just broken. If the command takes a long time to complete you'll run the risk of polling too early, at which point your PM app will read that there's no change in the Vio cursor and fail to pop up the window. It's a race condition, and that's why you should use semaphores and not polling.

26
Programming / Re: Observing if a program uses vio calls
« on: February 27, 2020, 12:34:06 pm »
1. The PM app shouldn't care about the cursor position, the PM app should care about output. Use  semaphores to indicate that the command has completed and produced output, The helper app posts a semaphore when the command has completed, the helper app should check for vio output if the command doesn't produce output on stdout and indicate this to the PM app, which should pop up the vio window if it's appropriate. It could indicate the presence of vio output using a semaphore or by writing a specific value to the pipe before writing the prompt to the pipe.

2. Don't observe while executing, the PM app should care about output, not how  the shell is doing what it is doing, that's the province of the helper application. Either it's got output to display or it hasn't and the output is either in the pipe or it needs to pop up a vio window. Which action is required should be indicated by the helper application, not computed by the PM application.   Modularity breeds simplicity.

3. See 1.

Analysing the executable files is unnecessary, and certainly not something that a shell front end should be doing. It's an interesting project in it's own right though. If you are interested in pursuing it then the OS/2 debugging handbook is a good place to start.
https://openlibrary.org/works/OL8414318W/The_OS_2_Debugging_Handbook

27
Programming / Re: Observing if a program uses vio calls
« on: February 27, 2020, 01:13:16 am »
For 2b and 2c have the thread that writes the command to stdin set a semaphore and have the thread that reads from stdout post that semaphore, that way it's only active when a command is running, so you don't have to handle 2a.  Then have a thread that is started immediately after the command is written to stdin which waits on the semaphore being posted with a timeout value. If your reader thread reads data from stdin then it should post the semaphore, The thread waiting on the semaphore should call DosQueryEventSemaphore to get the post count to distinguish between the semaphore being posted or the timeout expiring. If the timer has expired it should check whether the cursor position has changed if it has then pop up the vio window, if it hasn't there's been no output.

I'm assuming that the helper application sits in a DosWaitEventSemaphore which the PM application posts when it sends a command.

28
Programming / Re: Observing if a program uses vio calls
« on: February 26, 2020, 06:21:42 pm »
Quote
VioHandle (HVIO) - input
Presentation-space handle.

This must be zero, unless the caller is a Presentation Manager application; in this case, it must be the value returned by VioCreatePS
Your helper application isn't a presentation manager application, so the VioHandle should be zero.

29
Programming / Re: Observing if a program uses vio calls
« on: February 26, 2020, 01:53:12 pm »
Looking at the documentaion for os2trace I found this.
Quote
The  first  feat,   trace  enabling,   is  accomplished  by
                 processing  each  entry in  the table of strings within the
                 executable  file that  contains the  names of  the imported
                 DLLs.  If the entry  represents one  of the  supported OS/2
                 DLLs and the  user requested  enablement of API tracing for
                 this  DLL,  the  entry is  replaced  with the  name  of the
                 appropriate  trace  DLL.   

Quote
   NOTE:  Trace enablement alters the contents of the table of
                 strings within the executable file  that contains the names
                 of the imported DLLs.  Although this action does not affect
                 the  functionality of  the executable,  it does  affect its
                 date and time stamp unless the -P option is specified.

This behaviour is fine if I'm debugging something, it's not something I'd expect an application, particularly a text editor, to be doing behind my back. It'll also give an antivirus program conniptions. If all you want is to check if an arbitrary application uses only vio calls for output then what you are trying to detect is
a) Is there any output on stdio (some programs use overlaying of vio and standard i/o in which case you don't care about vio)
b) If there is no output on stdio has the program written to the screen using vio calls
in case b if the program has written to the screen using vio calls the cursor will have moved.

So, something along these lines would give you the behaviour you want.
1 Get current cursor position (VioGetCurPos) and save it
2 Write command to pipe
3 Check for output on stdout, if there is you're done
4 If there isn't check the cursor position and compare it to the original, if it's different pop up the vio window, otherwise there was no output.

You can, and indeed you should, check for the case where there's no output on stdout but there is on stderr and take apropriate action(popping up the vio window at a minimum). While it's possible that an application might use vio calls exclusively for error output rather than writing to stderr I've never seen it, nor can I think of a case where it would be sensible.

30
Applications / Re: Is the Arca Noae update service worth it?
« on: February 21, 2020, 02:34:50 pm »
I think it's worth paying for, not simply for the access to updates but to support the development of the updates.

Pages: 1 [2] 3 4 5