Re: DosAllocMem and OBJ_ANY


"Ilya Zakharevich" <nospam-abuse@xxxxxxxxx> schrieb im Newsbeitrag
news:fpf9vj$ooo$1@xxxxxxxxxxxxxxxxxxxxx
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Lars Erdmann
<lars.erdmann@xxxxxxxx>], who wrote in article
<47b9b7db$0$23012$9b4e6d93@xxxxxxxxxxxxxxxxxxxxxxxxxxx>:
I thought that display drivers are 32-bit all the way through ? And it's
them that eventually implement all the GPI routines (or, to be more
precise
the set of device dependent functions that the GPI routines use). I think
16-bit display drivers were dropped starting with OS/2 2.1.

[By IBM, or by OEM?]

see below. It's not only IBM or OEM. OS/2 moved from 16-bit display driver
DLLs to 32-bit display driver DLLs. It was a design change everyone had to
follow.

The last time we had this discussion, somebody explained that even
16-bit DRIVERS would be able to support high memory (my knowledge of
DD is very limited, so I can't do anything but quote somebody else;
sorry!). It was noted that is the 16-bit DLLs which implement ring-3
part of the services which may break...

Memory that is allocated in the GDT (and therefore accessible to any process
calling into the device driver) will always be in the high memory region by
nature. There is no "low memory" for GDT mapped memory objects.
On the other hand, 16-bit device drivers have to be coded to support "user"
high memory (that is memory seen only by a specific process) with specific
allocation flags of VMAlloc. Technically, it's possible but it has to be
coded that way explicitely. No older 16-bit device drivers will therefore
support high memory in user space as high memory did not exist when those
drivers were written.

See VMAlloc, with flags VMDHA_USEHMA | VMDHA_PROCESS that allow allocation
of memory from within the device driver for a specific process calling into
the device driver.
Similarly, flags VMDHA_USEHMA | VMDHA_SHARED will allow to allocate memory
from within the device driver in the high memory arena not for a specific
process but shared memory for all processes (like shared memory for a DLL).
Still, this is DIFFERENT from memory allocated through the GDT (GDT memory
is normally only accessible by Ring-0 code, like device drivers, IFSs, the
kernel etc.)

In short: VMAlloc with the flags stated is the "Ring-0 extension" of the
APIs DosAllocMem, DosAllocSharedMem with the OBJ_HMA flag set.


See also VMGlobalToProcess, with flag VMDHGP_HMA32 that (on demand) maps
global memory allocated in GDT into high memory for the process calling into
the device driver.

Side note: flags VMDHA_USEHMA (,VMDHA_SHARED) and VMDHGP_HMA32, along with
some others, are "barely" documented in the Yahoo "os2ddprog" (Device Driver
Programming) group, see messages 994, 995 and 2465.



About DLLs: that's the point: starting with OS/2 2.1, the display driver
DLLs are 32-bit all the way through (and the 16-bit DLL DISPLAY.DLL that
contained all screen drawing code was dropped). The question is if the
32-bit display driver DLL still calls into some 16-bit code. One such
example might be that a display driver DLL might use the SCREEN IOCTLs
(SCREENDD_CATEGORY) provided by SCREENDD$ device driver (screen01.sys,
screen02.sys). That device driver is very old and most certainly does not
support "user" high memory.
However that is no problem if the 32-bit DLL only passes via the IOCTL
memory addresses of structures etc. that it allocates on the stack or
anywhere else in low memory.

Lars


.

Relevant Pages

  • Re: Please help!
    ... This bug check is issued if paged memory is accessed ... installation of a faulty device driver, system service, or BIOS. ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: DosAllocMem and OBJ_ANY
    ... OS/2 moved from 16-bit display driver DLLs to 32-bit display driver DLLs. ... Memory that is allocated in the GDT (and therefore accessible to any process calling into the device driver) will always be in the high memory region by nature. ...
    (comp.os.os2.programmer.misc)
  • Re: Lock memory ?
    ... process's working set, but of course that doesn't keep the working set ... > There is far less memory than hard disk space. ... > You can write a device driver that does it. ...
    (microsoft.public.vc.mfc)
  • Re: Testing for the presence of an attached IO device
    ... A device driver is usually configured automatically by OpenVMS, when the system autoconfiguration processing runs through its configuration sequence -- probing the contents of the attached buses. ... Device drivers can and do use probe, but usually for accessing user memory and rather less commonly in CSR space, which is where the device announces itself. ... If within a VAX device driver, you'll want to use a machine check protection block, see the $PRTCTINI/$PRTCTINI mechanism in the OpenVMS VAX device driver. ... With typical system services and user-mode code, just aim a sys$getdvi and catch the error that would get returned for a non-existent device. ...
    (comp.os.vms)
  • Re: DosAllocMem and OBJ_ANY
    ... calling into the device driver) will always be in the high memory region by ... 16-bit device drivers have to be coded to support "user" ...
    (comp.os.os2.programmer.misc)