Does anyone have experience creating DLLs called by C from Lispworks for
Windows? I created a DLL that works properly when called by C in normal
mode, but crashes when called by C in debug mode and when called by C from
Java -- Java calls what it thinks is a native C function, but it's the
routine in the Lisp DLL.
In one version, the initialize function prints out "hello world" in a
Capi window. This worked, but the DLL crashed during the C call to
GetProcAddress.
The delivery routine looked like:
(deliver 'initialize "cd" 3
:symbol-names-action nil
:interface :capi
:dll-exports '("get_hint" "process_play"
"get_current_play_lesson_explanation" "analyze_play" "play_next_card"
"correct_play_p" "legal_play_p" "final_score"
"get_summary" "start_game1" "start_game2" ))
(quit)
Thanks,
Neil
Neil Cohen
Bridge Trix
Producers of the Bobby Wolff Bridge Mentoring Series
http://www.bridgetrix.com
In article <·······················@max3-102.ip.realtime.net>,
······@bridgetrix.com (Neil Cohen) wrote:
>Does anyone have experience creating DLLs called by C from Lispworks for
>Windows? I created a DLL that works properly when called by C in normal
>mode, but crashes when called by C in debug mode and when called by C from
>Java -- Java calls what it thinks is a native C function, but it's the
>routine in the Lisp DLL.
>
> In one version, the initialize function prints out "hello world" in a
>Capi window. This worked, but the DLL crashed during the C call to
>GetProcAddress.
>
> The delivery routine looked like:
>
>(deliver 'initialize "cd" 3
> :symbol-names-action nil
> :interface :capi
> :dll-exports '("get_hint" "process_play"
>"get_current_play_lesson_explanation" "analyze_play" "play_next_card"
>"correct_play_p" "legal_play_p" "final_score"
> "get_summary" "start_game1" "start_game2" ))
>
>(quit)
>
>
> Thanks,
>
> Neil
The DLL also works fine when called by Rundll32. Here's further
information:
Over the weekend, I tried a bunch of different approaches to running your
dll from a C program, but I still got the same error. It seemed that
Rundll32 is doing something that my C++ program was not, but I didn't have
a clue what that could be.
I found out one new thing, however. It turns out it wasn't crashing
during the invocation of the hdefun routine (or the mult routine in your
earlier dlls). It was actually crashing during the LoadLibrary
call. LoadLibrary simply loads the dll into memory, but that also triggers
a lisp startup routine. It's this startup routine that was regularly
crashing, and what fooled me is that the startup routine doesn't crash
immediately--it eventually creates a thread, and something in that thread
crashes after a very long period of time (i.e. 15 seconds or so). It's as
if the startup routine were looking for something, but then crashes when it
doesn't find it (I tried putting the dll into C:\Windows, for example, but
that didn't help either). There's no such delay (and no crash) when I run
your dll with Rundll32.
Neil Cohen
Bridge Trix
Producers of the Bobby Wolff Bridge Mentoring Series
http://www.bridgetrix.com
You might want to try keeping the TTY debugger in your delivered dll. Maybe
the debugger will start up and give some indication of what is going wrong.
Use the keyword :keep-debug-mode
(deliver 'initialize "cd" 3
:symbol-names-action nil
:interface :capi
:dll-exports '("get_hint" "process_play"
"get_current_play_lesson_explanation" "analyze_play" "play_next_card"
"correct_play_p" "legal_play_p" "final_score"
"get_summary" "start_game1" "start_game2" )
:keep-clos-object-printing t
:keep-eval t
:keep-function-name t
:keep-lexer t
:keep-lisp-reader t
:keep-load-function t
:keep-modules t
:keep-structure-info t
:keep-top-level t
:keep-walker t
:top-level-listener-p t
:keep-debug-mode t
:compact nil)
See
file:///D:/Harlequin/LispWorks/lib/4-1-0-0/manual/online/web/DV-W/html/D_104
.HTM#HEADING104-0
Wade
Aha!! You just said the magic words....
> earlier dlls). It was actually crashing during the LoadLibrary
> call. LoadLibrary simply loads the dll into memory, but that also
triggers
> a lisp startup routine. It's this startup routine that was regularly
> crashing, and what fooled me is that the startup routine doesn't crash
> immediately--it eventually creates a thread, and something in that thread
I believe that the DLL startup routine is restricted in what it is permitted
to do. I know it cannot also call LoadLibrary (I just went through a similar
exercise with ACL/6.1). It may also be forbidden to launch additional
threads at that particular time.
How this information translates into something more helpful to you is not
clear to me at this early time....
- DM
Certainly, one recommendation I would make, is to ensure that your startup
routine does little more than return TRUE -- indicating successful loading.
Then make a separate entry point in the DLL that must be called to kick
things off. At that point you can safely spawn threads and call LoadLibrary.
- DM
I went the other way (Lisp calls C dll). All of my crashes were due to
calling convention mismatches (:stdcall vs. :cdecl). The symptoms were
similar - it appeared to work some of the time, e.g. entry points with no
args worked, but entry points with args caused crashes.
pt
In article <·························@news3.rdc1.on.home.com>, "Paul
Tarvydas" <·········@tscontrols.com> wrote:
>I went the other way (Lisp calls C dll). All of my crashes were due to
>calling convention mismatches (:stdcall vs. :cdecl). The symptoms were
>similar - it appeared to work some of the time, e.g. entry points with no
>args worked, but entry points with args caused crashes.
Thanks for the suggestion. Don't think it's the problem here -- it
worked fine for all functions, including those with arguments, when called
from normal C, but not from C using the debugger (within a Visual C++
environment). At any rate, the FLI for my code didn't specify the
calling-convention keyword, but according to the documentation, when the
language is C, the default, the default calling-convention is :cdecl.
But, it's certainly worth the experiment to try it the other way.
Neil
Neil Cohen
Bridge Trix
Producers of the Bobby Wolff Bridge Mentoring Series
http://www.bridgetrix.com