dll load question - OS2

This is a discussion on dll load question - OS2 ; Just spent a long time trying to test a new dll and wondering why it was not working - turns out there was another copy in /usr/lib but the question is *why* did it pick that up? The libpath starts ...

+ Reply to Thread
Results 1 to 16 of 16

Thread: dll load question

  1. dll load question

    Just spent a long time trying to test a new dll and wondering why it
    was not working - turns out there was another copy in /usr/lib but the
    question is *why* did it pick that up? The libpath starts
    LIBPATH=C:\SECURITY\dll;.;D:\APPS\ORACLE\DLL;D:\us r\lib;
    so there is a dot in there *before* /usr/lib

    I was executing the test prog from the same directory as the updated
    dll was in. And no it was not in use by anything else. Module is
    loaded by a DosLoadModule

    Anyone?
    --
    Regards
    Dave Saville

    NB Remove -nospam for good email address

  2. Re: dll load question

    [A complimentary Cc of this posting was sent to
    Dave Saville
    ], who wrote in article :
    > LIBPATH=C:\SECURITY\dll;.;D:\APPS\ORACLE\DLL;D:\us r\lib;
    > so there is a dot in there *before* /usr/lib
    >
    > I was executing the test prog from the same directory as the updated
    > dll was in. And no it was not in use by anything else.


    How did you check?

    > Module is loaded by a DosLoadModule


    Just in case: code?

    Yours,
    Ilya

  3. Re: dll load question

    Dave Saville wrote:
    > Just spent a long time trying to test a new dll and wondering why it
    > was not working - turns out there was another copy in /usr/lib but the
    > question is *why* did it pick that up? The libpath starts
    > LIBPATH=C:\SECURITY\dll;.;D:\APPS\ORACLE\DLL;D:\us r\lib;
    > so there is a dot in there *before* /usr/lib
    >

    What about BEGINLIBPATH?

    --
    jmm (hyphen) list (at) sohnen-moe (dot) com
    (Remove .AXSPAMGN for email)

  4. Re: dll load question

    On Mon, 16 Jul 2007 19:35:43 UTC, Ilya Zakharevich
    wrote:

    > [A complimentary Cc of this posting was sent to
    > Dave Saville
    > ], who wrote in article :
    > > LIBPATH=C:\SECURITY\dll;.;D:\APPS\ORACLE\DLL;D:\us r\lib;
    > > so there is a dot in there *before* /usr/lib
    > >
    > > I was executing the test prog from the same directory as the updated
    > > dll was in. And no it was not in use by anything else.

    >
    > How did you check?
    >
    > > Module is loaded by a DosLoadModule

    >
    > Just in case: code?


    rc = DosLoadModule(buf + 32, 16, buf, &cv_res);

    buf contains "CV_xx" where xx is a country code such as "de".

    No BEGINLIBPATH.

    And yes I do check rc :-)

    --
    Regards
    Dave Saville

    NB Remove -nospam for good email address

  5. Re: dll load question

    [A complimentary Cc of this posting was sent to
    Dave Saville
    ], who wrote in article :
    > > > I was executing the test prog from the same directory as the updated
    > > > dll was in. And no it was not in use by anything else.

    > >
    > > How did you check?


    No answer???

    > > > Module is loaded by a DosLoadModule

    > >
    > > Just in case: code?

    >
    > rc = DosLoadModule(buf + 32, 16, buf, &cv_res);
    >
    > buf contains "CV_xx" where xx is a country code such as "de".
    >
    > No BEGINLIBPATH.
    >
    > And yes I do check rc :-)


    [16 may be too low (I use 512, to cover 260 chars of file path -
    though usually it is just 8 chars) - but this is not important if it
    succeeds, as in your case.]

    Hope this helps,
    Ilya

  6. Re: dll load question

    In , on 07/16/2007
    at 05:54 PM, "Dave Saville" said:

    Hi,

    >Just spent a long time trying to test a new dll and wondering why it was
    >not working - turns out there was another copy in /usr/lib but the
    >question is *why* did it pick that up? The libpath starts
    >LIBPATH=C:\SECURITY\dll;.;D:\APPS\ORACLE\DLL;D:\us r\lib; so there is a
    >dot in there *before* /usr/lib


    You'll need to be a bit more specific. Exactly how did you specific the
    DLL name to DosLoadModule?

    Steven

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


  7. Re: dll load question

    On Mon, 16 Jul 2007 17:54:19 UTC, "Dave Saville" wrote:

    > Just spent a long time trying to test a new dll and wondering why it
    > was not working - turns out there was another copy in /usr/lib but the
    > question is *why* did it pick that up? The libpath starts
    > LIBPATH=C:\SECURITY\dll;.;D:\APPS\ORACLE\DLL;D:\us r\lib;
    > so there is a dot in there *before* /usr/lib
    >
    > I was executing the test prog from the same directory as the updated
    > dll was in. And no it was not in use by anything else. Module is
    > loaded by a DosLoadModule


    The current directory has gotten changed (?). Set BEGINLIBPATH to the
    exe+dll directory, then retry. If it gets the right dll, '.' isn't
    pointing to the directory you think it is.

    BTW... are you causing this dll to be loaded into another process?


    --
    == == 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
    __________________________________________________ _________________

  8. Re: dll load question

    Hi,

    Dave Saville schrieb:
    > Just spent a long time trying to test a new dll and wondering why it
    > was not working - turns out there was another copy in /usr/lib but the
    > question is *why* did it pick that up? The libpath starts
    > LIBPATH=C:\SECURITY\dll;.;D:\APPS\ORACLE\DLL;D:\us r\lib;
    > so there is a dot in there *before* /usr/lib


    If the other DLL is already loaded into memory by another process then
    DosLoadModule will not even try to search for the DLL. It will simply
    use the instance in memory which has the same module name - ignoring the
    path.
    LIBPATHSTRICT chanches this as far as I know.


    Marcel

  9. Re: dll load question

    On Tue, 17 Jul 2007 08:21:25 UTC, "Rich Walsh"
    wrote:

    > On Mon, 16 Jul 2007 17:54:19 UTC, "Dave Saville" wrote:
    >
    > > Just spent a long time trying to test a new dll and wondering why it
    > > was not working - turns out there was another copy in /usr/lib but the
    > > question is *why* did it pick that up? The libpath starts
    > > LIBPATH=C:\SECURITY\dll;.;D:\APPS\ORACLE\DLL;D:\us r\lib;
    > > so there is a dot in there *before* /usr/lib
    > >
    > > I was executing the test prog from the same directory as the updated
    > > dll was in. And no it was not in use by anything else. Module is
    > > loaded by a DosLoadModule

    >
    > The current directory has gotten changed (?). Set BEGINLIBPATH to the
    > exe+dll directory, then retry. If it gets the right dll, '.' isn't
    > pointing to the directory you think it is.
    >


    There is no directory change in the code.

    > BTW... are you causing this dll to be loaded into another process?


    Did not know you could :-)


    --
    Regards
    Dave Saville

    NB Remove -nospam for good email address

  10. Re: dll load question

    On Tue, 17 Jul 2007 08:21:25 UTC, "Rich Walsh"
    wrote:


    > The current directory has gotten changed (?). Set BEGINLIBPATH to the
    > exe+dll directory, then retry. If it gets the right dll, '.' isn't
    > pointing to the directory you think it is.


    Must be correct because otherwise the hlp file would not get loaded -
    and that is *not* anywhere else and shows immediate changes so that
    *is* working.

    --
    Regards
    Dave Saville

    NB Remove -nospam for good email address

  11. Re: dll load question

    On Tue, 17 Jul 2007 09:23:10 UTC, Marcel Mller
    wrote:

    > Hi,
    >
    > Dave Saville schrieb:
    > > Just spent a long time trying to test a new dll and wondering why it
    > > was not working - turns out there was another copy in /usr/lib but the
    > > question is *why* did it pick that up? The libpath starts
    > > LIBPATH=C:\SECURITY\dll;.;D:\APPS\ORACLE\DLL;D:\us r\lib;
    > > so there is a dot in there *before* /usr/lib

    >
    > If the other DLL is already loaded into memory by another process then
    > DosLoadModule will not even try to search for the DLL. It will simply
    > use the instance in memory which has the same module name - ignoring the
    > path.


    Even if nothing is using it? Is there not a delete if use count = 0
    sort of thing? Otherwise one would need a reboot evreytime a test dll
    was recompiled. How does it cope with that anyway?

    > LIBPATHSTRICT chanches this as far as I know.


    No LIBPATHSRICT no BEGINLIBPATH


    --
    Regards
    Dave Saville

    NB Remove -nospam for good email address

  12. Re: dll load question

    In , on 07/17/2007
    at 10:13 AM, "Dave Saville" said:

    Hi,

    >Even if nothing is using it? Is there not a delete if use count = 0 sort
    >of thing?


    Sure, but the count is not always what one might assume it is. For
    example, with REXX DLLs, it's often neccessary to close the shell rather
    than just unloading the functions.

    IAC, I've found the pstat /L and psfiles are both good for checking out
    these kinds of issues.

    Wrt your help files, the search logic is entirely different, so this is
    not a terribly useful testcase.

    I don't know if there's any truth to this idea, but perhaps, the loader
    does try to load your DLL and fails to find a dependent DLL and continues
    searching until it finds the DLL it can load.

    You might want to test your DLL with pmdll or chkdll32.


    Steven

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


  13. Re: dll load question

    [A complimentary Cc of this posting was NOT [per weedlist] sent to
    Steven Levine
    ], who wrote in article <469d14d2$1$fgrir53$mr2ice@news.west.earthlink.net>:
    > IAC, I've found the pstat /L and psfiles are both good for checking out
    > these kinds of issues.


    Nope. pstat /L does not show dynamically loaded DLLs. psfiles shows
    them - but I'm not sure how it would behave with DosUpdateModule()
    (sp?).

    For best results, use a proper tool. E.g.,

    perl -MData:umper -MOS2::Proc -wle "print Dumper [proc_info 0]" | less

    will show all the info about loaded processes and loaded modules which is
    available without calling DosPerfSysCall() and/or
    DosQueryHeaderInfo().

    Hope this helps,
    Ilya

  14. Re: dll load question

    On Tue, 17 Jul 2007 19:13:21 UTC, Steven Levine
    wrote:

    > In , on 07/17/2007
    > at 10:13 AM, "Dave Saville" said:
    >
    > Hi,
    >
    > >Even if nothing is using it? Is there not a delete if use count = 0 sort
    > >of thing?

    >
    > Sure, but the count is not always what one might assume it is. For
    > example, with REXX DLLs, it's often neccessary to close the shell rather
    > than just unloading the functions.
    >
    > IAC, I've found the pstat /L and psfiles are both good for checking out
    > these kinds of issues.
    >
    > Wrt your help files, the search logic is entirely different, so this is
    > not a terribly useful testcase.
    >
    > I don't know if there's any truth to this idea, but perhaps, the loader
    > does try to load your DLL and fails to find a dependent DLL and continues
    > searching until it finds the DLL it can load.
    >
    > You might want to test your DLL with pmdll or chkdll32.
    >


    Well it worked perfectly once I deleted the extra one - which also
    points to it *not* being in use, else I could not delete it yes?

    I am not going to worry about it any more - It is on the "see if it
    happens again pile" :-)
    --
    Regards
    Dave Saville

    NB Remove -nospam for good email address

  15. Re: dll load question

    On Tue, 17 Jul 2007 10:13:51 UTC, "Dave Saville"
    wrote:

    > On Tue, 17 Jul 2007 09:23:10 UTC, Marcel Müller
    > wrote:
    >
    > > If the other DLL is already loaded into memory by another process then
    > > DosLoadModule will not even try to search for the DLL. It will simply
    > > use the instance in memory which has the same module name - ignoring the
    > > path.

    >

    Sometimes it can be very hard to detect simple typing errors. Check
    the whole path in the sources char by char that it is exactly what you
    means it should be.

    When your source means ".\\sample.dll" and is typed as ".\sample.dll"
    then dosloadmoduele sees ".ample.dll" and DLL not "found" is the
    result.

    DosLoadModule loads recursively DLLs needed by the DLL to load, when
    it can't find all of them it fails and nothing gets loaded.

    Is the DLL really in the same directory as the executeable itself? Is
    the current drive and directory really holding the executeable itself?
    Insert some debug code that shows you the parameters you give to
    DosLoadModule including the results of DosQueryPathInfo(),
    DosQueryCurrentDisk(), DosQueryCurrentDir

    --
    Tschau/Bye
    Herbert

    Visit http://www.ecomstation.de the home of german eComStation
    eComStation 1.2R Deutsch ist da!

  16. Re: dll load question

    On Thu, 19 Jul 2007 10:37:56 UTC, "Herbert Rosenau"
    wrote:

    > On Tue, 17 Jul 2007 10:13:51 UTC, "Dave Saville"
    > wrote:
    >
    > > On Tue, 17 Jul 2007 09:23:10 UTC, Marcel Mller
    > > wrote:
    > >
    > > > If the other DLL is already loaded into memory by another process then
    > > > DosLoadModule will not even try to search for the DLL. It will simply
    > > > use the instance in memory which has the same module name - ignoring the
    > > > path.

    > >

    > Sometimes it can be very hard to detect simple typing errors. Check
    > the whole path in the sources char by char that it is exactly what you
    > means it should be.
    >


    It is

    > When your source means ".\\sample.dll" and is typed as ".\sample.dll"
    > then dosloadmoduele sees ".ample.dll" and DLL not "found" is the
    > result.
    >
    > DosLoadModule loads recursively DLLs needed by the DLL to load, when
    > it can't find all of them it fails and nothing gets loaded.
    >
    > Is the DLL really in the same directory as the executeable itself? Is
    > the current drive and directory really holding the executeable itself?
    > Insert some debug code that shows you the parameters you give to
    > DosLoadModule including the results of DosQueryPathInfo(),
    > DosQueryCurrentDisk(), DosQueryCurrentDir
    >


    Yes and yes - If I have a command prompt open to
    d:/dir-with-exe-and-dll and I run the exe from the command prompt then
    I expect the damn OS to get the path, current disk and current dir
    right :-)

    --
    Regards
    Dave Saville

    NB Remove -nospam for good email address

+ Reply to Thread