Re: another VIO attempt

Subject	Re: another VIO attempt
Newsgroups	comp.os.os2.programmer.misc
References	<uqk6ia$35m65$1@dont-email.me> <d6855582-82fd-4883-8806-7bb0de30c63fn@googlegroups.com> <uql3ho$3arit$1@dont-email.me> <g0zzN.357630$c3Ea.117477@fx10.iad> <uqn5pe$3p9rk$1@dont-email.me>
From	Dave Yeo <dave.r.yeo@gmail.com>
Message-ID	<RSRzN.332642$Wp_8.301346@fx17.iad> (permalink)
Date	2024-02-16 15:05 -0800

Show all headers | View raw

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

Back to comp.os.os2.programmer.misc | Previous | Next — Previous 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