In <list-11710856@2rosenthals.com>, on 01/05/25 at 04:51 PM, "Peter
Moylan" <ecs-isp@2rosenthals.com> said:

Has anyone else had problems with VioWrtCharStr?

Not really.  It just works as long as you respect the limits.  As we
know a VIO app cannot have more than 256 threads.  Also since under
the covers, this is a 16-bit API, any buffers need to be in lower
memory or the thunking will fail.

The code in question is

HALT is there because I was searching for a way to discover the
value of rc, but it turns out that the exit occurs before an rc
value can be returned. The parameter values: CurrentRow=19,
CurrentColumn=0, amount is something like 50, and p points to a
character string that is guaranteed not to cross a 64K boundary in
memory.

I wonder if the modula runtime has a new to us thunking issue.

If I compare the above, to what WriteStringAt does there is a
difference. Your new code passes a pointer to a buffer.  The
WritestringAt code copies the string to the stack and passes a
pointer to a copy of the buffer on the stack.

What happens if you modify the failing code to use WriteStringAt
rather calling OS2.VioWrtCharStr?

By stepping through machine instructions I found that the problem
is somewhere in a module called BVHWNDW$, in something called from
DOSCALL1, but I haven't been able to pin it down more precisely
than that.

This makes sense if you are running your app in a VIO session.
BVHWNDW.DLL supports using VIO APIs in a VIO Session which is really
a PM window.

Will the debugger allow you to step into the BVHWNDW code?  If so,
what's the last cs:ip before the code goes away?