Groups | Search | Server Info | Login | Register


Groups > comp.os.os2.programmer.misc > #1827

Re: another VIO attempt

Subject Re: another VIO attempt
Newsgroups comp.os.os2.programmer.misc
References (2 earlier) <uql3ho$3arit$1@dont-email.me> <g0zzN.357630$c3Ea.117477@fx10.iad> <uqn5pe$3p9rk$1@dont-email.me> <RSRzN.332642$Wp_8.301346@fx17.iad> <uqp327$3psl$1@dont-email.me>
From Dave Yeo <dave.r.yeo@gmail.com>
Message-ID <bAbAN.96974$TSTa.67456@fx47.iad> (permalink)
Date 2024-02-17 15:47 -0800

Show all headers | View raw


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

Back to comp.os.os2.programmer.misc | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

another VIO attempt Paul Edwards <mutazilah@gmail.com> - 2024-02-15 13:13 +0800
  Re: another VIO attempt xhajt03 <xhajt03@gmail.com> - 2024-02-15 04:16 -0800
    Re: another VIO attempt Paul Edwards <mutazilah@gmail.com> - 2024-02-15 21:28 +0800
      Re: another VIO attempt xhajt03 <xhajt03@gmail.com> - 2024-02-15 06:47 -0800
        Re: another VIO attempt Paul Edwards <mutazilah@gmail.com> - 2024-02-15 23:23 +0800
          Re: another VIO attempt xhajt03 <xhajt03@gmail.com> - 2024-02-15 09:07 -0800
            Re: another VIO attempt Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-15 17:13 -0800
          Re: another VIO attempt Paul Edwards <mutazilah@gmail.com> - 2024-02-17 16:58 +0800
            Re: another VIO attempt Paul Edwards <mutazilah@gmail.com> - 2024-02-17 18:09 +0800
      Re: another VIO attempt Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-15 17:38 -0800
        Re: another VIO attempt Paul Edwards <mutazilah@gmail.com> - 2024-02-16 16:17 +0800
          Re: another VIO attempt Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-16 15:05 -0800
            Re: another VIO attempt Paul Edwards <mutazilah@gmail.com> - 2024-02-17 09:44 +0800
              Re: another VIO attempt Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-17 15:47 -0800
                Re: another VIO attempt Paul Edwards <mutazilah@gmail.com> - 2024-02-18 09:48 +0800

csiph-web