In <list-11710856@2rosenthals.com>, on 01/05/25
at 04:51 PM, "Peter Moylan" <ecs-isp@2rosenthals.com> said:
Hi Peter,
>This is a long shot. I suspect my problem is unsolvable.
Yee of little faith. :-)
>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.
>in the execution.) No trap file, no POPUPLOG entry, no symptoms at all
>except that the program exits.
That's odd. I have to suspect that the exception is hidden by one of the
PM exception handlers.
>The code in question is
> rc := OS2.VioWrtCharStr (p^, amount, CurrentRow,CurrentColumn, 0);
> IF rc <> 0 THEN
> HALT;
> END (*IF*);
>The 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?
terug naar list