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

[GoogleCodeExporter]

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]

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]

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]

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

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

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