Interpreter inside a database

[Chris Holbrook]

It just occurred to me that an interpreter could be stored in a database (I'm for SQLite!) and executed from there by using a loader program. Would ThinBASIC "work" in this context?

[Michael Clease]

Chris could you expand on this this please, I am interested in what you are thinking.

[Charles Pegge]

Hi Chris,

Do you mean storing TB scripts in a database?

[Chris Holbrook]

Hi Charles,
I was thinking about also storing the interpreter, then executing a loader program(load <table> <column>) which loaded it. I imagine that it would drive Windows firewall crazy.

Hi Michael,
It was just thinking that it would be a neat way of distributing an application, or maybe a step on the road to platform independence. The application user (as opposed to developer) doesn't really need an interpreter, just an application.

[Chris Holbrook]

Just knocked up a PowerBASIC applcaition to store any file type in BLOBs in a SQLITE DB and execute exes. To my shame I have forgotten what changes would be required to create a TB script from this application, so it's RTFM time!

[Petr Schreiber]

Hi Chris,

I am not sure if it is exactly what you want, but you can bundle script to single EXEcutable (Script/Bundle).
Maybe you could embed the final EXE to the table.

Problem could be that the bundle once executed, temporarily extracts DLLs in the directory it is executed in, and cleans it up after execution.


Petr

[Chris Holbrook]

Hi Petr,

Yes, I see what you mean, but was thinking about running an interpreter from the DB without creating any files outside the DB.

An example would be a SQL script interpreter with a command line interface, the scripts being stored in the DB.

[Charles Pegge]

Hi Chris,

I can see the possible uses for this sort of system, for instance a database of demo programs would make the task of building applications much easier. What sort of programs would you envisage storing in the database?

At present I don't think you can retrieve a TB script in a string variable and then execute it directly within the same instance of TB.

However it is possible to do this with Oxygen source code which will JIT compile to machine code in a fraction of a second and be executed in memory. (without generating an EXE file). You could also store the compiled Oxygen binary strings (blobs?!) in the database if so desired, and invoke them directly within thinBasic.

[Chris Holbrook]

Hi Charles,
Although - as usual - I was thinking about a specific application when I started, there seems to be some interesting territory here, maybe not unexplored, but seldom visited. Encapsulating all an application's code and data in a single file has attractions if you are distributing code, and the installation and software CM of same is also greatly simplified. By simplifying, you also potentially make the thing more reliable on the "fewer parts" principle.

It would be nice to get some familiarity with this approach by developing an application to inhabit such a database. One problem is passing control between different modules, whether scripts or exes. It could be done by using a loader application which "knew" it was running in a DB enivronment, and could perform a "shell" type function.

I have a feeling that I need to bone up on Oxygen! Yet another gap in my education.

[Charles Pegge]

Chris, This idea is well worth pursuing so I am posting a barebones conceptual example where ThinBasic provides
the database and user i/o, and the programs are held as oxygen source strings - retrieved then dynamically compiled.

[Chris Holbrook]

Charles,

I will post an e.g. over on PowerBasic which stores exes (well, anything really) in Blobs inside a SQLite DB and allows the exes to be shelled to.

PS I just realised - we're both in Wales, do you think we might get a grant for this?

[Charles Pegge]

Hi Chris,

Grants are hard to obtain but we may well be awarded a bouquet of leeks :D

I've posted the TB/Oxygen example here:
http://community.thinbasic.com/index.php?topic=3202.msg23952;topicseen#new

[Chris Holbrook]

Charles, thanks for your example!

Can APIs be called from Oxygen?

[Charles Pegge]

Yes Chris,

Oxygen will accept headers in the QB/PB/TB/FB genre - Native C headers are also in the pipeline.

It is also possible to access API calls without defining prototypes which is very compact and works well as long as you provide matching variable types when passing parameters.

But I have a lot of checking to do, before exposing it to the full Windows API :read:

[Chris Holbrook]

It is also possible to access API calls without defining prototypes which is very compact and works well as long as you provide matching variable types when passing parameters
as in the full set of windwoes types? or the "shorthand" set as used in PB etc?

[Charles Pegge]

With Basic Prototype Declarations, double-pointered variables etc get messed up and you have to degrade them to dwords. This is because Basic does not support the typedef constructs found in C. So translating C headers to Basic headers will require considerable interpretation, which is why I aim to read C header files directly.

Now for interfacing APIs at a lower level, all the compiler needs to know is the library handle, and a list comprising pairs of alias names and real case-sensitive names for each call available. No type matching is attempted - so you have to know what you are providing is compatible with the library call - for instance it is ok to provide a dword when a byte is expected. And you must explicitly pass the variable's adress when a pointer is expected.

This is an example of low level API declaration in Oxygen (the semicolons are comment marks)



dim kernel32,user32,GDI32 as long
kernel32=LoadLibrary `kernel32.dll`
user32=LoadLibrary `user32.dll`
GDI32=LoadLibrary `GDI32.dll`

bind kernel32
(
GetCommandLine GetCommandLineA ; @0
GetModuleHandle GetModuleHandleA ; @4
ExitProcess ExitProcess ; @4
)

bind user32
(
LoadIcon LoadIconA ; @8
LoadCursor LoadCursorA ; @8
RegisterClass RegisterClassA ; @4
MessageBox MessageBoxA ; @4
CreateWindowEx CreateWindowExA ; @48
ShowWindow ShowWindow ; @8
UpdateWindow UpdateWindow ; @4
GetMessage GetMessageA ; @16
TranslateMessage TranslateMessage ; @4
DispatchMessage DispatchMessageA ; @4
PostQuitMessage PostQuitMessage ; @4
BeginPaint BeginPaint ; @8
EndPaint EndPaint ; @8
GetClientRect GetClientRect ; @8
DrawText DrawTextA ; @20
PostMessage PostMessageA ; @16
DefWindowProc DefWindowProcA ; @16
)


bind GDI32
(
SetBkColor SetBkColor ; @16
SetTextColor SetTextColor ; @16
GetStockObject GetStockObject ; @4
)