link to newlisp.dll

Sammo · Post by **Sammo** » Wed Nov 17, 2004 6:49 pm

In a manner similar to

(link "newlisp.exe" "myProg.exe" "mySource.lsp")

is there any chance that

Code: Select all

(link "newlisp.dll" "my.dll" "mysource.lsp")

would result in a usable 'my.dll' augmented with mysource.lsp's definitions?

HPW · Post by **HPW** » Wed Nov 17, 2004 9:08 pm

Hello Sam,

Since newlisp.dll can not run standalone, this wish make not so much sense for me. You can embed your lsp in your calling app.

What do you want to reach?

Lutz · Post by **Lutz** » Wed Nov 17, 2004 11:58 pm

This is already working since 7.3.16, but not documented ...

Lutz

HPW · Post by **HPW** » Thu Nov 18, 2004 6:47 am

>This is already working since 7.3.16, but not documented ...

Hello Lutz,

Surprise!
(Still nice secrets inside newLISP!)

Does it work in the same way as the EXE?
Also I think it will not work with the runtime-packed version of the DLL,
which I deliver with hpwNewLISP-plugin.
I have tried it with a runtime-packed EXE and this does not work.

So is it this:

;; When importing a linked win32 dll from win32 programs other
;; then newlisp.exe, than the following statment should be executed
;; directly after importing functions and before any 'dllEvalStr'
;; statment: (dllName <name-of-dll>) where <name-of-dll> is the file
;; name of the linked win32 newlisp dll. This will enable the autoload
;; of linked newlisp source in the dll. When importing to newlisp.exe
;; this is not required.

Init.lsp is no more executed with the new DLL!

HPW · Post by **HPW** » Thu Nov 18, 2004 6:54 am

And of cource I had to provide this new call '(dllName "mynewlisp.dll")' in the hpwNewLISP wrapper plugin, because it only uses 'newlispEvalStr'.

Lutz:
Correct your link.lsp source

Write newlispEvalStr and not the older deprecated dllEvalStr.

And about naming conventions:

Wouldn't be 'newlispAutoLoad' better than 'dllName'?

If so do it now when it is introduced before someone use it!

HPW · Post by **HPW** » Thu Nov 18, 2004 9:22 am

I have problems to get it to work:

I linked the following to the DLL:

Code: Select all

;(link "newlisp.dll" "myNewLISP.dll" "MyTest1.lsp")
;(import "mynewlisp.dll" "dllName")
;(dllName "mynewlisp.dll")
;(import "mynewlisp.dll" "newlispEvalStr")
(setq MyTest1 1)
(setq MyTest2 "Banane")

From newLISP-TK I do:

Code: Select all

> (import "mynewlisp.dll" "newlispEvalStr")
newlispEvalStr <6BD67FB0>
> (import "mynewlisp.dll" "dllName")
dllName <6BD67F80>
> (dllName "mynewlisp.dll")
1
> (get-string(newlispEvalStr "MyTest1"))
"1"
> (get-string(newlispEvalStr "MyTest2"))
"\"Banane\""

Is the return-value of dllName = 1 right?
dllName switch it on and the next EvalStr evaluate the attached code.

Should a linked lisp.dll work the same when called with
the normal calling commands? From a new test-plugin
it crashes the hole app. A unlinked renamed newlisp.dll
works at that point. So with linked dll's always call dllName first.

HPW · Post by **HPW** » Thu Nov 18, 2004 10:27 am

Some things got clearer now.

The return-value from 'dllName' (1) is an Integer and not a PChar.

When I call newlispEvalStr on a linked DLL without calling dllName first,
it crashed. When I call dllName first, everything works as expected.
When I free the DLL I have to call dllName at first again.

HPW · Post by **HPW** » Thu Nov 18, 2004 10:43 am

Oops, just tried from TK:

Code: Select all

> (import "mynewlisp.dll" "newlispEvalStr")
newlispEvalStr <6BD67FB0>
> (get-string(newlispEvalStr "(setq a 10)"))
"10"
> (get-string(newlispEvalStr "MyTest1"))
"1"
> (get-string(newlispEvalStr "MyTest2"))
"\"Banane\""
>

Works without calling 'dllName'??

>When importing to newlisp.exe this is not required.
Ok, I see it to late.

Lutz · Post by **Lutz** » Thu Nov 18, 2004 1:23 pm

The DLL needs to know it's name for a GetModuleHandle() call to Win32. By default this name is "newlisp.dll". When the dll is renamed a call to 'dllName' must be the first call, so subsequent calls to 'newlispEvalStr' work correct. Yes, the return value of 'dllName' should be 1.newLISP does the call to dllName automatically.

The whole feature will stay undocumented. As you say: DLL users should pass source from the parent.

Lutz

HPW · Post by **HPW** » Thu Nov 18, 2004 2:29 pm

>The whole feature will stay undocumented. As you say: DLL users should pass source from the parent.

Then the question is: Should I make it public in my wrapper (I have a working prototype)

HPW · Post by **HPW** » Thu Nov 18, 2004 2:45 pm

Until now the Dll-name is hardcoded in the wrapper-plugin.
I could also modify the prototype that it works only with a customised plugin named 'newlisp.dll'. (No parameter DllName)

HPW · Post by **HPW** » Thu Nov 18, 2004 2:59 pm

After a second thought, there is no need for further improvment.
It will work with the current plugin, as long the user rename his customised DLL back to 'newlisp.dll'.
Then is there no need for 'dllName' and it work right out of the box. I just tested it.