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

Laurence Pithie

  • Jr. Member
  • **
  • Thank You
  • -Given: 0
  • -Receive: 3
  • Posts: 59
    • View Profile
Re: Observing if a program uses vio calls
« Reply #15 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);

Wim Brul

  • Full Member
  • ***
  • Thank You
  • -Given: 3
  • -Receive: 37
  • Posts: 212
    • View Profile
    • Wim's home page
Re: Observing if a program uses vio calls
« Reply #16 on: March 01, 2020, 11:35:37 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);

Yes, that info is there, but when you look into BSESUB.H you will see that only the 16 bit version has been defined in there.     

Martin Vieregg

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 8
  • Posts: 226
    • View Profile
Re: Observing if a program uses vio calls
« Reply #17 on: March 01, 2020, 12:24:54 pm »
In the Borland C header, both parameters row and column are PUSHORT. So we have three different meanings. Anyway, the original 2 times PUSHORT definition works. I assume the are problems if values higher than 65536.

Meanwhile, the new mechanism for popping up VIO windows works! But I have found a program TED.EXE (very old minimalistic editor for editing config.sys on 3,5 inches discs) which is not recognized: It is a pure VIO program and when starting, it draws a menu on the bottom of the VIO window and then it awaits input on the topleft cursorposition (0,0). So my program thinks that there was no input. Are there other useful VioGet... calls where I can additionally query and compare other values than the cursor position? Perhaps comparing the whole screen buffer? (Which is not as big today as it was 20 years before...) I could write user settings for these additional queries.

Wim Brul

  • Full Member
  • ***
  • Thank You
  • -Given: 3
  • -Receive: 37
  • Posts: 212
    • View Profile
    • Wim's home page
Re: Observing if a program uses vio calls
« Reply #18 on: March 01, 2020, 12:50:10 pm »
In the Borland C header, both parameters row and column are PUSHORT. So we have three different meanings. Anyway, the original 2 times PUSHORT definition works. I assume the are problems if values higher than 65536.

Meanwhile, the new mechanism for popping up VIO windows works! But I have found a program TED.EXE (very old minimalistic editor for editing config.sys on 3,5 inches discs) which is not recognized: It is a pure VIO program and when starting, it draws a menu on the bottom of the VIO window and then it awaits input on the topleft cursorposition (0,0). So my program thinks that there was no input. Are there other useful VioGet... calls where I can additionally query and compare other values than the cursor position? Perhaps comparing the whole screen buffer? (Which is not as big today as it was 20 years before...) I could write user settings for these additional queries.

Use VioReadCharStr to compare the whole screen buffer (I think 8192 chars max)  or use VioReadCellStr to compare the whole screen buffer including colors.

Martin Vieregg

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 8
  • Posts: 226
    • View Profile
Re: Observing if a program uses vio calls
« Reply #19 on: March 02, 2020, 06:34:20 pm »
I think I will compare the whole screen buffer (max 2x8192 bytes). If I understand it right, a "cell" is a byte for the ASCII value and a byte for the colors and attributes. VioGetBuf let me show both the length of the buffer and the address. The user can choose whether to compare the Cursor position or the whole screen buffer.

Does anyone know if the screen buffer changes with the "mode" command? Can VIO programs change the window size on their own?

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 189
  • Posts: 2592
    • View Profile
Re: Observing if a program uses vio calls
« Reply #20 on: March 02, 2020, 07:00:50 pm »
Does anyone know if the screen buffer changes with the "mode" command? Can VIO programs change the window size on their own?

I was compiling something inwhich the GCC output used ANSI colours and the VIO window unexpectedly changed to about 20 chars wide, I assume due to a ANSI escape sequence.

Laurence Pithie

  • Jr. Member
  • **
  • Thank You
  • -Given: 0
  • -Receive: 3
  • Posts: 59
    • View Profile
Re: Observing if a program uses vio calls
« Reply #21 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.

Martin Vieregg

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 8
  • Posts: 226
    • View Profile
Re: Observing if a program uses vio calls
« Reply #22 on: March 03, 2020, 08:57:41 am »
First, VioGetBuf has in the edm2 wiki the same wrong description. Length is USHORT and not ULONG. It seems that the 8192 char limitation depends on the USHORT values which are spread all over the VIO calls. If I have true color foreground, background, attributes and the ASCII value, then I need 8 bytes for one cell. I think this is the reason for the 8192 chars limit. That means, even if we write the VIO dll new, all existing programs have got the USHORT values in their code. (Perhaps in Windows, this restriction has not existed since Windows NT?) For a perfect solution, we would need a new VIO32 API interface and a compatibility mode. This is a big thing, so I think that the way I have chosen to pop the original VIO window is the right one for the moment.

------------------

But VioGetBuf does not fit my purpose. I want to copy the screen buffer to compare with an ancient state. VioGetMode fits my purpose. I get a structure VIOMODEINFO which holds lots of interesting information. I have logged some values:

VioGetMode returns rc = 0; buffer length 4000 full length 4000 columns 80 rows 25 address 753664

The length of the buffer is 80 x 25 x 2 = 4000. One byte is for the ASCII value, one for the attribute and colors.

But the address of the screen buffer is too low for a normal memory pointer. memcpy let the program crash, the access to this address is not valid.

The definition in VIOMODEINFO is:

ULONG   buf_addr
ULONG buf_length
ULONG full_length


(Interesting: buf length has got here a 32 bit value and this is really true.)

Any idea how to get access to the data? Perhaps I have to convert this value to a real pointer value.

Laurence Pithie

  • Jr. Member
  • **
  • Thank You
  • -Given: 0
  • -Receive: 3
  • Posts: 59
    • View Profile
Re: Observing if a program uses vio calls
« Reply #23 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..
« Last Edit: March 03, 2020, 09:57:30 am by Laurence Pithie »

Martin Vieregg

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 8
  • Posts: 226
    • View Profile
Re: Observing if a program uses vio calls
« Reply #24 on: March 03, 2020, 03:20:46 pm »
OK, Laurence. VioReadCharStr works now. TED.EXE which starts at cursorposition (0,0) and ends after writing the screen on cursorposition (0,0) is recognized now. In most cases, only 2000 bytes have to be compared. But anyway, I wonder why I cannot access directly to the buffer address buf_addr of VioGetMode.

Again, the VioReadCharStr length parameter is USHORT, not ULONG. I think the whole VIO EDM2 documentation has to be checked.

Thank you Laurence and Wim again for your valuable hints and explanations !

Laurence Pithie

  • Jr. Member
  • **
  • Thank You
  • -Given: 0
  • -Receive: 3
  • Posts: 59
    • View Profile
Re: Observing if a program uses vio calls
« Reply #25 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

Martin Vieregg

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 8
  • Posts: 226
    • View Profile
Re: Observing if a program uses vio calls
« Reply #26 on: March 05, 2020, 09:10:02 am »
If I understand the linked EDM2 FAPI page right, VIO is the only part of OS/2 which is still used in 16 bit and 32 bit VIO has started (I assume about the year 2000, at the end of IBM OS/2 development), while all other FAPI stuff has been rewritten in 32 bit and the conversion project has not finished. In the EDM2 documentation, some but not all VIO calls are documentated in two variants, one 16 bit with (FAPI) and one 32 bit without.

http://www.edm2.com/index.php/VioReadCharStr_%28FAPI%29
http://www.edm2.com/index.php/VioReadCharStr

Some parameters are USHORT in the FAPI variant and ULONG in the non-FAPI (32 bit) variant.

So that means the last correction in EDM2 was false. All VIO calls in the EDM2 documentation which have a FAPI correspondent page have to get a link with a sentence: "VIO 32 (bla bla) needs DLL (bla bla) not supported by default, Link to FAPI call"

Some calls have got a correspondent FAPI entry, others not.

Where are the binaries (DLLs) of vio16 and vio32 and do we have the source code to complete the vio32 calls in a long run? (I don't need this stuff for my editor, meanwhile all works fine.)

Martin Vieregg

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 8
  • Posts: 226
    • View Profile
Re: Observing if a program uses vio calls
« Reply #27 on: March 07, 2020, 09:31:28 am »
I thaught that I have all VIO specific stuff solved (works really nice and handy, with two different positions of the VIO window dependent on the prompt state of the editor window, so nothing important is covered), but there's another special situation which is not programmed yet and where my program still fails:

[C:\] dir | more

more let rest the output at stdout and writes into stdout (not VIO!) an additional line

----more----

and then it waits for a keypress via VIO. Stdin Input always requires pressing ENTER at the end of the line, and VIO accepts a single keystroke.

Now the behaviour of my program is like I have it programmed:

- The "dir" output is shown in the editor and ends with a "----more----" line
- the VIO window does not pop up because there's no output to show (it is still empty or unchanged)
- but the invisible and empty VIO window now expects a keystroke!

In the editor I distinguish between "prompt state" and "not prompt state" (the user types a new command or the last command is still executed). So I can simply send the user input in not prompt state (program is running) to the VIO window by a WM_CHAR message to the Vio Window handle, I think this should work (have not tried yet). But now I get a new problem: I need to know whether a program waits for stdin input (a character or a line which is finished by typing ENTER) or the VIO window waits for a single keystroke. I have no clear solution for this problem yet. Any hints are appreciated. Again, the helper program running in the VIO window could perhaps help me in observing something.

I would not have the problem if MORE would send the "----more----" line to VIO instead of stdout. The MORE substitute on Hobbes (a VIO read only editor where you have to press "q" to quit) runs completely in VIO and makes no problems. Of course users of my program do not need MORE anymore, but it could appear in cmd files. And  there's the question if there are other programs which require VIO console input without writing to VIO or MORE is the only case - all stdout programs with a "press ANY key" (not only ENTER) are candidates for this problem.

Of course, I could scan the last stdout line content by searching "more" or "any key" (oops, how much languages do exist?), but I hope we find a general solution like we did for VIO output by observing the whole screen text buffer.

Perhaps one of these calls can help:
http://www.edm2.com/index.php/Category:Kbd
http://www.edm2.com/index.php/Category:Vio


Andreas Schnellbacher

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 30
  • Posts: 564
    • View Profile
Re: Observing if a program uses vio calls
« Reply #28 on: March 07, 2020, 11:25:42 am »
BTW: EPM produces this output:

Code: [Select]
epm: D:\ > dir |more
SYS0436: An invalid VIO handle was found.
SYS1805: The process tried to write to a nonexistent pipe.

epm: D:\ >

Martin Vieregg

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 8
  • Posts: 226
    • View Profile
Re: Observing if a program uses vio calls
« Reply #29 on: March 07, 2020, 11:35:49 am »
EPM does not support VIO. Even the stdin/out support is very poor. When starting a VIO program in EPM, an error message occurs (TED.EXE) or nothing happens (DFSOS2.EXE).