Script Engine Beta 7

[hutch--]

With thanks to Tim for his assistance in developing the DLL call code, I have implemented direct versions of LoadLibrary(), GetProcAddsress() and FreeLibrary() to make the direct calling code a lot cleaner and easier to use. I have also renamed the calladdr function to STDCALL and collectively it delivers a notation like this.

Code Select Expand


; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

    INTEGER hUser
    INTEGER MessageBox
    INTEGER void

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

    hUser = LoadLibrary "user32"

    MessageBox = GetProcAddress hUser "MessageBoxA"

    void = STDCALL MessageBox 0 "Make an STDCALL API function call" "Welcome" MB_OK

    void = FreeLibrary hUser

    end

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

I have added the system based file commands, copyfile, movefile and deletefile to compliment the existing file IO functions.

[attachment deleted by admin]

[Timbo]

Hutch,

I am currently writing a tool that will create a script from any DLL.  It will write the script using the plain names of exported functions as an integer array like the following, and also write the script code required to get the loader into memory.

Code Select Expand


INTEGER SomeLibFunc1
INTEGER SomeLibFunc2
INTEGER SomeLibFunc3

INTEGER &SomeLibFuncBlockPtr
&SomeLibFuncBlockPtr = ptr SomeLibFunc1

It will then write, assemble, and link a "loader" dll for the target library.  All the loader will be responsible for is loading the actual library into memory and writing the addresses of the exported functions into the array that is declared in the script (in the same order, of course), and unloading the library when the user is done with it.

Code Select Expand


INTEGER hLoaderLib
hSomeLibLoader = LoadLibrary "seLoadLib_SomeLib"
INTEGER LoaderLib_Load
LoaderLib_Load = GetProcAddress hLoaderLib "Load"
#1 = STDCALL LoaderLib_Load &SomeLibFuncBlockPtr
;now you have a functional array of pointers with meaningful names

What do you think of this approach?  It would be useful for creating a script "header" I think.  This brings me back to asking about inclusion of auxillary script files. :green2

Tim

[Timbo]

Hutch,

Attached is an example of what I was trying to describe.

Tim

[attachment deleted by admin]

[hutch--]

Tim,

It looks like a good tool that produces the exported function names. I had a look at the fmod site you mentioned in the script and seems to be high quality software that is a very mature package. What I am trying to do at the moment is get enough runtime functions into it to make it more useful. I have added the system file functions and have a reasonable amount of console mode support done for it.

External files are a problem at this stage of development in that I am developing the engine as a single exe that must perform both loader and runtime tasks and while it is reasonably easy to do, it interferes with the original design of the script engine being a simple self contained unit. I have a 450k equates file for it already that is close to exhaustive for Windows and the hash table is easily fast enough to handle the whole lot but it then entails dependency with the scripts.

What I had in mind further down the track is to seperate the loader and the runtime engine and treat the loader much more like a script compiler and this will allow external file that contain equates and the type of header information your tool produces. Even after bashing it to death, the loader is still a lot slower than the runtime engine and by seperating them, a prebuilt script that has the loader processing already done will load almost instantly.

There is another consideration I have in mind so that the script engine can be used in a secure environment under the control of a sys admin. With loader and runtime engine seperated I can encrypt the script coming out of the front half so the runtime engine will only run a script encrypted by a specific loader. This is to address the rogue script problem. I am inclined to make facilities that each installation of the engine creates a reasonable size unique random pad which of course will be different for each machine it is installed on.

Someone with a bank of supercomputers cold break the pad due to reuse but this method puts rogue scripts out of the range of trojans and the like as the sysadmin can keep the encrypted script production elsewhere.

[Timbo]

Hutch,

You have a bug (or it is a feature?) with "fileopen".  It seems you aren't zeroing your filename buffer that you use with GetOpenFileName which means a test against a null string is meaningless on successive calls to fileopen.

I have put my tool on hold for the moment, as I have come up with a better model for handling externals required by a module.  With the external references in the script being handled by a library called by the script engine itself, you can allow a syntax with the script for external modules to be declared.  Maybe something like the following?:

Code Select Expand


#externdecl Somelib

You then pass the name of the library to load to the loader lib and it returns a small structure that gives you the number of functions, a pointer to an array of strings (the plain names of the exported functions), and a pointer to an array of pointers (the function addresses).  You then have everything you need to resolve externals to addresses. You could maybe add some syntax to tip the parser off to an external such as:

Code Select Expand


void = STDCALL SomeLib->SomelibFunc
Which would make calling externals effortless and seamless for the user for the most part since you would no longer require the user to declare a variable then manually load the address before calling.

Just a couple of ideas,

Tim

[hutch--]

Thanks Tim, I will chase this up. I have the console mode stuff running OK at the moment.