behavior of BEGINLIBPATH - OS2

This is a discussion on behavior of BEGINLIBPATH - OS2 ; According to HELP BEGINLIBPATH: BEGINLIBPATH is not actually part of the environment. The SET command provides a means for setting and viewing the value. BEGINLIBPATH affects only the current OS/2 process. It does not globally affect the system as LIBPATH ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: behavior of BEGINLIBPATH

  1. behavior of BEGINLIBPATH

    According to HELP BEGINLIBPATH:

    BEGINLIBPATH is not actually part of the environment. The SET
    command provides a means for setting and viewing the value.
    BEGINLIBPATH affects only the current OS/2 process. It does not
    globally affect the system as LIBPATH does.

    However, I recently used BEGINLIBPATH in one command prompt window
    to enable a program to run that needed a couple of DLLs, and suddenly
    I was able to run that same program in other command prompt windows
    without setting BEGINLIBPATH. Has the behavior of BEGINLIBPATH been
    altered and not documented in the HELP system?


  2. Re: behavior of BEGINLIBPATH

    On Fri, 3 Aug 2007 19:03:51 UTC, tholen@antispam.ham wrote:

    > According to HELP BEGINLIBPATH:
    >
    > BEGINLIBPATH is not actually part of the environment. The SET
    > command provides a means for setting and viewing the value.
    > BEGINLIBPATH affects only the current OS/2 process. It does not
    > globally affect the system as LIBPATH does.
    >
    > However, I recently used BEGINLIBPATH in one command prompt window
    > to enable a program to run that needed a couple of DLLs, and suddenly
    > I was able to run that same program in other command prompt windows
    > without setting BEGINLIBPATH. Has the behavior of BEGINLIBPATH been
    > altered and not documented in the HELP system?


    Was the original instance still running? If so, then this is the
    expected behavior. In the absence of LIBPATHSTRICT, the system
    searches its list of loaded dlls before seaching the extended
    LIBPATH. Indeed, this behavior is what necessitates the use of
    LIBPATHSTRICT on occassion to ensure that the system _doesn't_
    check for an already-loaded copy of a needed dll.


    --
    == == almost usable email address: rws AT e-vertise.com == ==
    __________________________________________________ _________________
    |
    | Remote Workplace Server v0.80
    Rich Walsh | interact with the WPS from any program
    Ft Myers, FL | http://e-vertise.com/rws/rws080.zip
    __________________________________________________ _________________

  3. Re: behavior of BEGINLIBPATH

    Rich Walsh writes:

    >> According to HELP BEGINLIBPATH:
    >>
    >> BEGINLIBPATH is not actually part of the environment. The SET
    >> command provides a means for setting and viewing the value.
    >> BEGINLIBPATH affects only the current OS/2 process. It does not
    >> globally affect the system as LIBPATH does.
    >>
    >> However, I recently used BEGINLIBPATH in one command prompt window
    >> to enable a program to run that needed a couple of DLLs, and suddenly
    >> I was able to run that same program in other command prompt windows
    >> without setting BEGINLIBPATH. Has the behavior of BEGINLIBPATH been
    >> altered and not documented in the HELP system?


    > Was the original instance still running?


    No. How long can/does the system cache a program?

    > If so, then this is the
    > expected behavior. In the absence of LIBPATHSTRICT, the system
    > searches its list of loaded dlls before seaching the extended
    > LIBPATH. Indeed, this behavior is what necessitates the use of
    > LIBPATHSTRICT on occassion to ensure that the system _doesn't_
    > check for an already-loaded copy of a needed dll.


    That's the first thing I thought of, so I tested it by running only
    one instance of the program at a time, and in one case, after waiting
    many minutes.


  4. Re: behavior of BEGINLIBPATH

    >> If so, then this is the
    >> expected behavior. In the absence of LIBPATHSTRICT, the system
    >> searches its list of loaded dlls before seaching the extended
    >> LIBPATH. Indeed, this behavior is what necessitates the use of
    >> LIBPATHSTRICT on occassion to ensure that the system _doesn't_
    >> check for an already-loaded copy of a needed dll.

    >
    > That's the first thing I thought of, so I tested it by running only
    > one instance of the program at a time, and in one case, after waiting
    > many minutes.


    If you load for instance a REXX dll from a script in cmd.exe,
    I think it stays loaded if the script does not explicitly
    unloads it at the end and cmd.exe stays running.

    I'm not even sure whether the dll is unloaded if cmd.exe ends.

  5. Re: behavior of BEGINLIBPATH

    On Fri, 03 Aug 2007 23:26:09 +0200, Heiko Nitzsche
    wrote:

    > If you load for instance a REXX dll from a script in cmd.exe,
    > I think it stays loaded if the script does not explicitly
    > unloads it at the end and cmd.exe stays running.
    >
    > I'm not even sure whether the dll is unloaded if cmd.exe ends.


    If you deregister the functions and exit cmd.exe then the DLL's usage count
    reduces to 0 and it gets unloaded.
    If you don't do both those then it doesn't.

+ Reply to Thread