Checking if PM is in the foreground - DosQuerySysInfo() bug? - OS2

This is a discussion on Checking if PM is in the foreground - DosQuerySysInfo() bug? - OS2 ; I'm trying to find a way to be able to check if the PM is the current foreground fullscreen session or not, so I can decide if I want to show a window or not. I've thought that I've found ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Checking if PM is in the foreground - DosQuerySysInfo() bug?

  1. Checking if PM is in the foreground - DosQuerySysInfo() bug?


    I'm trying to find a way to be able to check if the PM is the
    current foreground fullscreen session or not, so I can decide
    if I want to show a window or not.

    I've thought that I've found the perfect way for this:
    DosQuerySysInfo() with QSV_FOREGROUND_FS_SESSION should
    return the (quoted from cp*.inf):
    "Session ID of the current foreground full-screen session. Note that
    this only applies to full-screen sessions. The Presentation Manager
    session (which displays Vio-windowed, PM, and windowed DOS Sessions)
    is full-screen session ID 1."

    According to this text, if the returned value is 1, then the current
    foreground full-screen session is the PM.

    Unfortunately, it seems that it's not true. The returned value seems to
    be a session ID of the current foreground process, and not the
    full-screen session ID of the screen-group.

    This can be checked by a small utility, called sysinfo.exe (not the
    SysInfo/2 GUI app, it's a small VIO application). Starting two VIO
    windows, and running sysinfo.exe in both of them, it will report
    different foreground session IDs.


    Now I have two questions:
    Is it a bug of DosQuerySysInfo(), or did I miss something in the docs?
    Is there any reliable way to determine if PM is the current FS session?

    Thanks,
    Doodle

  2. Re: Checking if PM is in the foreground - DosQuerySysInfo() bug?


    Okay, just for the record, I answer myself.

    Doodle wrote:
    >
    > Now I have two questions:
    > Is it a bug of DosQuerySysInfo(), or did I miss something in the docs?


    Don't know, but it does not work as written in the docs.

    > Is there any reliable way to determine if PM is the current FS session?


    However, the original 16 bits API called DosGetInfoSeg() returns a
    selector to global info segment, which contains the right session ID,
    so using the 16 bits counterpart of DosQuerySysInfo() can solve this.

    The sgCurrent field of the global info segment is really 1 if PM is
    in the foreground.

    Doodle

  3. Re: Checking if PM is in the foreground - DosQuerySysInfo() bug?

    [A complimentary Cc of this posting was sent to
    Doodle
    ], who wrote in article :
    > However, the original 16 bits API called DosGetInfoSeg() returns a
    > selector to global info segment, which contains the right session ID,
    > so using the 16 bits counterpart of DosQuerySysInfo() can solve this.
    >
    > The sgCurrent field of the global info segment is really 1 if PM is
    > in the foreground.


    Are you sure? Even if PM was started from non-first FS session?

    Yours,
    Ilya

  4. Re: Checking if PM is in the foreground - DosQuerySysInfo() bug?

    Ilya Zakharevich wrote:

    >>The sgCurrent field of the global info segment is really 1 if PM is
    >>in the foreground.

    >
    > Are you sure? Even if PM was started from non-first FS session?


    I couldn't try it on a system where PM is not the first FS session,
    but I guess that it would be 1 for that, too. There seem to be some
    hard-coded session IDs, like this, and like 3 for the Popups...

    If you can try it, I'd be very interested in the results!

    Doodle

  5. Re: Checking if PM is in the foreground - DosQuerySysInfo() bug?

    [A complimentary Cc of this posting was sent to
    Doodle
    ], who wrote in article :
    > > Are you sure? Even if PM was started from non-first FS session?

    >
    > I couldn't try it on a system where PM is not the first FS session,
    > but I guess that it would be 1 for that, too. There seem to be some
    > hard-coded session IDs, like this, and like 3 for the Popups...


    I thought about command-line boot with the BootOS2's session switcher
    (one needs to change one line in config.y). Create several new
    sessions via

    start

    Check IDs of the sessions; you say that none of these two ids is going
    to be 1 or 3; strange. Then run

    pmshell

    from one of the sessions; my guess is that the sid of PM is going to
    be the same as sid of the session it was started from....

    Do not plan to check it soon,
    Ilya

  6. Re: Checking if PM is in the foreground - DosQuerySysInfo() bug?

    [A complimentary Cc of this posting was sent to
    Doodle
    ], who wrote in article :
    > > Are you sure? Even if PM was started from non-first FS session?

    >
    > I couldn't try it on a system where PM is not the first FS session,
    > but I guess that it would be 1 for that, too. There seem to be some
    > hard-coded session IDs, like this, and like 3 for the Popups...
    >
    > If you can try it, I'd be very interested in the results!


    Actually, today I upgraded my emergency partition from Warp3 to Warp4,
    and took an opportunity to check this.

    a) PROTSHELL=cmd.exe

    After booting, sid=0. After starting PMSHELL, sid=1 (actually, I
    do not remember whether I checked it, drat...).

    b) PROTSHELL=bos2shl.exe

    After booting, sid=5. Starting a new session gets sid=6 (I did
    not check what happens after one reaches 16...).

    Starting PMSHELL fails (3170 in DOSCALL1).

    So this supports your conjecture... But where are the remaining SIDs
    remains unclear; where are 0, 2, 4 (assuming 1 and 3 are reserved)?

    Yours,
    Ilya

    P.S. I found SID by

    perl.exe -wle "print unpack 'x24 C', unpack 'P32', pack 'L', OS2::_InfoTable"

    (this unpack/unpack/pack stuff is required to convert an integer
    address to a content of a struct - here a Character at offset 25).

  7. Re: Checking if PM is in the foreground - DosQuerySysInfo() bug?


    Ilya Zakharevich wrote:
    > Actually, today I upgraded my emergency partition from Warp3 to Warp4,
    > and took an opportunity to check this.


    [...]

    > So this supports your conjecture... But where are the remaining SIDs
    > remains unclear; where are 0, 2, 4 (assuming 1 and 3 are reserved)?


    Many thanks for checking it!

    Unfortunately, I don't know about other SIDs, these I've found in the
    documents and in various source codes...


    Doodle

+ Reply to Thread