Text only | Text with Images

newLISP Fan Club

Forum => newLISP and the O.S. => Topic started by: Sammo on November 17, 2004, 10:49:28 AM

Title: link to newlisp.dll
Post by: Sammo on November 17, 2004, 10:49:28 AM
In a manner similar to


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


Code Select
(link "newlisp.dll" "my.dll" "mysource.lsp") would result in a usable 'my.dll' augmented with mysource.lsp's definitions?
Title:
Post by: HPW on November 17, 2004, 01:08:16 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?
Title:
Post by: Lutz on November 17, 2004, 03:58:43 PM
This is already working since 7.3.16, but not documented ...



Lutz
Title:
Post by: HPW on November 17, 2004, 10:47:53 PM
>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:
Quote
;; 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!
Title:
Post by: HPW on November 17, 2004, 10:54:59 PM
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!
Title:
Post by: HPW on November 18, 2004, 01:22:10 AM
I have problems to get it to work:



I linked the following to the DLL:
Code Select

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

> (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.
Title:
Post by: HPW on November 18, 2004, 02:27:46 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.
Title:
Post by: HPW on November 18, 2004, 02:43:31 AM
Oops, just tried from TK:


Code Select

> (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.
Title:
Post by: Lutz on November 18, 2004, 05:23:02 AM
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
Title:
Post by: HPW on November 18, 2004, 06:29:29 AM
>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)
Title:
Post by: HPW on November 18, 2004, 06:45:43 AM
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)
Title:
Post by: HPW on November 18, 2004, 06:59:19 AM
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.
Text only | Text with Images