Unable to load library (sometimes)

We have the following situation:

We use oracle for store and our application. This application also uses
a dll from Vasco (digipass).
When we start a development image and immediately  access this dll
everything work fine. If I connect to store first the dll fails to load
( SystemError('io error', 126)). If I make sure the vasco dll is loaded
first everything work fine. It It fails when using a machine with oracle
10.2.0.x installed. It works with oracle 9.2.0.7 and oracle 10.1.0.x.

Does anyone have an idea why this happens?  I have noticed that when
connecting to oracle 10.2 a lot of
dlls are loaded. But this doesn't halt the loading of other (microsoft) dlls

I hope someone can help me,

Cham

What are you using for your library path? Relative filenames are prone to 'migrate' around whenever 'current' directory changes,

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: Cham Püschel [mailto:[hidden email]]
Sent: Friday, November 10, 2006 9:34 AM
To: [hidden email]
Subject: Unable to load library (sometimes)

We have the following situation:

We use oracle for store and our application. This application also uses
a dll from Vasco (digipass).
When we start a development image and immediately  access this dll
everything work fine. If I connect to store first the dll fails to load
( SystemError('io error', 126)). If I make sure the vasco dll is loaded
first everything work fine. It It fails when using a machine with oracle
10.2.0.x installed. It works with oracle 9.2.0.7 and oracle 10.1.0.x.

Does anyone have an idea why this happens?  I have noticed that when
connecting to oracle 10.2 a lot of
dlls are loaded. But this doesn't halt the loading of other (microsoft) dlls

I hope someone can help me,

Cham

Boris Popov wrote:
> What are you using for your library path? Relative filenames are prone to 'migrate' around whenever 'current' directory changes,
>
> Cheers!
>
> -Boris
>
>  
Hi Boris,

This seems indeed the case. Thanks!
This dll is normally located in the image directory which is also the
startup dir.
When I evaluate:
Filename concreteClass currentDirectory asAbsoluteFilename

I will get the imagedirectory in both cases but only in one case the dll
loads.

Any idea?

Cham

Check #defaultDirectory as well in both cases,

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: Cham Püschel [mailto:[hidden email]]
Sent: Friday, November 10, 2006 9:54 AM
To: [hidden email]
Cc: Boris Popov
Subject: Re: Unable to load library (sometimes)

Boris Popov wrote:
> What are you using for your library path? Relative filenames are prone to 'migrate' around whenever 'current' directory changes,
>
> Cheers!
>
> -Boris
>
>  
Hi Boris,

This seems indeed the case. Thanks!
This dll is normally located in the image directory which is also the
startup dir.
When I evaluate:
Filename concreteClass currentDirectory asAbsoluteFilename

I will get the imagedirectory in both cases but only in one case the dll
loads.

Any idea?

Cham

Boris Popov wrote:
> Check #defaultDirectory as well in both cases,
>
> Cheers!
>
> -Boris
>
>  
Same as the currentDirectory: both times the image directory but still
it fails to load in one case.

Strange isn't?

Cham

Have you tried setting your lib path to an absolute filename yet?

#(#libraryDirectories #('c:\mylibs'))

Cheers,

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: Cham Püschel [mailto:[hidden email]]
Sent: Friday, November 10, 2006 10:45 AM
To: Boris Popov
Cc: [hidden email]
Subject: Re: Unable to load library (sometimes)

Boris Popov wrote:
> Check #defaultDirectory as well in both cases,
>
> Cheers!
>
> -Boris
>
>  
Same as the currentDirectory: both times the image directory but still
it fails to load in one case.

Strange isn't?

Cham

Cham_Püschel <[hidden email]> wrote:

| Boris Popov wrote:
| > Check #defaultDirectory as well in both cases,
| >
| > Cheers!
| >
| > -Boris
| >
| >
| Same as the currentDirectory: both times the image directory but still
| it fails to load in one case.

| Strange isn't?

Cham,
        wrap the dll loading primitive with something that writes the arguments, result (and the current directory and, if possible, what PATH really is in the environment - I don't know how to do this on Windows) to the transcript and then run the two examples.  Keep adding relevant info until you find the difference.

HTH
---
The surest sign that intelligent life exists elsewhere in           Calvin &
the universe is that none of it has tried to contact us.             Hobbes.
--
Eliot     ,,,^..^,,,    Smalltalk - scene not herd     x4581 [hidden email]

Boris Popov wrote:
> Have you tried setting your lib path to an absolute filename yet?
>
> #(#libraryDirectories #('c:\mylibs'))
>

Our experience has been that absolute paths for libraries do not work on
Windows. However, including the library's directory in the PATH variable
of the environment in which the VM is launched is effective.

Regards,

-Martin

Martin McClure <[hidden email]> wrote:

| Boris Popov wrote:
| > Have you tried setting your lib path to an absolute filename yet?
| >
| > #(#libraryDirectories #('c:\mylibs'))
| >

| Our experience has been that absolute paths for libraries do not work on
| Windows. However, including the library's directory in the PATH variable
| of the environment in which the VM is launched is effective.

...which is typically because of an inability to bind dlls upon which the loaded one depends.  e.g. if one attempts to load a library foo.dll via the absolute path c:\dir\foo.dll and foo.dll depends on c:\dir\bar.dll, bar.dll can't be loaded by foo (eg. as foo initializes) unless c:\dir is in the path.

| Regards,

| -Martin
---
Eliot Miranda                 ,,,^..^,,,                mailto:[hidden email]
VisualWorks Engineering, Cincom  Smalltalk: scene not herd  Tel +1 408 216 4581
3350 Scott Blvd, Bldg 36 Suite B, Santa Clara, CA 95054 USA Fax +1 408 216 4500

[hidden email] wrote:
> Martin McClure <[hidden email]> wrote:
>
> | Our experience has been that absolute paths for libraries do not work on
> | Windows. However, including the library's directory in the PATH variable
> | of the environment in which the VM is launched is effective.
>
> ...which is typically because of an inability to bind dlls upon which the
> loaded one depends.  e.g. if one attempts to load a library foo.dll via the
 > absolute path c:\dir\foo.dll and foo.dll depends on c:\dir\bar.dll,
bar.dll
 > can't be loaded by foo (eg. as foo initializes) unless c:\dir is in
the path.

That's good to know!

Thanks,

-Martin

Try evaluating this:

        Filename findDefaultDirectory

This usually "tracks" the actual local directory on Windows.
Demonstrate by opening a native file dialog, and navigating
to a different directory, and then re-evaluate the above.

- Dave Wallen

-----Original Message-----
From: Cham Püschel [mailto:[hidden email]]
Sent: Friday, November 10, 2006 9:54 AM
To: [hidden email]
Cc: Boris Popov
Subject: Re: Unable to load library (sometimes)

Boris Popov wrote:
> What are you using for your library path? Relative filenames are prone to 'migrate' around whenever 'current' directory changes,
>
> Cheers!
>
> -Boris
>
>  
Hi Boris,

This seems indeed the case. Thanks!
This dll is normally located in the image directory which is also the
startup dir.
When I evaluate:
Filename concreteClass currentDirectory asAbsoluteFilename

I will get the imagedirectory in both cases but only in one case the dll
loads.

Any idea?

Cham

[hidden email] wrote:

Cham_Püschel [hidden email] wrote:

| Boris Popov wrote:
| > Check #defaultDirectory as well in both cases,
| >
| > Cheers!
| >
| > -Boris
| >
| >   
| Same as the currentDirectory: both times the image directory but still 
| it fails to load in one case.

| Strange isn't?

Cham,
	wrap the dll loading primitive with something that writes the arguments, result (and the current directory and, if possible, what PATH really is in the environment - I don't know how to do this on Windows) to the transcript and then run the two examples.  Keep adding relevant info until you find the difference.

HTH
---
The surest sign that intelligent life exists elsewhere in           Calvin &
the universe is that none of it has tried to contact us.             Hobbes.
--
Eliot     ,,,^..^,,,    Smalltalk - scene not herd     x4581 [hidden email]



  

I tried this with a call to GetCurrentDirectoryA in the kernel32.dll but this shows the same directory:
(E:\Projects\Eurolight 4\EurolightAllInOneDevelopmentImage).
The getCurrentDirectory was called just before  the primitive and still it fails to find it.

the description of the GetCurrentDirectory call is here

It looks like the loading of the oracle dll (oci.dll, which loads a lot of other oracle dlls) messes something up.

Cham

PS make sure that GetCurrentDirectory is ones called before inserting it in ExternalLibrary>>load otherwise
you'll end up with a beautiful loop.

C

Wallen, David wrote:

Try evaluating this:

	Filename findDefaultDirectory

This usually "tracks" the actual local directory on Windows.
Demonstrate by opening a native file dialog, and navigating
to a different directory, and then re-evaluate the above.

- Dave Wallen

-----Original Message-----
From: Cham Püschel [[hidden email]] 
Sent: Friday, November 10, 2006 9:54 AM
To: [hidden email]
Cc: Boris Popov
Subject: Re: Unable to load library (sometimes)

Boris Popov wrote:
  

What are you using for your library path? Relative filenames are prone to 'migrate' around whenever 'current' directory changes,

Cheers!

-Boris

  
    

Hi Boris,

This seems indeed the case. Thanks!
This dll is normally located in the image directory which is also the 
startup dir.
When I evaluate:
Filename concreteClass currentDirectory asAbsoluteFilename

I will get the imagedirectory in both cases but only in one case the dll 
loads.

Any idea?

Cham


  

Filename findDefaultDirectory calls:  Filename defaultClass getDefaultDirectory
This is implemented as primitive 1605 and I assume that on windows this is implemented as the GetCurrentDirectory call (eliot?) How can I find a primitive in the vm sources?

Cham

Cham_Püschel <[hidden email]> wrote:
[snip]
| Filename findDefaultDirectory calls:  Filename defaultClass
| getDefaultDirectory
| This is implemented as primitive 1605 and I assume that on windows this
| is implemented as the GetCurrentDirectory call (eliot?) How can I find a
| primitive in the vm sources?

Since its windows you need only look in the $(VISUALWORKS)/bin/src/platpc directory, so

grep -w 1605 $(VISUALWORKS)/bin/src/platpc/*.c
/blah/bin/src/platpc/ntfile.c: * <primitive: 1605> Filename class defaultDir gets
/blah/bin/src/platpc/ntfile.c:  addCPrimitive(1605, defaultDir, 0);    /* essential */

and then edit the file.  You'll see it is indeed a call on GetCurrentDirerctory(A).
| -----
Eliot Miranda                 ,,,^..^,,,                mailto:[hidden email]
VisualWorks Engineering, Cincom  Smalltalk: scene not herd  Tel +1 408 216 4581
3350 Scott Blvd, Bldg 36 Suite B, Santa Clara, CA 95054 USA Fax +1 408 216 4500

Native Windows file dialogs shouldn't change the OS default directory - VW sets the OFN_NOCHANGEDIR flag in CommonDialogsFileNameRequest>>initialize. What that actually does happen is ensure that Windows sets the directory back at the end - however while the dialog is open, each change of directory in the dialog changes the current directory of the VW process.

This didn't use to matter, since file dialogs were blocking, but now they are threaded - and VW updates damaged areas of its windows when you move the dialog. If the update causes VW to read from a relative filename, it will not be able to find the file - it passes the relative filename to Windows, which evaluates it with respect to the new current directory (whatever is visible in the file dialog).

I've just spent a day or two over the last couple of weeks trying to sort out all the problems this causes. Admittedly Windows docs say you must never rely on the current directory, but still... After I'd made all screen updates reset the OS current directory back to VW's defaultDirectory (which is never changed by Windows), I found that solved the problem in VW. However, the multi-select file dialogs stopped working: they would check at the end whether the selected files existed, and would look in the wrong directory (the one I'd reset for VW, rather than the one they had open). So much for Windows programs not relying on the current directory... I just turned off the flag to check the files existed (the #multipleOld case FileDialogWin32Surrogate>>configureForFileCondition) and made the check in VW instead, and all is now fine almost all the time.

On the rare occasions that the dialog directory change happens during a VW screen update, or some other weird situation, I have a backup solution in the code for opening files. I've taken some bits specific to our situation out and pasted it below, in the hope that it might help someone someday...

This backup solution also helps when other (IMHO) badly-behaved programs change "my" directory - e.g. the Microsoft Office Document Image Writer does this when printing.

Share and Enjoy,
Steve

Filename>>openHandleForDirection: rwMode creation: creationRule
        "Return an accessor on the file named by the receiver with
        the appropriate read/write mode."
        "This message is private, for the use of the IOAccessor
        classes only"

        ^self class handleWrongDirDo:
                [self primOpenFileNamed: osName
                                direction: rwMode
                                creation: creationRule
                                errorInto: self class errorReporter new]

Filename class>>handleWrongDirDo: aBlock
        "If we can't find a file, it may just be that Windows has changed its default directory from under our feet. If so, set it back and retry"
        ^aBlock on: OSErrorHolder nonexistentSignal do:
                [:ex | Filename ensureVWDefaultDirectory notNil
                        ifTrue: [ex returnWith: aBlock value]
                        ifFalse: [ex pass]]

Filename class>> ensureVWDefaultDirectory
        "If the OS current directory is different from what VW remembered, set it back to VW's value and return it, else return nil"
        | vwDefault osDefault |
        vwDefault := self defaultDirectory.
        osDefault := self findDefaultDirectory.
        ^vwDefault ~= osDefault ifTrue:
                [OSSystemSupport concreteClass new setCurrentDirectory:
                        (self class encodeFilename: vwDefault asString)]

[hidden email] wrote:

Cham_Püschel [hidden email] wrote:
[snip]
| Filename findDefaultDirectory calls:  Filename defaultClass 
| getDefaultDirectory
| This is implemented as primitive 1605 and I assume that on windows this 
| is implemented as the GetCurrentDirectory call (eliot?) How can I find a 
| primitive in the vm sources?

Since its windows you need only look in the $(VISUALWORKS)/bin/src/platpc directory, so

grep -w 1605 $(VISUALWORKS)/bin/src/platpc/*.c
/blah/bin/src/platpc/ntfile.c: * <primitive: 1605> Filename class defaultDir gets
/blah/bin/src/platpc/ntfile.c:  addCPrimitive(1605, defaultDir, 0);    /* essential */

and then edit the file.  You'll see it is indeed a call on GetCurrentDirerctory(A).
| -----
Eliot Miranda                 ,,,^..^,,,                [hidden email]
VisualWorks Engineering, Cincom  Smalltalk: scene not herd  Tel +1 408 216 4581
3350 Scott Blvd, Bldg 36 Suite B, Santa Clara, CA 95054 USA Fax +1 408 216 4500



  

Hi Eliot (and others),

I have probably found what is causing the problem.
If you want to change the search order for dlls on windows you should use SetDllDirectory.
Apparently one of the oracle dll calls this function and doesn't release this (calling it with nil).
If I call this function before trying to load my library it loads again.

Now reporting this issue to oracle...

Since SetDllDirectory isn't used by visualworks (at least I couldn't find it in the sources) this is why absolute pathnames fail when the dll is calling another one in the same directory.  A way to fix this is instead of just creating a full pathname (ExtenalLibraryHolder>>findFile:inDirectories:) and supplying this to the ExternalLibrary is to set the name and the directory separate and using these two in the primitive.
So on windows the primitive can call SetDllDirectory. This should (imho) fix this absolute path problem.
Probably a combination of GetDllDirectory and SetDllDirectory is needed to restore a previous set dllsearch path.

Cham