Lisp HUG Maillist Archive

windows dll bug - need suggestions

I'm staring at a Lispworks + windows DLL bug that I haven't figured out - 
maybe someone can make a suggestion that will break my mental logjam:

DLL "A" is a commercial dll - I want to give it an HWND to a capi:output-pane 
and have the dll scribble on the window

DLL "B" is a small C wrapper that lessens the amount of plumbing that I have 
to do 

My LWW program loads the two dll's, then calls DLL "B", which calls DLL "A", 
and DLL "A" writes something onto my capi:output-pane.

Test 1:

When I perform a simple test - open a capi:output-pane, then call "B" - it 
works.


Test 2:

But when I create a :display-callback for the output-pane, and call "B" from 
the :display-callback, the result crashes horribly (register dump).  It acts 
almost as if the dll's were not loaded, or some instance data has not been 
instantiated.  Trying to load the dll's in the (initialize-instance :after) 
method of the parent interface (i.e. hoping to load the dll's from the 
process belonging to the interface) doesn't change the behaviour.


I'm probably missing something "obvious".  Any thoughts?

thanx
pt


Re: windows dll bug - need suggestions

On Sun, 25 Nov 2007 14:19:31 -0500, Paul Tarvydas <tarvydas@visualframeworksinc.com> wrote:

> I'm probably missing something "obvious".  Any thoughts?

Have you tried if calling SYS:SETUP-FOR-ALIEN-THREADS first makes a
difference?  (It doesn't fit exactly with your description, but you
never know...)


Re: windows dll bug - need suggestions

On Sun, 25 Nov 2007 15:45:42 -0500, Paul Tarvydas <tarvydas@visualframeworksinc.com> wrote:

> Does Windows know enough to load dll's required by other dll's?  Do
> I need to call LoadLibrary in DLL "B" (to load "A")?

>From my experience with libraries like CLSQL, Windows indeed does know
enough, i.e. it will load DLLs referenced by the DLL you're
registering.  (If it can find them - see below.)

> (fli:register-module "B" :real-name "dll/debug/B.dll")

This looks strange to me.  (I'm not saying that it is wrong, I'm just
wondering if it works.)

I thought it works like this: If :REAL-NAME gets an absolute pathname,
it will load exactly the file specified.  If :REAL-NAME gets a
relative pathname, it should be of the form "foo.dll" and then the OS
will search[1] for the library.

I would try without the second call to FLI:REGISTER-MODULE and I'd
move B.dll to a place where Windows can find it.  /Maybe/ in your case
B.dll is loaded twice or something like that?


[1] http://msdn2.microsoft.com/en-us/library/7d83bc18(vs.71).aspx


Updated at: 2020-12-10 08:44 UTC