DosAllocMem and OBJ_ANY - OS2

This is a discussion on DosAllocMem and OBJ_ANY - OS2 ; On Sun, 17 Feb 2008 02:58:12 UTC, Marty wrote: > Are you using UniAud or another 32-bit audio driver? Your results are > positive, but may be unintentionally misleading in this case. I use > Sander's 32-bit SBLive driver, so ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 54

Thread: DosAllocMem and OBJ_ANY

  1. Re: DosAllocMem and OBJ_ANY

    On Sun, 17 Feb 2008 02:58:12 UTC, Marty wrote:

    > Are you using UniAud or another 32-bit audio driver? Your results are
    > positive, but may be unintentionally misleading in this case. I use
    > Sander's 32-bit SBLive driver, so I can't augment your findings
    > unfortunately.



    Audio drivers request the upper layer stream manager to provide
    buffer addresses in one of the following formats:

    ADDRESS_TYPE_VIRTUAL
    ADDRESS_TYPE_PHYSICAL /* this is the default */
    ADDRESS_TYPE_LINEAR /* used by SBLive and most likely UNIAUD */

    The latter two are no problem (except for some drivers that treat
    32bit addresses as "signed long").

    The first could be. However, the buffers are mapped by SSMDD.SYS
    to a pool of GDT selectors. This does not introduce problems with
    high memory, because these are usually LDT mapping issues.


    So I'm quiet positive, that it will work with other sound drivers
    (are there any ? ;-) as well provided those are not too buggy...




    --
    Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
    http://www.s-t.de
    Please remove all characters left of the "R" in my email address


  2. Re: DosAllocMem and OBJ_ANY

    Marty writes:

    >> Heiko Nitzsche wrote:


    >>> Yes, I know this list. But all on it refers to Dos, nothing mentioned
    >>> about graphics or multimedia APIs which are the parts that would especially
    >>> require this support.


    >> I have enabled high memory support in my audio editing software. I have
    >> succeeded in loading a .WAV file over 800 MB in size. Use of multimedia
    >> APIs is limited to just what I need to play an audio clip, but it has no
    >> trouble playing the 800 MB clip.


    > Are you using UniAud or another 32-bit audio driver?


    My recollection is that I installed UniAud on my office OS/2 machine,
    where I have tested my audio editing software, but my development
    machine at home uses a driver for on-board Intel motherboard audio.
    The driver in CONFIG.SYS is named ICHCSND.SYS, and I'm not sure
    whether it is 32-bit or not.

    > Your results are
    > positive, but may be unintentionally misleading in this case. I use
    > Sander's 32-bit SBLive driver, so I can't augment your findings
    > unfortunately.


    For a while, I had OS/2 running on a T23 and a T43p Thinkpad, and did
    test my audio editing software on them, but that may have been before
    I added high memory support. Anyway, my software does try a small
    memory allocation in high memory first thing, and if it fails, falls
    back on low memory. One of the first messages the program displays is
    whether high memory support is enabled, or whether the process is limited
    to 512 MB (which really means more like 300 MB).


  3. Re: DosAllocMem and OBJ_ANY

    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.

    Lars

    "Marty" schrieb im Newsbeitrag
    news:YdidnXmy8dK7PyranZ2dnUVZ_sytnZ2d@comcast.com. ..
    > Heiko Nitzsche wrote:
    >> Lets have a look at graphics. Try working with a 5000x4000x32bpp bitmap.
    >> ...

    >
    > [snipped for brevity, but read in full]
    >
    >> As Peter told us, GpiDrawBits seems to work fine. I also have not
    >> discovered any issues blitting areas from huge buffers (600MB). Also
    >> GpiCreateBitmap showed no obvious problems so far. Well you cannot
    >> create such a huge GPI bitmap (probably GPI allocates memory from
    >> low memory for internal purposes or the graphics driver does not
    >> support such huge bitmaps), but this is OK for most cases.
    >>
    >> I think most of the graphics APIs are fully 32bit (for performance
    >> reasons) and thus there is some hope

    >
    > To my recollection, there is a portion of Gpi's implementation that can
    > occur in the video device driver itself (as well as some portion of DIVE).
    > In this case, it is possible to wind up in 16 bit code. We're lucky that
    > GRADD drivers like SNAP are so pervasive (and actually necessary at this
    > stage) that this has become less of a concern, but it still could cause
    > some issues with legacy drivers.
    >
    > --
    > [Reverse the parts of the e-mail address to reply.]




  4. Re: DosAllocMem and OBJ_ANY

    On Wed, 13 Feb 2008 23:33:06 UTC, Heiko Nitzsche
    wrote:

    > As long as DosWrite and DosRead support large buffers, there is no problem.
    > It just makes it error prone as you have to think twice before using every
    > single API function.
    >
    >


    Too true. I just learned that DosStartSession will not work correctly
    if the text buffers of the STARTDATA are residing in high memory.



  5. Re: DosAllocMem and OBJ_ANY

    In <47b9b7db$0$23012$9b4e6d93@newsspool1.arcor-online.net>, on 02/18/2008
    at 05:52 PM, "Lars Erdmann" said:

    Hi,

    >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.


    Yes and no. The DLLs display driver components are generally 32-bit.
    However, more than a few kernel APIs are still unexpectedly 16-bit with a
    32-bit wrapper. The problems occur when the driver uses these APIs. The
    residual 16-bit code is also the reason for the 64KB data limit that
    exists in a number of the APIs.

    If the 16-bit code uses, GDT selectors, there should be no problem using
    high memory. This is why 16-bit device drivers generally have no problem
    accessing upper memory. If the 16-bit code uses LDT selectors, then
    attempting to access upper memory will fail.


    Steven

    --
    --------------------------------------------------------------------------------------------
    Steven Levine MR2/ICE 3.00 beta 11pre #10183
    eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
    --------------------------------------------------------------------------------------------


  6. Re: DosAllocMem and OBJ_ANY

    On Thu, 14 Feb 2008 06:43:38 UTC, Lars Erdmann
    wrote:

    > Come on. Copying a filename (< 260 bytes) into a buffer in low memory or
    > on the stack is not a problem. If yes, use DosAliasMem.
    >


    DosAliasMem....
    Does not exist in help! You spend time reading .h files, I guess!

    So I did the same and found DosAliasMem in bsedos.h and SEL_USE32
    defined in bsememf.h. After a little playing around, I got it to work
    as far as mapping high memory to low.

    Unfortunately, it is only useful on DosAllocMem chunks and not
    DosSubAllocMem chunks. Of course, it wouldn't...duh. But I had to
    learn it the "experiential" way.

  7. Re: DosAllocMem and OBJ_ANY

    On Mon, 18 Feb 2008 19:20:31 UTC, no_spam@outgoing.net (Jeffrey Smick)
    wrote:

    > DosAliasMem....
    > Does not exist in help! You spend time reading .h files, I guess!


    It's documented in \book\addenum.inf


    > Unfortunately, it is only useful on DosAllocMem chunks and not
    > DosSubAllocMem chunks.


    DosSubAllocMem is evil anyway ;-). In most cases it's more efficient
    to use your complier's malloc function or roll you own sub allocation
    machanism instead of using this API.



    --
    Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
    http://www.s-t.de
    Please remove all characters left of the "R" in my email address


  8. Re: DosAllocMem and OBJ_ANY

    It's described in the Programming Addendum. And there, it is clearly stated
    that DosAliasMem only works with memory addresses that align on a page
    boundary (4096 bytes). What you can always do is align whatever memory
    address you have to 4096 bytes (by zeroing out the lowest 12 bits).
    Then, add the offset to the page boundary to the address that DosAliasMem
    returns.

    Lars

    "Jeffrey Smick" schrieb im Newsbeitrag
    news:9fiCUuybBu8t-pn2-LYCSpHJN1L6x@P4P800S.home...
    > On Thu, 14 Feb 2008 06:43:38 UTC, Lars Erdmann
    > wrote:
    >
    >> Come on. Copying a filename (< 260 bytes) into a buffer in low memory or
    >> on the stack is not a problem. If yes, use DosAliasMem.
    >>

    >
    > DosAliasMem....
    > Does not exist in help! You spend time reading .h files, I guess!
    >
    > So I did the same and found DosAliasMem in bsedos.h and SEL_USE32
    > defined in bsememf.h. After a little playing around, I got it to work
    > as far as mapping high memory to low.
    >
    > Unfortunately, it is only useful on DosAllocMem chunks and not
    > DosSubAllocMem chunks. Of course, it wouldn't...duh. But I had to
    > learn it the "experiential" way.




  9. Re: DosAllocMem and OBJ_ANY

    Addmittedly, it's a little bit like the near/far pointer stuff in DOS. Once
    you decide to go one way this decision is "hardcoded" in your program.
    But copying fairly small structures (like the STARTDATA structure) to the
    stack before using them at least makes it possible to work with high memory.


    Lars

    "Jeffrey Smick" schrieb im Newsbeitrag
    news:9fiCUuybBu8t-pn2-MMHCe8WcWEdV@P4P800S.home...
    > On Wed, 13 Feb 2008 23:33:06 UTC, Heiko Nitzsche
    > wrote:
    >
    >> As long as DosWrite and DosRead support large buffers, there is no
    >> problem.
    >> It just makes it error prone as you have to think twice before using
    >> every
    >> single API function.
    >>
    >>

    >
    > Too true. I just learned that DosStartSession will not work correctly
    > if the text buffers of the STARTDATA are residing in high memory.
    >
    >




  10. Re: DosAllocMem and OBJ_ANY

    [A complimentary Cc of this posting was NOT [per weedlist] sent to
    Lars Erdmann
    ], who wrote in article <47b9b7db$0$23012$9b4e6d93@newsspool1.arcor-online.net>:
    > 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?]

    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...

    Hope this helps,
    Ilya


  11. Re: DosAllocMem and OBJ_ANY

    Ruediger Ihle schrieb:
    > On Mon, 18 Feb 2008 19:20:31 UTC, no_spam@outgoing.net (Jeffrey Smick)
    > wrote:
    >
    >> DosAliasMem....
    >> Does not exist in help! You spend time reading .h files, I guess!

    >
    > It's documented in \book\addenum.inf
    >
    >
    >> Unfortunately, it is only useful on DosAllocMem chunks and not
    >> DosSubAllocMem chunks.

    >
    > DosSubAllocMem is evil anyway ;-). In most cases it's more efficient
    > to use your complier's malloc function or roll you own sub allocation
    > machanism instead of using this API.


    Why ?

  12. Re: DosAllocMem and OBJ_ANY

    [A complimentary Cc of this posting was sent to
    Ruediger Ihle
    ], who wrote in article :
    > > Unfortunately, it is only useful on DosAllocMem chunks and not
    > > DosSubAllocMem chunks.


    > DosSubAllocMem is evil anyway ;-). In most cases it's more efficient
    > to use your complier's malloc function or roll you own sub allocation
    > machanism instead of using this API.


    This is not my experience (when I was benchmarking "my" malloc()
    against alternatives). Mine was much better (except for
    signal-safety); but the compiler's ones were not *significantly*
    better.

    Hope this helps,
    Ilya

  13. Re: DosAllocMem and OBJ_ANY

    Ruediger Ihle schrieb:
    > On Sun, 17 Feb 2008 02:58:12 UTC, Marty wrote:
    >
    >> Are you using UniAud or another 32-bit audio driver? Your results are
    >> positive, but may be unintentionally misleading in this case. I use
    >> Sander's 32-bit SBLive driver, so I can't augment your findings
    >> unfortunately.

    >
    >
    > Audio drivers request the upper layer stream manager to provide
    > buffer addresses in one of the following formats:
    >
    > ADDRESS_TYPE_VIRTUAL
    > ADDRESS_TYPE_PHYSICAL /* this is the default */
    > ADDRESS_TYPE_LINEAR /* used by SBLive and most likely UNIAUD */
    >
    > The latter two are no problem (except for some drivers that treat
    > 32bit addresses as "signed long").
    >
    > The first could be. However, the buffers are mapped by SSMDD.SYS
    > to a pool of GDT selectors. This does not introduce problems with
    > high memory, because these are usually LDT mapping issues.
    >
    >
    > So I'm quiet positive, that it will work with other sound drivers
    > (are there any ? ;-) as well provided those are not too buggy...
    >
    >
    >
    >

    By the way: do you know how DosAliasMem works, technically ? I mean if
    you use up an LDT selector to map high memory (the "alias"), for the
    used LDT selector, you break the "simple" thunking algorithm (sel =
    (SEL)((ULONG)linearaddress >> 13 | 7)) that is true for the low memory
    region. So, what happens to the linear low memory address space that
    would normally map to that LDT selector ?
    And if you map a high memory region that is much greater than 64 kBytes,
    you potentially use up a whole bunch of them, that is, 1 LDT selector
    per 64 kBytes ("huge pointers" I say). Is that true ?
    DosAliasMem offers to map a large memory object with one "big" LDT
    selector only (SEL_USE32) but that will lead to offsets >= 64k rendering
    it unusable for 16-bit code that only works with 16:16 pointers, correct ?
    Can you also tell me what OBJ_SELMAPALL does and if it can only be used
    with SEL_USE32 or also works without it ?


    Lars

  14. Re: DosAllocMem and OBJ_ANY

    > By the way: do you know how DosAliasMem works, technically ? I mean if
    > you use up an LDT selector to map high memory (the "alias"), for the
    > used LDT selector, you break the "simple" thunking algorithm (sel =
    > (SEL)((ULONG)linearaddress >> 13 | 7)) that is true for the low memory
    > region. So, what happens to the linear low memory address space that
    > would normally map to that LDT selector ?
    > And if you map a high memory region that is much greater than 64 kBytes,
    > you potentially use up a whole bunch of them, that is, 1 LDT selector
    > per 64 kBytes ("huge pointers" I say). Is that true ?
    > DosAliasMem offers to map a large memory object with one "big" LDT
    > selector only (SEL_USE32) but that will lead to offsets >= 64k rendering
    > it unusable for 16-bit code that only works with 16:16 pointers, correct ?
    > Can you also tell me what OBJ_SELMAPALL does and if it can only be used
    > with SEL_USE32 or also works without it ?


    Just another question: what is the difference between SEL_USE32 and
    SEL_USE32 | OBJ_SELMAPALL ?

    Lars

  15. Re: DosAllocMem and OBJ_ANY

    On Tue, 19 Feb 2008 19:45:13 UTC, Lars Erdmann
    wrote:

    > Why ?


    I didn't test it mayself, but ISTR that Scott gave me that
    advice a long time ago...



    --
    Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
    http://www.s-t.de
    Please remove all characters left of the "R" in my email address


  16. Re: DosAllocMem and OBJ_ANY

    On Tue, 19 Feb 2008 19:58:30 UTC, Lars Erdmann
    wrote:

    > By the way: do you know how DosAliasMem works, technically ?


    No, I can only speculate...


    > So, what happens to the linear low memory address space that
    > would normally map to that LDT selector ?


    I'd say the API will use free virtual address space. Just like a
    DosAllocMem in the low region would do. Only with the difference,
    that the contents of the returned memory block are identical to
    your high memory object.


    > And if you map a high memory region that is much greater than 64 kBytes,
    > you potentially use up a whole bunch of them, that is, 1 LDT selector
    > per 64 kBytes ("huge pointers" I say). Is that true ?


    I would think so. Again: think of it as a special form of DosAllocMem.


    > DosAliasMem offers to map a large memory object with one "big" LDT
    > selector only (SEL_USE32) but that will lead to offsets >= 64k rendering
    > it unusable for 16-bit code that only works with 16:16 pointers, correct ?


    I would interprete the docs the following: If the object is larger than
    64K, a number of consecutive LDT selectors is neccessary to address it.
    That's what the API would do anyway. But if SEL_USE32 is specified, the
    first of these LDT selectors is setup in a way, that it will allow 32
    bit
    addressing. This is usable by ASM code (16:32 pointers). I don't think,
    that it will break the 16:16 addressibility as provided without this
    flag.


    > Can you also tell me what OBJ_SELMAPALL does


    I would think that it controls the behaviour when the source (high)
    memory object is sparsely allocated. The docs are not clear to me
    here as well, but I would speculate that it disallows / allows the
    memory region to contain "holes" or not.


    > and if it can only be used with SEL_USE32 or also works without it ?


    If my assumption about OBJ_SELMAPALL is correct, then it can be used
    independently from SEL_USE32.


    > Just another question: what is the difference between SEL_USE32 and
    > SEL_USE32 | OBJ_SELMAPALL ?


    Also based on my other assupmtions: OBJ_SELMAPALL enforces that the
    memory region doesn't contain "holes". This is probably a requirement
    to allow 16:32 addressibility via the the first LDT selector as provided
    by SEL_USE32. Therefore, SEL_USE32 is only effective, when OBJ_SELMAPALL
    is present as well.




    As I said in the beginning: this is just speculation. If anyone knows
    it better, please jump in !



    --
    Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
    http://www.s-t.de
    Please remove all characters left of the "R" in my email address


  17. Re: DosAllocMem and OBJ_ANY


    "Ilya Zakharevich" schrieb im Newsbeitrag
    news:fpf9vj$ooo$1@agate.berkeley.edu...
    > [A complimentary Cc of this posting was NOT [per weedlist] sent to
    > Lars Erdmann
    > ], who wrote in article
    > <47b9b7db$0$23012$9b4e6d93@newsspool1.arcor-online.net>:
    >> 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



  18. Re: DosAllocMem and OBJ_ANY

    Lars Erdmann wrote:
    > "Ilya Zakharevich" schrieb im Newsbeitrag
    > news:fpf9vj$ooo$1@agate.berkeley.edu...
    >
    >>[A complimentary Cc of this posting was NOT [per weedlist] sent to
    >>Lars Erdmann
    >>], who wrote in article
    >><47b9b7db$0$23012$9b4e6d93@newsspool1.arcor-online.net>:
    >>
    >>>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.


    Some display drivers also still need to call into the video BIOS,
    especially for full screen operations. Unless they do some clever call
    gating like SDDHELP.SYS, they need to be in 16-bit code to do this (via
    SYSINIT?). How do you think high memory plays into this scenario (if at
    all)?

    --
    [Reverse the parts of the e-mail address to reply.]

  19. Re: DosAllocMem and OBJ_ANY

    [A complimentary Cc of this posting was NOT [per weedlist] sent to
    Lars Erdmann
    ], who wrote in article <47bc3d89$0$4288$9b4e6d93@newsspool3.arcor-online.net>:
    > > 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.


    Thanks, Lars. Sorry for my DD illiteracy, but for me, what you
    discuss looks like "memory allocated by DD and passed to a process".
    Should not the "possible breakage" scenario be the opposite: "memory
    allocated by process and passed to DD"?

    Or are you discussing memory-pre-digestion by DD to translate memory
    addresses as-usable-by-ring3 into something usable-by-ring-0?

    Yours,
    Ilya

  20. Re: DosAllocMem and OBJ_ANY

    Hi,

    > Some display drivers also still need to call into the video BIOS,
    > especially for full screen operations. Unless they do some clever call
    > gating like SDDHELP.SYS, they need to be in 16-bit code to do this (via
    > SYSINIT?). How do you think high memory plays into this scenario (if at
    > all)?


    I assume that the video BIOS can be called in protected mode ? Real mode
    would be even more involved ...
    If a user application passes a buffer to the display driver, directly or
    indirectly, and the display driver directly calls into video BIOS passing
    that buffer address (no copying), then that user buffer will have to be in
    low memory if the video BIOS code is pure 16-bit. If the user buffer is in
    high memory, the caller will have to use DosAliasMem to get a memory alias
    in low memory.


    Lars



+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast