From: "Steven Levine" <ecs-isp@2rosenthals.com>
Message-ID: <677a3305.2.mr2ice.fgrirsq@earthlink.net>
Date: Sat, 04 Jan 2025 23:21:41 -0800
To: "eCS ISP Mailing List" <ecs-isp@2rosenthals.com>
In-Reply-To: <list-11710856@2rosenthals.com>
Subject: Re: [eCS-ISP] Getting started with Let's Encrypt

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?

Steven

-- 
----------------------------------------------------------------------
"Steven Levine" <steve53@earthlink.net>  Warp/DIY/BlueLion etc.
www.scoug.com www.arcanoae.com www.warpcave.com
----------------------------------------------------------------------