Loadable code

[Daryl Lock]

Does anyone know of a way to have a PB programme use loadable code in a similar in concept to the DLL? Chaining isn't the solution as control is passed to the chained programme and then out to DOS when it's done. TSRs are a poor relation to the idea, especially since I have NEVER got that darned multiplex to work! The example in the help file is pretty sad at explaining that one...

------------------

[Michael Mattias]

Using PB-DOS, you can use CALL DWORD to execute code you have loaded into your memory space.

I do not know if this will work with "DOS running as a child of Windows" but I've done this under "pure" MS-DOS.

CALL DWORD (PowerBASIC) = CALL ABSOLUTE (certain other brand BASICs)

MCM

[Jerry Mason]

If you can get the loadable code as an object file, you can use
$LINK and DECLARE SUB:

$LINK "filename.obj"
DECLARE SUB SomeSubroutine()

CALL SomeSubroutine()


Of course, it's not usually as easy as all that, but I've used
this method for years to imbed assembly language in my basic code.


------------------

[Mel Bishop]

Originally posted:

Chaining isn't the solution as control is passed to the chained
programme and then out to DOS when it's done.

If you have, for example, a main menu, press a key or click a
button to CHAIN to the program you want. Then, when that program
is finished, CHAIN back to the calling program.

You will have to make up a small .EXE file to call the menu
program, then chain to where-ever you want.

------------------


[This message has been edited by Mel Bishop (edited March 11, 2002).]

[Daryl Lock]

[QUOTE]Originally posted by Jerry Mason:
[B]If you can get the loadable code as an object file, you can use
$LINK and DECLARE SUB:

$LINK "filename.obj"
DECLARE SUB SomeSubroutine()

CALL SomeSubroutine()

Linking isn't the answer since it is still incorporated into the final exe...


------------------

[Daryl Lock]

[QUOTE]Originally posted by Michael Mattias:
[B]Using PB-DOS, you can use CALL DWORD to execute code you have loaded into your memory space.

I do not know if this will work with "DOS running as a child of Windows" but I've done this under "pure" MS-DOS.

CALL DWORD (PowerBASIC) = CALL ABSOLUTE (certain other brand BASICs)

Aha! OK...this sounds closer to what I am looking for..ummm...can you illustrate with an example? Thanks


------------------

[OTTO WIPFEL]

What is the purpose / function of the "Loadable Code" you do not
want to make part of the compiled EXE itself ?



------------------

[Michael Mattias]

On second thought, look at the example under CALL ABSOLUTE. It's a little easier to understand (for me, anyway)..

The procedure to be loaded will need to be in "executable bytes" as shown there.

The code would look something like this

OPEN "codefile.bin" FOR BINARY AS #1
GET$ #1, LOF(1), CodeString$
CLOSE 1
AddressVar = STRPTR32(CodeString$)
CALL ABSOLUTE AddressVar [parameters]

(Hmmmm, it seems you can only get to CALL ABSOLUTE in the help file by going to CALL, paging down to the end and hitting the link to CALL ABSOLUTE. the ABSOLUTE option is not shown in the syntax line for CALL).

MCM

[Daryl Lock]

Originally posted by OTTO WIPFEL:
What is the purpose / function of the "Loadable Code" you do not
want to make part of the compiled EXE itself ?

Smaller EXE

------------------

[Daryl Lock]

Originally posted by Michael Mattias:
On second thought, look at the example under CALL ABSOLUTE. It's a little easier to understand (for me, anyway)..

The procedure to be loaded will need to be in "executable bytes" as shown there.

MCM

Thanks...I think I see my way clear now with that...

------------------

[OTTO WIPFEL]

SMALLER EXEs !

My Accounting and Point-of-Sale Systems, comprising dozens of PB-DOS
compiled EXEs, have to run in Lower Dos Memory in Pure Dos, having
loaded as much as possible of any other stuff such as BTRIEVE into
HIMEM. This usually leaves about 600 K memory for programmes.

I use a MENU.EXE starter which PB-"EXECUTES" to other PB-DOS.EXEs.
To transfer certain Data from one EXE to another, if needed, I save
it to an ordinary text file, say called PB-CHAIN.Dat to be read by
the "EXECUTED"-to PB-DOS.EXE at the start. I also put a code in it
to stop the "EXECUTED"-to PB-DOS.EXE being run in Stand-Alone mode.

In other words, the satellite EXEs can not be run without this code
from the PB-CHAIN.DAT, removed on Exit from it and re-created prior
to the next access from one of the systems programmes.

You many not have to bother with this added measure of security, I
insist upon to prevent misuse of parts ot my systems.

When finished using the "EXECUTED"-to PB-DOS.EXE you can "EXECUTE"
to other PB-DOS.EXEs or back to the MAIN-MENU.EXE.

This way you could run hundreds of EXEs and never run out of Memory !

Simple and easy to program

------------------

[David J Walker]

I use a similar technique, but the MENU.EXE is run from a batch file, creates another batch file called EXECUTE.BAT, which runs the new .EXE after MENU.EXE terminates, and then runs MENU.EXE after the called .EXE terminates.
So there is never any .EXE but the currently running one loaded im memory at any time.
Er, actually simpler than my description makes it seem!

------------------

[Daryl Lock]

Originally posted by David J Walker:
I use a similar technique, but the MENU.EXE is run from a batch file, creates another batch file called EXECUTE.BAT, which runs the new .EXE after MENU.EXE terminates, and then runs MENU.EXE after the called .EXE terminates.
So there is never any .EXE but the currently running one loaded im memory at any time.
Er, actually simpler than my description makes it seem!

Actually I think I found a way...I can have a "blind" exe (no io at all) that does nothing more than watch the value of a set of flags and feed the data as requested by any other running processs to any data structures or variables they put in the XMS shared data area. Basically like a huge DLL...and without overhead.

------------------

[Amos Vryhof]

I am interested in how this is done. I would like to write my
programs so they only load and execute certain pieces of code
when needed.

I would also like to use a similar methode to export functions
from a main program to a sub program loaded in this way.

For example; I have a set of GUI/Mouse routines.

I would like to write the main program that takes care of providing
GUI, Mouse, Font, Icon, etc routines to any program it executes.

I could do this by creating a library and compiling it into each
program, or by doing my own programming language...but I would
like a way to simply program the program in PB, and have the
functions provided bythe main GUI construct program.

Any ideas?

------------------
Amos
mailto:[email protected][email protected]</A>

[Michael Mattias]

I would also like to use a similar methode to export functions
from a main program to a sub program loaded in this way.

For example; I have a set of GUI/Mouse routines.

Hmmm, I think you can do something real close to "exporting" functions by reserving some memory in which to store the "exported" functions.

Use MEMSET to restrict where your regular programs will reside (use in each executable). In your "main" (first executed) module, store your common routines above the memory limit defined by MEMSET; in the "importing" modules use CALL ABSOLUTE to access them.

MCM



[This message has been edited by Michael Mattias (edited March 19, 2002).]

[Daryl Lock]

This is not really much more than my own musings...

The real problem I guess is a limitation in this version of PB. It assumes 'Real' mode of course, so the program 'code' limit is how much memory PB actually sees. It's not as if you can tell the compiler to plonk the compiled code way up there at 4MB or wherever! A 700kb exe is not gonna happen, hence the need to load external executable code without terminating the main exe (as happens with CHAIN). Unfortunately, since PB doesn't produce OBJ files, it means grappling with *shudder* ASM or *gag* C.

I had hoped to use the multitasking kernel of DR-DOS (and it is likely still possible) except the 16 bit portions of that API that are available to PB DON'T suppress screen mode reset when starting a new process (even in the background) nor does it allow a background process to have control of the keyboard and mouse. The 32 bit API is out of PB's reach. I think it is a case of using a 1990 F1 car to win the 2002 series...

An alternative was to use the 2FH interrupt to do the mouse/keyboard IO but considering this would need multiple calls probably many times a second, I can't see that it would gain anything in speed...

Now...if some smartypants could come up with a DLL-style loader for DOS that allows access to, say, routines in a CHAIN-compiled file that has been loaded by other means above 1Mb?



------------------

[Amos Vryhof]

I have been playing with the original exapmle for about a week or so without much success...

Any more info or real good examples of what type of programs can
be "linked" in this way?

I can't seem to get anything I create to load and execute. If I could just get that
figured out, I'm sure I can build off the idea enough to make something useful.


------------------
Amos
mailto:[email protected][email protected]</A>

[Lance Edmonds]

Daryl, it really sounds to me like you have simply outgrown DOS and the limitations it imposes on real-mode DOS applications (from a app-size point-of-view anyway).

Rather than trying to come up with all sorts of difficult and time consuming ways to create bigger programs, have you considered moving over to Windows where you can eat as much of the 2Gb flat address space as you need, and call as many of the 32-bit Windows API functions as you need?

It might just make sense, given your situation...

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Daryl Lock]

Originally posted by Lance Edmonds:


It might just make sense, given your situation...

Aw c'mon Lance...where's your sense of adventure gone? *grin*
I'm no stranger to programming for Windows *yawn* It's the difference between Betty Crocker cake mix and making something out of your dear ol' mum's recipe book...one may be simple to use, easy to bake, leaves no mess and turns out factory precise almost everytime - but which tastes better and gives a greater sense of personal accomplishment, really?

------------------

[Lance Edmonds]

Well, in that case: Good luck with your project!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>