renan-guimaraes / dwscript

Automatically exported from code.google.com/p/dwscript
0 stars 0 forks source link

[Enhancement/Doubt] Is DWsrcipt able to load dinamically/statically a DLL? #371

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Hi could not find in the docs if DWScript is able to load dinamically a DLL or 
event statically within its scripts (using the LoadLibrary and GetProcAddress) 
or load the library statically binded to the methods inside a script?

Original issue reported on code.google.com by fdue...@gmail.com on 20 Apr 2013 at 5:38

GoogleCodeExporter commented 9 years ago
It can't do this by itself, unless you create a system to marshal calls from 
DWS to the library.

Original comment by frederic...@gmail.com on 20 Apr 2013 at 12:18

GoogleCodeExporter commented 9 years ago
wel my doubt was if it already implement the functions LoadLibrary and 
GetProcAddress to optain the Method adress and asociate them to a variable, or 
if they can be implemented by us easily. Or maybe bind them statically witht 
methods and the CDecl.

This is a feature that other pascal scripters like TMS Scripter,PaxScript and 
PaxCompiler has. Just wanted to know if it can be done that way. DWScript is a 
good candidate to be used but want to know if can do those things easily.

Original comment by fdue...@gmail.com on 20 Apr 2013 at 3:25

GoogleCodeExporter commented 9 years ago
There is an optional COM connector which can access all ActiveX and COM 
objects, but no low-level DLL access at the moment.

The difference between DWScript and those other script engines is that DWScript 
is sandboxed and safe by default, i.e. the aim is that out of the box, scripts 
can't access anything you don't want them to, can't leak memory, and can't make 
the host application or service unstable or crash it. None of the 3 engines you 
cited aims for that, and direct access to DLLs would break that sandboxing.

That said, it should be possible to make an optional module or language 
extension to do that (just like the asm extension f.i.), by declaring function 
symbols and marshaling the calls to them.

Original comment by zar...@gmail.com on 21 Apr 2013 at 3:34

GoogleCodeExporter commented 9 years ago
You're right it is better to stay sandboxed. But then i could add this support 
manually.
any guidelines where can I start? maybe registering the functions that will 
load and unload the dll?, and then how to get the procedure address? the same 
way? registering like function like GetProcAddress?, obviously this is the 
dynamic way.

Any guidance where to start is appreciated. Thanks

Original comment by fdue...@gmail.com on 8 May 2013 at 4:09