I made another attempt to get PDPCLIB to work
under VIO instead of requiring fullscreen.

This guy had the exact same problem in 1996:

https://groups.google.com/g/comp.os.os2.programmer.misc/c/59LqqodyzMo/m/eidgva-x0d8J

but no-one seems to have answered him (or else
the replies weren't archived).

Anyway, during one of my experiments I managed
to crash ArcaOS 5.0.8:

https://mantis.arcanoae.com/view.php?id=3604

I have attempted to create a logical keyboard,
but that isn't working under VIO (error 22
about PM), and in fullscreen it crashes ArcaOS
so I have paused before I try anything else.

BFN. Paul.

On February 15, 2024 at 06:13:48 +0100 user Paul Edwards wrote:
> I made another attempt to get PDPCLIB to work
> under VIO instead of requiring fullscreen.
>
> This guy had the exact same problem in 1996:
>
> https://groups.google.com/g/comp.os.os2.programmer.misc/c/59LqqodyzMo/m/eidgva-x0d8J
>
> but no-one seems to have answered him (or else
> the replies weren't archived).
>
> Anyway, during one of my experiments I managed
> to crash ArcaOS 5.0.8:
>
> https://mantis.arcanoae.com/view.php?id=3604
>
> I have attempted to create a logical keyboard,
> but that isn't working under VIO (error 22
> about PM), and in fullscreen it crashes ArcaOS
> so I have paused before I try anything else.

While your persistance is admirable, I still miss the point why you decided using the more low-level access via the device driver rather than using the regularly supported means for accessing the keyboard inteded for VIO applications. Function KbdPeek, KbdCharIn and KbdGetStatus as provided in KbdCalls.dll provide (after proper initialization, setting the keyboard focus, etc.) full support for reading the keys and modifiers (i.e. shift, etc.) without any echo. Yes, you cannot treat the keyboard as a file in that case (i..e. you cannot use DosRead for retrieving the keys, etc.), but that is comparable to BIOS functions needed under plain DOS. And, obviously, the KbdCalls functions work both in full-screen and in VIO windows (except for minor documented exceptions which shouldn't be necessary for your purposes as far as I understand them).

Tomas

On 15/02/24 20:16, xhajt03 wrote:
> On February 15, 2024 at 06:13:48 +0100 user Paul Edwards wrote:

>> I have attempted to create a logical keyboard,
>> but that isn't working under VIO (error 22
>> about PM), and in fullscreen it crashes ArcaOS
>> so I have paused before I try anything else.
>
> While your persistance is admirable, I still miss

BTW, you wrote one very long line in this newsgroup
post instead of splitting it up. I have to manually
split it up instead.

> the point why you decided using the more low-level
> access via the device driver rather than using the
> regularly supported means for accessing the keyboard
> inteded for VIO applications. Function KbdPeek,
> KbdCharIn and KbdGetStatus as provided in KbdCalls.dll
> provide (after proper initialization, setting the
> keyboard focus, etc.) full support for reading the
> keys and modifiers (i.e. shift, etc.) without any echo.

I want to have a pure 32-bit executable.

> Yes, you cannot treat the keyboard as a file in that
> case (i.e. you cannot use DosRead for retrieving the
> keys, etc.), but that is comparable to BIOS functions
> needed under plain DOS.

You don't need to use the BIOS functions in plain DOS
to do the above.

So in that sense - yes, it is directly comparable.

My C library - PDPCLIB - doesn't use any BIOS calls,
and it is able to run micro-emacs etc.

> And, obviously, the KbdCalls functions work both in
> full-screen and in VIO windows (except for minor
> documented exceptions which shouldn't be necessary
> for your purposes as far as I understand them).

And I believe IBM intended that the 32-bit functions
they provided would be sufficient to do the job
instead. And it just didn't happen much for other
reasons.

And note that the functions they provided *do* do
the job in 32-bit. It's only when the program
terminates that I find I have an issue.

So they come very very close to working.

BTW, I'm not familiar with privilege levels in OS/2,
but I haven't done anything to attempt to get into
any sort of privileged mode.

It could be that the accessing of KBD$ is throwing
me into a privileged state regardless.

But maybe the 16-bit Kbd* functions do that too.

Maybe there's no security in OS/2 - I've never
asked the question.

BFN. Paul.

On February 15, 2024 at 14:28:26 +0100 Paul Edwards wrote:

.
.
> BTW, you wrote one very long line in this newsgroup
> post instead of splitting it up. I have to manually
> split it up instead.

Well, sorry. I'm responding to these Usenet messages via Google Groups (which will stop working in one week from now :-( ). I don't have any Usenet client installed.

.
.
> I want to have a pure 32-bit executable.

I see. You can have that if you use a 3rd party DLL providing the translation from/to the 16-bit calls, but you'd probably need to distribute those with your application(s). There are multiple options for such a DLL, one of them being emxwrap.dll (part of the EMX runtime, already available on many OS/2 installations), but there are others (see e.g. https://hobbes.nmsu.edu/?detail=%2Fpub%2Fos2%2Fdev%2Ftools%2Ftoolkits%2FUniConAPI_1-0-3.zip).

> > Yes, you cannot treat the keyboard as a file in that
> > case (i.e. you cannot use DosRead for retrieving the
> > keys, etc.), but that is comparable to BIOS functions
> > needed under plain DOS.
> You don't need to use the BIOS functions in plain DOS
> to do the above.

Well, yes, you can access the modifiers by accessing the low part of the memory (modified by BIOS) there. ;-)

.
.
> > And, obviously, the KbdCalls functions work both in
> > full-screen and in VIO windows (except for minor
> > documented exceptions which shouldn't be necessary
> > for your purposes as far as I understand them).
> And I believe IBM intended that the 32-bit functions
> they provided would be sufficient to do the job
> instead. And it just didn't happen much for other
> reasons.

Not really, because they clearly documented a different solution (in particular using KbdCalls) as intended for scenarios described by you. Also, the fact that the (beta) PowerPC version of OS/2 included a 32-bit version of KbdCalls kind of suggests that they didn't consider other solutions as directly replacing this DLL. Not that it matters much nowadays. ;-)

> And note that the functions they provided *do* do
> the job in 32-bit. It's only when the program
> terminates that I find I have an issue.
>
> So they come very very close to working.

OK. Even if you get it fully working, it doesn't mean that it's the most efficient solution.

> BTW, I'm not familiar with privilege levels in OS/2,
> but I haven't done anything to attempt to get into
> any sort of privileged mode.

Accessing the 16-bit calls requires the specific binary (e.g. a DLL) to be marked for privilege level 2 (IOPL), but you don't need to bother with that when using a translation library like one of those mentioned above (and it doesn't mean much for you otherwise except for a necessity to have the right flag in the respective executable header).

> It could be that the accessing of KBD$ is throwing
> me into a privileged state regardless.

The device driver works at a higher privilege level, but the code accessing the logical device (e.g. KBD$) doesn't.

> But maybe the 16-bit Kbd* functions do that too.

See above.

> Maybe there's no security in OS/2 - I've never
> asked the question.

If you refer to privilege levels specifically, these are for sure enforced in OS/2. Talking about OS/2 security in other contexts would go beyond the scope of this thread considerably.

Tomas

On 15/02/24 22:47, xhajt03 wrote:
> On February 15, 2024 at 14:28:26 +0100 Paul Edwards wrote:

>> BTW, you wrote one very long line in this newsgroup
>> post instead of splitting it up. I have to manually
>> split it up instead.
>
> Well, sorry. I'm responding to these Usenet messages
> via Google Groups (which will stop working in one
> week from now :-( ).

I used to use that too. Just hit enter after a while.

> I don't have any Usenet client installed.

Don't you use ArcaOS? It comes with Thunderbird.

You can get a free account here:

https://www.eternal-september.org/

>> I want to have a pure 32-bit executable.
>
> I see. You can have that if you use a 3rd party DLL
> providing the translation from/to the 16-bit calls,
> but you'd probably need to distribute those with
> your application(s).

And I don't want to do that either.

Or if I was to do that, the 3rd party DLL would
be called PDPCRT.DLL and it would be comprised
of pure 32-bit pure public domain code from
PDPCLIB. I already produce my own msvcrt.dll too,
but it's normally not used.

>>> Yes, you cannot treat the keyboard as a file in that
>>> case (i.e. you cannot use DosRead for retrieving the
>>> keys, etc.), but that is comparable to BIOS functions
>>> needed under plain DOS.

>> You don't need to use the BIOS functions in plain DOS
>> to do the above.
>
> Well, yes, you can access the modifiers by accessing
> the low part of the memory (modified by BIOS) there. ;-)

No. You don't need to do that either. You can
follow pure MSDOS rules and do INT 21H calls
(ioctl and read).

> Not really, because they clearly documented a
> different solution (in particular using KbdCalls)
> as intended for scenarios described by you.

Well they did that for OS/2 1.x, and so at that
point there was a 16-bit solution, and of course
it was documented.

For 32-bit they apparently updated what they
thought was enough and then stopped. And it
may well be enough. Or they came very very
close, anyway.

> Also, the fact that the (beta) PowerPC version
> of OS/2 included a 32-bit version of KbdCalls
> kind of suggests that they didn't consider other
> solutions as directly replacing this DLL.

Well, they would have needed to do that for the
other documented solution to work.

They're not going to force everyone to migrate
to the alternate solution immediately.

And maybe not force it ever. Maybe in time they
would have updated the 16-bit x86 versions to
32-bit. But it was not a priority at all because
by then they were more interested in graphics.

>> So they come very very close to working.
>
> OK. Even if you get it fully working, it doesn't
> mean that it's the most efficient solution.

I'm not after the most efficient solution, nor
the solution (graphics) that will attract the
most customers.

I'm after a technically pure 32-bit application.

And I may produce my own version of OS/2 2.0
(similar to PDOS/386 being a mini Win32 clone).

I'm actually planning on converting PDOS/86 to
be a mini OS/2 1.x clone and abandoning MSDOS.

Or I may do the opposite of win32os2 - and run
OS/2 2.0 programs under Win32. Certain OS/2
programs. Ones that are dependent on pdpcrt.dll.
Although that last one would still work if it
was implemented using the 16-bit calls internally.

>> BTW, I'm not familiar with privilege levels in OS/2,
>> but I haven't done anything to attempt to get into
>> any sort of privileged mode.
>
> Accessing the 16-bit calls requires the specific
> binary (e.g. a DLL) to be marked for privilege
> level 2 (IOPL), but you don't need to bother with
> that when using a translation library like one
> of those mentioned above (and it doesn't mean much
> for you otherwise except for a necessity to have
> the right flag in the respective executable header).

One of my experiments involved calling the Kbd calls.
I was using the Watcom compiler and libraries for
that, and it produced a standalone executable. Would
that executable have been marked as level 2?

And when I switched to pure dos calls, would the
executable have not had that marker?

>> It could be that the accessing of KBD$ is throwing
>> me into a privileged state regardless.
>
> The device driver works at a higher privilege level,
> but the code accessing the logical device (e.g. KBD$) doesn't.

Ok, cool. I didn't want to have privileged code.

> If you refer to privilege levels specifically,
> these are for sure enforced in OS/2.

Ok, thanks for the info.

> Talking about OS/2 security in other contexts
> would go beyond the scope of this thread considerably.

Yeah, I'm not interested in security - just wanted
to make sure I was unprivileged.

BFN. Paul.

On February 15, 2024 at 16:23:54 +0100 Paul Edwards wrote:
.
.
> Don't you use ArcaOS? It comes with Thunderbird.

No, I use eCS (among others). I know I could install TB (on all my machines.... :/ ).

> You can get a free account here:
>
> https://www.eternal-september.org/

Thanks for the link.

.
.
> One of my experiments involved calling the Kbd calls.
> I was using the Watcom compiler and libraries for
> that, and it produced a standalone executable. Would
> that executable have been marked as level 2?

Actually, I was wrong, you don't need that for the 16-bit calls, sorry for the confusion. :-( I mixed it up with another functionality for which EMX run-time libraries might be used, in particular port access (level 2 allows that, level 3 doesn't). In other words, you can stay at level 3 all the time, regardless from being pure 32-bit code or calling 16-bit API functions via thunking.

Regards

Tomas

xhajt03 wrote:
> On February 15, 2024 at 16:23:54 +0100 Paul Edwards wrote:
> .
> .
>> Don't you use ArcaOS? It comes with Thunderbird.
>
> No, I use eCS (among others). I know I could install TB (on all my machines... :/ ).

SeaMonkey works fine for news groups as well. For eCS, TB10 or TB17 or
the equivalent SM would be the simplest to install.

>
>
>> You can get a free account here:
>>
>> https://www.eternal-september.org/
>
> Thanks for the link.
>
>
> .
> .
>> One of my experiments involved calling the Kbd calls.
>> I was using the Watcom compiler and libraries for
>> that, and it produced a standalone executable. Would
>> that executable have been marked as level 2?
>
> Actually, I was wrong, you don't need that for the 16-bit calls, sorry for the confusion. :-( I mixed it up with another functionality for which EMX run-time libraries might be used, in particular port access (level 2 allows that, level 3 doesn't). In other words, you can stay at level 3 all the time, regardless from being pure 32-bit code or calling 16-bit API functions via thunking.
>

You can set PROTECTONLY=YES in config.sys to enforce level 3.
Dave

Paul Edwards wrote:
> On 15/02/24 20:16, xhajt03 wrote:
>> On February 15, 2024 at 06:13:48 +0100 user Paul Edwards wrote:
....
>> the point why you decided using the more low-level
>> access via the device driver rather than using the
>> regularly supported means for accessing the keyboard
>> inteded for VIO applications. Function KbdPeek,
>> KbdCharIn and KbdGetStatus as provided in KbdCalls.dll
>> provide (after proper initialization, setting the
>> keyboard focus, etc.) full support for reading the
>> keys and modifiers (i.e. shift, etc.) without any echo.
>
> I want to have a pure 32-bit executable.

You can't, at least easily. Too much of the kernel(DOSCALL) and DOSCALL1
are 16 bit at their heart. This includes DosOpen() and DosOpenL() and
even DosDevIOCtl() or parts of it.
They do have 32 bit wrappers so they seem like 32 bit code but will fail
if you try to use them from high memory (above 1GB).
Search for os2safe.h for the full list of functions that need special
treatment if using high memory.
The simplest I found was KbdCharIn(), which libc wraps in a 32 bit
wrapper, likely the same as EMX. Even that spat out a scan code before
any chars IIRC.

>
>> Yes, you cannot treat the keyboard as a file in that
>> case (i.e. you cannot use DosRead for retrieving the
>> keys, etc.), but that is comparable to BIOS functions
>> needed under plain DOS.
>
> You don't need to use the BIOS functions in plain DOS
> to do the above.
>
> So in that sense - yes, it is directly comparable.
>
> My C library - PDPCLIB - doesn't use any BIOS calls,
> and it is able to run micro-emacs etc.
>
>> And, obviously, the KbdCalls functions work both in
>> full-screen and in VIO windows (except for minor
>> documented exceptions which shouldn't be necessary
>> for your purposes as far as I understand them).
>
> And I believe IBM intended that the 32-bit functions
> they provided would be sufficient to do the job
> instead. And it just didn't happen much for other
> reasons.

Unluckily they never finished porting the functions to 32 bit on X86.
There was a rumour that one of the devcon ISO's included 32 bit
versions. All I found were official wrappers to emulate the pure 32 bit
libraries when/if they got ported from the PowerPC OS/2. They never did
get ported.

>
> And note that the functions they provided *do* do
> the job in 32-bit. It's only when the program
> terminates that I find I have an issue.
>
> So they come very very close to working.

You are staying below the 1GB barrier? I think you mentioned OW1.6 which
didn't have much support for high memory IIRC.

>
> BTW, I'm not familiar with privilege levels in OS/2,
> but I haven't done anything to attempt to get into
> any sort of privileged mode.
>
> It could be that the accessing of KBD$ is throwing
> me into a privileged state regardless.
>
> But maybe the 16-bit Kbd* functions do that too.
>
> Maybe there's no security in OS/2 - I've never
> asked the question.

User programs run in Ring 3 or Ring 2 in the case of DOS. Ring 2 so most
DOS device drivers work. Drivers and Kernel often in Ring 0.
Dave

On 16/02/24 09:38, Dave Yeo wrote:
> Paul Edwards wrote:

>>> the point why you decided using the more low-level
>>> access via the device driver rather than using the
>>> regularly supported means for accessing the keyboard
>>> inteded for VIO applications. Function KbdPeek,
>>> KbdCharIn and KbdGetStatus as provided in KbdCalls.dll
>>> provide (after proper initialization, setting the
>>> keyboard focus, etc.) full support for reading the
>>> keys and modifiers (i.e. shift, etc.) without any echo.
>>
>> I want to have a pure 32-bit executable.
>
> You can't, at least easily. Too much of the kernel(DOSCALL) and DOSCALL1
> are 16 bit at their heart. This includes DosOpen() and DosOpenL() and
> even DosDevIOCtl() or parts of it.

That is external to my executable. My executable
itself is 32-bit. I don't really care what OS/2
itself does internally. Note that PDOS/386 itself
transitions to RM16 in order to do I/O so that I
don't need to deal with drivers. That's fine too.
It's completely transparent to the applications.
The applications themselves are pure 32-bit. And
at any time PDOS/386 can be updated to use drivers
so that the 16-bit stuff is eliminated. That would
be transparent to the application.

> They do have 32 bit wrappers so they seem like 32 bit code

That's all I'm after. With the vendor providing
that, not a 3rd party.

> but will fail
> if you try to use them from high memory (above 1GB).
> Search for os2safe.h for the full list of functions that need special
> treatment if using high memory.

This is a deficiency in OS/2 itself that could
be corrected overnight by Arca. I will patiently
wait for Arca, or else replace ArcaOS with an
updated PDOS/386 that handles OS/2 2.0 calls.

>>> And, obviously, the KbdCalls functions work both in
>>> full-screen and in VIO windows (except for minor
>>> documented exceptions which shouldn't be necessary
>>> for your purposes as far as I understand them).
>>
>> And I believe IBM intended that the 32-bit functions
>> they provided would be sufficient to do the job
>> instead. And it just didn't happen much for other
>> reasons.
>
> Unluckily they never finished porting the functions to 32 bit on X86.
> There was a rumour that one of the devcon ISO's included 32 bit
> versions. All I found were official wrappers to emulate the pure 32 bit
> libraries when/if they got ported from the PowerPC OS/2. They never did
> get ported.

Yeah, that's fine. That's an internal thing that
can happen at any time (even if it never happens
at all).

It doesn't detract from the technical purity that
I am after.

>> And note that the functions they provided *do* do
>> the job in 32-bit. It's only when the program
>> terminates that I find I have an issue.
>>
>> So they come very very close to working.
>
> You are staying below the 1GB barrier? I think you mentioned OW1.6 which
> didn't have much support for high memory IIRC.

I am not familiar with any of that. I wasn't aware
of a barrier. But such a barrier can be lifted by
the OS/2 vendor whenever they have bandwidth.

My executable is "4 GiB-ready" (similar to 4k-ready
for sector sizes).

> User programs run in Ring 3 or Ring 2 in the case of DOS. Ring 2 so most
> DOS device drivers work. Drivers and Kernel often in Ring 0.

Ok, and that protectonly in config.sys would force
apps to be in the lowest ring 3?

But my 32-bit OS/2 executable would be ring 3 by
default and stay there unless I go to some effort
to elevate it, right?

That's all I'm after.

Thanks. Paul.

Paul Edwards wrote:

....
>> You are staying below the 1GB barrier? I think you mentioned OW1.6 which
>> didn't have much support for high memory IIRC.
>
> I am not familiar with any of that. I wasn't aware
> of a barrier. But such a barrier can be lifted by
> the OS/2 vendor whenever they have bandwidth.

The problem is 16 bit code is limited to addressing the lower 1GB of
address space. Before Warp 4.5 (V4+fp13), the client was limited to 512
MB's of address space, minus whatever DLL's were loaded, with the other
512MB's kernel space.
Now, by adding objany to DosAllocMem, can access most of the full 32 bit
address space, minus PCI space. VIRTUALADDRESSLIMIT in config.sys
actually controls address space, with 3072 as high as it will go. Often
need a lower setting to avoid PCI address space, things like video memory.
The fix would be redoing doscall1.dll.

>
> My executable is "4 GiB-ready" (similar to 4k-ready
> for sector sizes).
>
>> User programs run in Ring 3 or Ring 2 in the case of DOS. Ring 2 so most
>> DOS device drivers work. Drivers and Kernel often in Ring 0.
>
> Ok, and that protectonly in config.sys would force
> apps to be in the lowest ring 3?

Yes, no DOS support. Not sure about OS/2 1.x programs and whether any
would be affected.

>
> But my 32-bit OS/2 executable would be ring 3 by
> default and stay there unless I go to some effort
> to elevate it, right?

I don't think you can elevate it even if you try.

>
> That's all I'm after.

Dave

On 17/02/24 07:05, Dave Yeo wrote:

>>> You are staying below the 1GB barrier? I think you mentioned OW1.6 which
>>> didn't have much support for high memory IIRC.
>>
>> I am not familiar with any of that. I wasn't aware
>> of a barrier. But such a barrier can be lifted by
>> the OS/2 vendor whenever they have bandwidth.
>
> The problem is 16 bit code is limited to addressing the lower 1GB of
> address space. Before Warp 4.5 (V4+fp13), the client was limited to 512
> MB's of address space, minus whatever DLL's were loaded, with the other
> 512MB's kernel space.
> Now, by adding objany to DosAllocMem, can access most of the full 32 bit

Ok, so let's say I add something here:

D:\devel\pdos\pdpclib>grep DosAllocMem stdlib.c
stdlib.c: rc = DosAllocMem(&BaseAddress, ulObjectSize,
ulAllocationFlags);

D:\devel\pdos\pdpclib>grep ulAllocationFlags stdlib.c
stdlib.c: ULONG ulAllocationFlags;
stdlib.c: ulAllocationFlags = PAG_COMMIT | PAG_WRITE | PAG_READ;
stdlib.c: rc = DosAllocMem(&BaseAddress, ulObjectSize,
ulAllocationFlags);

D:\devel\pdos\pdpclib>

so that I start getting high memory, e.g. I might get
an address at the 2 GiB mark.

And then let's say I put in a filename at that address.

And then I give that filename as a parameter to DosOpen.

You mentioned that DosOpen had 16-bit stuff at its heart.

Does that mean DosOpen won't be able to cope with me
giving it that high address and crash?

> address space, minus PCI space. VIRTUALADDRESSLIMIT in config.sys
> actually controls address space, with 3072 as high as it will go. Often
> need a lower setting to avoid PCI address space, things like video memory.
> The fix would be redoing doscall1.dll.

Sure. I'm exactly preparing for the vendor to fix all that.

BFN. Paul.

On 15/02/24 23:23, Paul Edwards wrote:

> I'm after a technically pure 32-bit application.
>
> And I may produce my own version of OS/2 2.0
> (similar to PDOS/386 being a mini Win32 clone).
>
> Or I may do the opposite of win32os2 - and run
> OS/2 2.0 programs under Win32. Certain OS/2
> programs. Ones that are dependent on pdpcrt.dll.
> Although that last one would still work if it
> was implemented using the 16-bit calls internally.

Ok, there has been a development.

The author of pdld has agreed to support the output
of OS/2 2.0 LX executables if I add load support for
them in exeload.c (of PDOS/386).

And I have similar plans for ELF, now that I know
how to read command line parameters via a method
other than an unusual stack (which PDOS/386 doesn't
provide).

And thanks to my OS/2 2.0 executables being pure
32-bit that are only dependent on doscalls, I can
intercept at the doscalls level.

And I maintain a variation of gcc 3.2.3 for Windows
that should also be suitable for OS/2 2.0.

And we also have an assembler that is sufficiently
masm-compatible.

So put it all together and we should be able to
stand up a self-hosting mini clone of OS/2 2.0.

Not what I originally set out to do.

But my goals have always been vague and more of
a "see what happens if I do this".

Pushing onto the Amiga, and onto 16-bit MSDOS
and OS/2 in the end gave me a model that applied
to 64-bit too.

Here is the code that needs to be updated if
anyone else is interested (all code needs to
be explicit public domain though):

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/bios/exeload.c

Executables will need to have relocation information
in order to work in a PDOS/386 environment.

BFN. Paul.

On 17/02/24 16:58, Paul Edwards wrote:

> So put it all together and we should be able to
> stand up a self-hosting mini clone of OS/2 2.0.

And I just realized that I can have a mini clone
of Linux the same way.

And I think the malloc kludge that I implemented
for Linux won't be an issue either if I introduce
msvcrt.dll.

Even without that, it would still be possible,
just chew up more memory I think.

All rolled into a single PDOS/386.

BFN. Paul.

Paul Edwards wrote:
> On 17/02/24 07:05, Dave Yeo wrote:
>
>>>> You are staying below the 1GB barrier? I think you mentioned OW1.6
>>>> which
>>>> didn't have much support for high memory IIRC.
>>>
>>> I am not familiar with any of that. I wasn't aware
>>> of a barrier. But such a barrier can be lifted by
>>> the OS/2 vendor whenever they have bandwidth.
>>
>> The problem is 16 bit code is limited to addressing the lower 1GB of
>> address space. Before Warp 4.5 (V4+fp13), the client was limited to 512
>> MB's of address space, minus whatever DLL's were loaded, with the other
>> 512MB's kernel space.
>> Now, by adding objany to DosAllocMem, can access most of the full 32 bit
>
> Ok, so let's say I add something here:
>
> D:\devel\pdos\pdpclib>grep DosAllocMem stdlib.c
> stdlib.c: rc = DosAllocMem(&BaseAddress, ulObjectSize,
> ulAllocationFlags);
>
> D:\devel\pdos\pdpclib>grep ulAllocationFlags stdlib.c
> stdlib.c: ULONG ulAllocationFlags;
> stdlib.c: ulAllocationFlags = PAG_COMMIT | PAG_WRITE | PAG_READ;
> stdlib.c: rc = DosAllocMem(&BaseAddress, ulObjectSize,
> ulAllocationFlags);
>
> D:\devel\pdos\pdpclib>
>
>
> so that I start getting high memory, e.g. I might get
> an address at the 2 GiB mark.

No, you won't get an address higher then 512MB, you need this for
allocating high memory,
stdlib.c: ulAllocationFlags = OBJ_ANY | PAG_COMMIT | PAG_WRITE |
PAG_READ;

>
> And then let's say I put in a filename at that address.
>
> And then I give that filename as a parameter to DosOpen.
>
> You mentioned that DosOpen had 16-bit stuff at its heart.
>
> Does that mean DosOpen won't be able to cope with me
> giving it that high address and crash?

I believe so. With GCC, there is os2safe.h which has this,
#define DosOpen SafeDosOpen
#define DosOpenL SafeDosOpenL
with the SafeDosOpen being a wrapper to handle the case of high memory.
DosOpenL() is used for files larger then 2GB

>
>> address space, minus PCI space. VIRTUALADDRESSLIMIT in config.sys
>> actually controls address space, with 3072 as high as it will go. Often
>> need a lower setting to avoid PCI address space, things like video
>> memory.
>> The fix would be redoing doscall1.dll.
>
> Sure. I'm exactly preparing for the vendor to fix all that.
>

OK
Dave

On 18/02/24 07:47, Dave Yeo wrote:

> No, you won't get an address higher then 512MB, you need this for
> allocating high memory,
> stdlib.c: ulAllocationFlags = OBJ_ANY | PAG_COMMIT | PAG_WRITE |
> PAG_READ;

Ok, thanks.

I see this:

bsedos.h: #define OBJ_ANY 0x00000400

>> Does that mean DosOpen won't be able to cope with me
>> giving it that high address and crash?
>
> I believe so. With GCC, there is os2safe.h which has this,
> #define DosOpen SafeDosOpen
> #define DosOpenL SafeDosOpenL
> with the SafeDosOpen being a wrapper to handle the case of high memory.
> DosOpenL() is used for files larger then 2GB
>
>>
>>> address space, minus PCI space. VIRTUALADDRESSLIMIT in config.sys
>>> actually controls address space, with 3072 as high as it will go. Often
>>> need a lower setting to avoid PCI address space, things like video
>>> memory.
>>> The fix would be redoing doscall1.dll.
>>
>> Sure. I'm exactly preparing for the vendor to fix all that.
>>
>
> OK

Ok, so I will fix it in my mini-OS/2 clone. I will
allow the above program - without OBJ_ANY - to
allocate memory anywhere in the 4 GiB range.

BFN. Paul.