Script Engine Beta 4

[hutch--]

I have spent a few days battering the loader to get it faster and it now loads a 200000 line file with 100000 labels in about 2 seconds on this 2.8 gig PIV which is probably fast enough for the moment.

I have added one new file function that writes a compact form of hex directly to an open file as binary data. There is a sample script called icon.se that writes an icon to a disk file. The idea of this function is so small binary files like icons and toolbar bitmaps can be written directly into the script when generating source code and support files.

[attachment deleted by admin]

[Timbo]

Hutch,

Firstly:  Nice job. :U

I've found a problem with external invocation (namely "dll") when the library in question spawns new thread(s).  It either causes an access violation, or all of the application threads go to sleep and the process has to be killed with Task Manager.  I found this little quirk while throwing together an mp3 player to see what the engine can do.

It's looking really good, though. Keep up the good work. :U

Tim

[PBrennick]

Hutch,
I get an error when I run hex2bin.  It says that the data is the wrong type.

Paul

[hutch--]

Paul,

Apologies, I should have removed the example as I changed my mind on how to implement binary output. I settled for the file function "fhexout" and my testing so far indicates that its a faster alternative.

Tim,

Thanks for the feedback on this one, I need to do some more work on the DLL function as it was written reasonably early in the dev cycle. I have much better operand type recognition at the current state and I will see if there is a way to provide a viable notation that distinguishes between a value in a variable and the address of a variable.

[P1]

Very Nice  :U

But I'll start worrying when it re-programs itself.   :eek

If I use this for more than just MASM32 work, what kind of EULA are you going to distribute with this???

Regards,  P1  :8)

[Timbo]

Hutch,

I figured out what the problem is.  When you call a library function, it seems you are loading the module, calling the function, then unloading the module again.  Is there any way to allow the module to persist and avoid the script engine unloading it until I am ready for it to be unloaded?  I am guessing the call to FreeLibrary isn't returning because it is waiting for the library to terminate its worker threads.

Also, if I manually load the module myself and get the function pointers, how do I call an external by address?

Thanks for your time,

Tim

[hutch--]

Tim,

I have added pointer support to it so that a DLL call can distinguish between an integer variable and an address in a variable. Its in the form,

Code Select Expand


    var = ptr othervar


It seems to be working OK so far. I am just tweaking a test piece with a later version of a BrowseForFolder dialog that returns the user selected directory and when I have it up and going reliably, I will add it into the runtime engine.

P1,

What I have in mind is licenced freeware that can be used in any context including commercial software. I think its OK for a tool like this to be included in commercial software but I will not allow the tools seperate sale.

[Timbo]

Hutch,

Being able to load the library and invoke via address will really give me what I need to publish a nice example for your script engine.

Any thoughts on being able to retrieve the address of a label within the script?

What I'm thinking is a syntax like the following:

[block#someintergervalue]

some scripting takes place here

[/block#someintegervalue]

Whereas we could retrieve the starting address of that block of generated code, which would allow us to write WndProcs, callbacks, and the like.  I understand that this is a pandora's box and can lead to volatile execution, so I also understand what I am suggesting.

Thanks again for your time,

Tim

[hutch--]

Tim,

I am reasonably sure it can be done within the design to get the procedure address with a normal dll call then make a function named something like "call" or similar. The way I do the DLL call is to parse the argument left to right into an array then run the array backwards pushing each arg onto the stack. I then call the procedure address and store its return value in the user defined 32 bit integer.

A "call" type function would only be a minor variation of this where it called a predefined integer variable rather than the address of the procedure name from GetProcAddress() that is used internally.

The address of a label really cannot be done as the script engine is a raw text parser and all a jump or call target is is an instruction offset in the array that contains all of the instructions. The model to do what you have asked would have to be a binary image loaded in memory which is a different animal to this script engine.

I have the pointer "ptr" function up and running and have modified the "dll" function so it passes integers as values and strings by their addresses. Where an integer adress needs to be passed, the "ptr" function does the job.