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

Martin Vieregg

  • Sr. Member
  • ****
  • Posts: 278
  • Karma: +2/-0
    • View Profile
Observing if a program uses vio calls
« on: February 25, 2020, 06:49:43 pm »
In the german forum os2.org I started a thread with a problem for my PM commandline frontend, which only supports stdin and stdout, but no VIO calls. If a program writes directly into the screen buffer, my PM window does not show it. So the user has to switch between VIO and PM stdout window - I have got a button in my PM window doing that. It would be useful if the program recognizes automatically if a program which is executed via cmd.exe writes VIO output, so the VIO window could get visible automatically.

My first idea was to analyse the EXE binary and search the string VIOCALLS. In the thread, I was told that there is a better way. The program exehdr.exe from the OS/2 2.45 Toolkit in combination with the following rexx script
Code: [Select]
/* analyse executable import viocalls */
parse upper arg efn SuperfluousArguments
if (efn == '') then return

ifn = 'exehdr.txt'

'@e:\os2ddk\base32\tools\os2.386\bin\exehdr /v 'efn' > 'ifn

needle = ' imp '
do while lines(ifn) <> 0
  haystack = linein(ifn)
  there = pos(needle,haystack)
  if (there > 0) then do
    line = substr(haystack,there+length(needle))
    if (left(line,8)=='VIOCALLS') then say line
    end
  end

return

shows not only the fact that a program uses VIO calls, it shows also the number. The list of VIO calls is here:
Code: [Select]
VIOENDPOPUP             VIOCALLS   1
VIO16ENDPOPUP           VIOCALLS   1
VIOGETPHYSBUF           VIOCALLS   2
VIO16GETPHYSBUF         VIOCALLS   2
VIOGETANSI              VIOCALLS   3
VIO16GETANSI            VIOCALLS   3
VIOSETANSI              VIOCALLS   5
VIO16SETANSI            VIOCALLS   5
VIODEREGISTER           VIOCALLS   6
VIO16DEREGISTER         VIOCALLS   6
VIOSCROLLUP             VIOCALLS   7
VIO16SCROLLUP           VIOCALLS   7
VIOPRTSC                VIOCALLS   8
VIO16PRTSC              VIOCALLS   8
VIOGETCURPOS            VIOCALLS   9
VIO16GETCURPOS          VIOCALLS   9
VIOWRTCELLSTR           VIOCALLS  10
VIO16WRTCELLSTR         VIOCALLS  10
VIOPOPUP                VIOCALLS  11
VIO16POPUP              VIOCALLS  11
VIOSCROLLRT             VIOCALLS  12
VIO16SCROLLRT           VIOCALLS  12
VIOWRTCHARSTR           VIOCALLS  13
VIO16WRTCHARSTR         VIOCALLS  13
VIOSETCURPOS            VIOCALLS  15
VIO16SETCURPOS          VIOCALLS  15
VIOSCRUNLOCK            VIOCALLS  18
VIO16SCRUNLOCK          VIOCALLS  18
VIOWRTTTY               VIOCALLS  19
VIO16WRTTTY             VIOCALLS  19
VIOGETMODE              VIOCALLS  21
VIO16GETMODE            VIOCALLS  21
VIOSETMODE              VIOCALLS  22
VIO16SETMODE            VIOCALLS  22
VIOSCRLOCK              VIOCALLS  23
VIO16SCRLOCK            VIOCALLS  23
VIOREADCELLSTR          VIOCALLS  24
VIO16READCELLSTR        VIOCALLS  24
VIOSAVREDRAWWAIT        VIOCALLS  25
VIO16SAVREDRAWWAIT      VIOCALLS  25
VIOWRTNATTR             VIOCALLS  26
VIO16WRTNATTR           VIOCALLS  26
VIOGETCURTYPE           VIOCALLS  27
VIO16GETCURTYPE         VIOCALLS  27
VIOSAVREDRAWUNDO        VIOCALLS  28
VIO16SAVREDRAWUNDO      VIOCALLS  28
VIOGETFONT              VIOCALLS  29
VIO16GETFONT            VIOCALLS  29
VIOREADCHARSTR          VIOCALLS  30
VIO16READCHARSTR        VIOCALLS  30
VIOGETBUF               VIOCALLS  31
VIO16GETBUF             VIOCALLS  31
VIOSETCURTYPE           VIOCALLS  32
VIO16SETCURTYPE         VIOCALLS  32
VIOSETFONT              VIOCALLS  33
VIO16SETFONT            VIOCALLS  33
VIOMODEUNDO             VIOCALLS  35
VIO16MODEUNDO           VIOCALLS  35
VIOMODEWAIT             VIOCALLS  37
VIO16MODEWAIT           VIOCALLS  37
VIOGETCP                VIOCALLS  40
VIO16GETCP              VIOCALLS  40
VIOSETCP                VIOCALLS  42
VIO16SETCP              VIOCALLS  42
VIOSHOWBUF              VIOCALLS  43
VIO16SHOWBUF            VIOCALLS  43
VIOSCROLLLF             VIOCALLS  44
VIO16SCROLLLF           VIOCALLS  44
VIOREGISTER             VIOCALLS  45
VIO16REGISTER           VIOCALLS  45
VIOGETCONFIG            VIOCALLS  46
VIO16GETCONFIG          VIOCALLS  46
VIOSCROLLDN             VIOCALLS  47
VIO16SCROLLDN           VIOCALLS  47
VIOWRTCHARSTRATT        VIOCALLS  48
VIO16WRTCHARSTRATT      VIOCALLS  48
VIOGETSTATE             VIOCALLS  49
VIO16GETSTATE           VIOCALLS  49
VIOPRTSCTOGGLE          VIOCALLS  50
VIO16PRTSCTOGGLE        VIOCALLS  50
VIOSETSTATE             VIOCALLS  51
VIO16SETSTATE           VIOCALLS  51
VIOWRTNCELL             VIOCALLS  52
VIO16WRTNCELL           VIOCALLS  52
VIOWRTNCHAR             VIOCALLS  53
VIO16WRTNCHAR           VIOCALLS  53
VIOASSOCIATE            VIOCALLS  55
VIO16ASSOCIATE          VIOCALLS  55
VIOCREATEPS             VIOCALLS  56
VIO16CREATEPS           VIOCALLS  56
VIODELETESETID          VIOCALLS  57
VIO16DELETESETID        VIOCALLS  57
VIOGETDEVICECELLSIZE    VIOCALLS  58
VIO16GETDEVICECELLSIZE  VIOCALLS  58
VIOGETORG               VIOCALLS  59
VIO16GETORG             VIOCALLS  59
VIOCREATELOGFONT        VIOCALLS  60
VIO16CREATELOGFONT      VIOCALLS  60
VIODESTROYPS            VIOCALLS  61
VIO16DESTROYPS          VIOCALLS  61
VIOQUERYSETIDS          VIOCALLS  62
VIO16QUERYSETIDS        VIOCALLS  62
VIOSETORG               VIOCALLS  63
VIO16SETORG             VIOCALLS  63
VIOQUERYFONTS           VIOCALLS  64
VIO16QUERYFONTS         VIOCALLS  64
VIOSETDEVICECELLSIZE    VIOCALLS  65
VIO16SETDEVICECELLSIZE  VIOCALLS  65
VIOSHOWPS               VIOCALLS  66
VIO16SHOWPS             VIOCALLS  66
VIOGETPSADDRESS         VIOCALLS  67
VIO16GETPSADDRESS       VIOCALLS  67
VIOGLOBALREG            VIOCALLS  70
VIO16GLOBALREG          VIOCALLS  70
XVIOSETCASTATE          VIOCALLS  71
XVIO16SETCASTATE        VIOCALLS  71
XVIOCHECKCHARTYPE       VIOCALLS  72
XVIO16CHECKCHARTYPE     VIOCALLS  72
XVIODESTROYCA           VIOCALLS  73
XVIO16DESTROYCA         VIOCALLS  73
XVIOCREATECA            VIOCALLS  74
XVIO16CREATECA          VIOCALLS  74
VIOCHECKCHARTYPE        VIOCALLS  75
VIO16CHECKCHARTYPE      VIOCALLS  75
XVIOGETCASTATE          VIOCALLS  76
XVIO16GETCASTATE        VIOCALLS  76

But this solution anlyses only the program code and I do not know if the API calls are really exeuted. For example, XCOPY uses VIO calls, but only in very special circumstances I have not found out yet.

There is a program os2trace  which excatly makes the job I need: Observing an application and journaling which API calls it calls.

The perfect solution would be if my PM program observes the EXE file which is executed via cmd.exe in the known session which is controlled by my program like os2trace does. Is the author Dave Blaschke still acitive? Perhaps he or someone can explain or help me with the code I need. I would need a simple C or Pascal commandline program which observes a specific binary and gets an output "VIOCALL used!" if a VIOcall is sent. Then I could copy these lines into my PM program in an own thread.
« Last Edit: February 25, 2020, 06:59:17 pm by Martin Vieregg »

Laurence Pithie

  • Jr. Member
  • **
  • Posts: 62
  • Karma: +1/-0
    • View Profile
Re: Observing if a program uses vio calls
« Reply #1 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.
« Last Edit: February 26, 2020, 01:58:52 pm by Laurence Pithie »

Martin Vieregg

  • Sr. Member
  • ****
  • Posts: 278
  • Karma: +2/-0
    • View Profile
Re: Observing if a program uses vio calls
« Reply #2 on: February 26, 2020, 05:36:53 pm »
Laurence,

yes, that idea is very useful for my purpose ! VioGetCurPos requires a VIO handle. I have got a window handle and a session ID. How can I get the VIO handle?

Laurence Pithie

  • Jr. Member
  • **
  • Posts: 62
  • Karma: +1/-0
    • View Profile
Re: Observing if a program uses vio calls
« Reply #3 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.

Martin Vieregg

  • Sr. Member
  • ****
  • Posts: 278
  • Karma: +2/-0
    • View Profile
Re: Observing if a program uses vio calls
« Reply #4 on: February 26, 2020, 10:56:27 pm »
Quote
Your helper application isn't a presentation manager application, so the VioHandle should be zero.

Ah, yes, the helper application! Then I can simply use semaphores again. So I see three ways for doing the job:

(1) I create a thread in the helper program which always queries VioGetCurPos (e.g. 4 times every second, with a DosSleep in the loop) and observes the changes of the cursor position. If a change has been observed, it sends a message via semaphores to the PM application.

(2) The timer (not an additional thread) is in the PM application and it sends a query to the helper via semaphores. This query is only sent if some conditions are true
(a) a command is running (not prompt state)
(b) the application uses VIO calls
(c) no output is received for e.g. 1/4 or 1/2 seconds.
I think it won't be necessary to check all conditions. The helper remembers the last query and compares it with the new query. The helper sends the result back to the PM application via semaphores.

(3) In the case of the possibility that the PM helper can query directly the VIO handle (from "outside"), I would prefer the short way without helper app because it is easier to program.

But anyway, it seems that a clean solution will be definitely possible! What solution would be preferable in your opinion? Option (2) has different possibilities. So we have to discuss (b) if a VIO call analyzation of the binary is still necessary or can be resigned, because the curorpos query via helper needs less processor power.  Also condition (c) is to discuss. If a program generates both VIO output and stdout, it would be better to show both windows? It can happen that an application creates very fast some lines of VIO output and ends again. Perhaps some user settings would be helpful.

Laurence Pithie

  • Jr. Member
  • **
  • Posts: 62
  • Karma: +1/-0
    • View Profile
Re: Observing if a program uses vio calls
« Reply #5 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.
« Last Edit: February 27, 2020, 10:08:28 am by Laurence Pithie »

Martin Vieregg

  • Sr. Member
  • ****
  • Posts: 278
  • Karma: +2/-0
    • View Profile
Re: Observing if a program uses vio calls
« Reply #6 on: February 27, 2020, 11:08:13 am »
OK. I see it clear now and I think this should work:

1. Storing VIO cursor position before exeuting the command
The user presses ENTER in the editor main thread to send the new command to cmd.exe. The editor posts a semaphore "helper, please tell me the current VIO cursor position". I can use the semaphore I already use for the Ctrl-C exception because both posts are from the editor main thread. Then the helper queries the cursor position via "VioGetCurPos" and sends the information immediately back to the editor thread which waits for a second new semaphore in a thread. The data is hold in Shared Memory which I already have. Now the editor sends the user input to cmd.exe stdin (and not before receiving the cursor position from the helper to avoid a race problem).

2. Observing while executing
In a specific frequency (e.g. I have got already a timer with 250 ms), the editor asks the helper about the current cursor position in the VIO window (same procedure as 1.). If the x or y values have changed, the VIO window gets popped up.
This query only gets executed if there is currently no output received in the editor and/or if an EXE file is executed which has got VIO calls.

3. Observing when the command execution ends
If a prompt is shown again in the editor and the current command has ended execution, a last query of the VIO cursor position gets started. If there's a change of the VIO cursor position, the VIO window gets popped up. While the editor waits for user input (prompt state), no timer query to the helper proceeds.

So for me it seems, that in Point 2., it is sufficient to observe a coming input, so analyzing the EXE binaries gets obsolete which is a lot of problematic code (observing the execution of cmd files) I do not need anymore and is not programmed yet anyway.

In my opinion, this is a real perfect solution. If the executed command creates both VIO and Stdout, the VIO window is shown in any case when ending the command execution. In this case, I can program the VIO window position beneath the editor window so the user can see both outputs. So it is absolutely precluded that the user does not see a VIO output.
« Last Edit: February 27, 2020, 11:18:01 am by Martin Vieregg »

Laurence Pithie

  • Jr. Member
  • **
  • Posts: 62
  • Karma: +1/-0
    • View Profile
Re: Observing if a program uses vio calls
« Reply #7 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

Martin Vieregg

  • Sr. Member
  • ****
  • Posts: 278
  • Karma: +2/-0
    • View Profile
Re: Observing if a program uses vio calls
« Reply #8 on: February 27, 2020, 12:58:51 pm »
Quote
2. Don't observe while executing, the PM app should care about output

Laurence, so in your opinion the loop/timer which continously queries the VIO cursor position should be placed in the helper app. Because non-PM programs do not know timer events, I have to create a thread with a DosSleep loop and continous querying VioGetCurPos. This only proceeds if the PM editor tells the helper doing so. If the prompt appears again in the PM editor, the editor tells the helper "tell me if the VIO cursor position has changed and end the loop."

Laurence Pithie

  • Jr. Member
  • **
  • Posts: 62
  • Karma: +1/-0
    • View Profile
Re: Observing if a program uses vio calls
« Reply #9 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.
« Last Edit: February 27, 2020, 09:28:46 pm by Laurence Pithie »

Martin Vieregg

  • Sr. Member
  • ****
  • Posts: 278
  • Karma: +2/-0
    • View Profile
Re: Observing if a program uses vio calls
« Reply #10 on: February 28, 2020, 10:09:00 am »
Laurence, thank you for reasoning. Most things are congruent with my ideas, but I think that you have one circumstance not in view.
Quote
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.
If a VIO program waits for user input (e.g. a VIO-based editor or a menu program like DFSEE), I need a loop with continous querying. After again thinking about the problem, I have got this result: The PM editor has to send two kinds of queries to the helper:
1. A single query after a current command execution ends and a prompt is shown again: "Please tell me if VIO (cursor position) has changed and end the loop, if it is running".
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.
An option to optimize is to check whether the output contains Returns without Carriage (^M only without ^J). This output is typical for progress bars of stdout programs. In this case, a continous VIO observation is not necessary in my opinion. The editor knows it already.

This is all quite simple to program for me, because a lot of stuff can be reused: For the post from the PM window to the helper, I can use the semaphore and Shared Memory I use for the Ctrl-C exception. Then in the PM editor I have one unused thread left which starts the helper. I can add here a wait for semaphore loop. I have not to submit any data from the helper to the PM editor, I have only to wait for the semaphore event "pop VIO window now". This semaphore event is used in both cases 1. and 2.
So I will need a new semaphore. I will generate the semaphore fin the PM editor, the pointer value is submitted via commandline parameter to the helper again. Then I need a new thread in the helper executing the loop.

Two minor questions:
In the helper, I can recreate the thread if needed or suspend/resume the old thread. (Any ideas what is to prefer?)
When creating the new second semaphore, I hope that it is allowed that the receiver creates the semaphore? Normally the sender creates it. The way via commandline parameters to submit the pointer value is very easy for me.

Laurence Pithie

  • Jr. Member
  • **
  • Posts: 62
  • Karma: +1/-0
    • View Profile
Re: Observing if a program uses vio calls
« Reply #11 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.

Martin Vieregg

  • Sr. Member
  • ****
  • Posts: 278
  • Karma: +2/-0
    • View Profile
Re: Observing if a program uses vio calls
« Reply #12 on: February 28, 2020, 04:30:08 pm »
If I exeute a binary directly, in most cases there comes VIO output immediately (I have no sample, but it can be different, too, that it first generates some stdout output "starting my app... please wait" and then switches to VIO, and after finishing VIO, some stdout is created (which wouldn't be a problem for me). In most cases, a first query after 400 ms without stdout output should be sufficient.

More sophisticated is the case of executing a cmd file. We discussed the case of sending the cmd file content line by line to cmd.exe stdin and the PM editor checks whether there's a VIO program in the sent text line or not. (We want to avioid this procedure.) I have got big cmd files in use which runs two minutes. It can happen that in such a long cmd file, a VIO program is placed between other stdout programs and commands.

Meanwhile, I have doubt, too, that a loop within the helper app is really useful. Instead, the PM editor could send a single query "VIO cursor position changed?" after 300-400 ms after the last received stdout. And if nothing happens at all - in the case the helper detects no VIO program and there's no stdout output anyway for seconds - the editor does not query anymore. Only if there's a new stdout output and a pause again, then it queries again. So the case of a cmd file should be covered.

In this case, I do not need a thread in the helper program which simplifies the code. No thread, no problem in suspending, resuming, memory access conflicts to consider and so on.

Martin Vieregg

  • Sr. Member
  • ****
  • Posts: 278
  • Karma: +2/-0
    • View Profile
Re: Observing if a program uses vio calls
« Reply #13 on: March 01, 2020, 09:19:20 am »
I began to program now and I have found a suspect difference between headers of VioGetCurPos:

in
http://www.edm2.com/index.php/VioGetCurPos
the second parameter Row is PULONG, but in my header file (Borland C 2.0), the header file is defined as PUSHORT16. What is correct now? Can someone take a look at a current development environment (Open Watcom?) in bsesub.h ? Thank you.

Wim Brul

  • Sr. Member
  • ****
  • Posts: 295
  • Karma: +25/-0
    • View Profile
    • Wim's home page
Re: Observing if a program uses vio calls
« Reply #14 on: March 01, 2020, 10:30:46 am »
I began to program now and I have found a suspect difference between headers of VioGetCurPos:

in
http://www.edm2.com/index.php/VioGetCurPos
the second parameter Row is PULONG, but in my header file (Borland C 2.0), the header file is defined as PUSHORT16. What is correct now? Can someone take a look at a current development environment (Open Watcom?) in bsesub.h ? Thank you.

PULONG for Row in the wiki is definitely  wrong. It must be USHORT. I will change it in the wiki accordingly.

EDIT: Now I am not so sure anymore. I see VioGetCurPos and VioGetCurPos (FAPI) in the wiki. I am used to code my VIO calls as to the FAPI definitions, which is 16 bit source code. That VioGetCurPos (FAPI) definition is correct. It seems to me that the VioCurPos definition applies to 32 bit source code. Hence PULONG seems to be correct for its Row and Column parameters.

EDIT: I know better now. Therefore I have undone my wiki changes.
« Last Edit: March 05, 2020, 10:14:45 am by Wim Brul »