link to newlisp.dll

[Sammo]

In a manner similar to

Code Select Expand

(link "newlisp.exe" "myProg.exe" "mySource.lsp")is there any chance that

Code Select Expand

(link "newlisp.dll" "my.dll" "mysource.lsp") would result in a usable 'my.dll' augmented with mysource.lsp's definitions?

[HPW]

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]

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



Lutz

[HPW]

>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]

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]

I have problems to get it to work:



I linked the following to the DLL:

Code Select Expand


;(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 Expand


> (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]

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]

Oops, just tried from TK:

Code Select Expand


> (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]

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]

>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]

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]

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.