Overlays

[Walt Decker]

In quickbasic 4.5 and PDS 7.x a number of files can be seperately compiled and then linked together as overlays. Overlays are similar to DLLs in that they are loaded dynamically when called and then unloaded when not needed. This allows a minimal kernal in memory with a little loss in execution time. Is there a method to do the same in PB3.5?

[Lance Edmonds]

PB/DOS provides only the CHAIN method for runtime operation - there is no support for overlays.



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

[Walt Decker]

Thank you, Lance. I thought that was the case. Too bad. With overlays one can produce huge programs with only a small amount in memory at any one time. Perhaps it could be implemented in the future.

[Michael Mattias]

FWIW:

1. Overlays are NOT supported in Microsoft QuickBASIC 4.5; they are supported in Microsoft Professional Development system.

2. Using the PB/DOS function CALL DWORD, there is no reason you cannot load your own code modules dynamically. I do not think you'd be able to make the loaded modules PowerBASIC modules, as I'm not sure you can locate the entry point of a procedure in a PBU file unless that PBU is $LINKed at compile time. (Or maybe someone can think of a way to do that).

And, you'd have to manage yourself "which procedure is currently in memory", but this might be worth a little exploration.



-------------
Michael Mattias
Racine WI USA
[email protected]

[Matthew Berg]

Perhaps it would be possible to use INT 21h FUNCTION 4Bh "LOAD AND/OR EXECUTE PROGRAM" (see RB's Interrupt List) to load overlays or modules? I have not investigated the possibility of using this myself.

[Lance Edmonds]

I would have thought the RUN or EXECUTE statements would be easier then using the interrupt...

Note: It is also possible to CHAIN to EXE files as well as PBC modules - the same rules apply.

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

[Walt Decker]

I doubt if using run, execute, or interrupt would work to simulate overlays. Using run and execute, the current prog is unloaded thus losing it's data. With interrupts, one would somehow have to find the address at which the overlay was located.

Chain is not such a good choice either. Consider a spredsheet that allows a user to write his own formulas for calculations. The formulas can include many of the more esoteric math functions. Most users would not use them but some would. Now, the code can include those functions or you can write two progs, one with and one without them, or you can write one prog with the math functions as overlays. In the first case, the math functions would just sit in memory taking up programming space most of the time. In the second case, one would have to chain to the app containing the functions and in the process pass the data, the line number calling the functions, and a host of other information. With the last case, it's just a simple call. Much easier to implement, much more convient.

Perhaps a better way would be to use a TSR. However, I'm not sure, since I'm new to pb, if one can do that with the pop-up.

[Matthew Berg]

If you want to try using a TSR, you can use the POPUP INTERRUPT to have your TSR code hook an interrupt, which you can use from your main program to invoke functions in the TSR. Interrupts F1h to FDh are reserved for your own use.

[Wyman A Belts]

How 'bout the Shell statement?

[Walt Decker]

If one wanted to use a TSR couldn't the procedures be declared PUBLIC in the TSR and then just call them from the main module instead of going through the INTERRUPT?

As for SHELL, I guess one could pass some parameters through the command line or write them to a temorary disk file (perhaps a virtual memory address?), but then how would the return values be passed back? I suppose one could write them to a virtural memory address (hopefully the data would not be destroyed on return) or one could write them to a temporary disk file. SHELL, I think, would be going through more hoops than is really necessary.

[Mike Luther]

Walt ..

If it isn't all that great a bundle of switches, grin, passing the
parameters in a small file on the disk and using the SHELL game is really
not such a bad deal at all, perhaps. DOS is far from dead on cheap
boxes. Come LINUX time a 486 is a terrible thing to WAIS! Chuckle.

One reason it's an interesting way to get things done is that for network
purposes, you can split the work load across machines and the network.
Not only can you use the disk for slush, but you can echo it elsewhere, or
chunk it over on another directory across the network. In doing that,
you can operate on the data for local purposes, using the shell. If you
are using a multi-tasking system, such as OS/2, you can have 8 or 10
separate instances of a PowerBASIC execuatble operation going even in DOS!

Using the common data file, you can then have half a dozen different client
operations in good old DOS going on a gaggle of workstations all at once,
spawned off that joint, or joint and operated-upon data file(s). Using
the stunt the whole gaggle of geese squawk as instructed, but use the data
in near real-time in, perhaps many different ways.

It's sort of a cheap server-client push trick you can pull off even in DOS!

For example, one of several places we use the trick is to post the entire
inbound and outbound CNID and all call progress tracing across six lines
of phone service in a facioity! It is slushed in several shared common
random access files on the server from whatever workstation has the
Rochelle sniffer in operation. Then, another operation on the server,
sniffing for changes in the file on a looping basis, the loops carefuly
coded in PowerBASIC so as to not trash the CPU during polling, may or
may not make changes, itself, in the file(s), as well. It also may post
other files for similar shared read on the server for more clients to use
for instructions and data!

Any workstation, running an application executable, may not only make use
of that shared data in their executables, but, in cases where the required
operations are too big for the main module, or, for example, where we want
to run an external custome editor, can then SHELL out to that, perhaps,
third party program using the common, but then privately copied data
file, all generated from the original spawned data file!

Yes, it is convoluted! Yes, considering the fact that more modern
operating systems have access to far more memory in their memory models
may not need such thrashing! But if you think about it, you can get a
terrific amount out of nothing but DOS, provided the operating system
is good enough to let you run protected instances of it!

By the way, when you start to play this SHELL game, pay close attention
to a utility that is available for PowerBASIC for DOS called ULTRASHELL.
It's worth every penny you'll spend for it, as it can reduce the entire
main program into ahout 5K of upper memory! That leaves you most all of
the actual main memory for re-use. It's almost like being able to, at
will, use dozens of massive pseudo-TSR's, all carefully orchestrated to
get what you seem to want to do done, but with near total memory for
any one of them on command!

Quite frankly, ULTRASHELL opened up a complete re-birth of the utility
of DOS for us. Between that, and OS/2 - we've been doing what appear
to be simultaneous operations for years now, totally protected from one
another, happy as a dead pig in the sunshine. Lots here know I champion
OS/2 .. In my humble opinion, the only thing wrong with it was it was too
darned good, a bit too far ahead of the desktop time, and victim of an
IBM that, for marketing purposes, in this case, couldn't track the
elephant in a snow storm with a bloody nose!

Sigh..

I've never been able to run more than a couple PowerBASIC for DOS
applications at one time in a WIN-95 box, for what we do, without the
whole box grinding into too slow a response time. On the other hand,
I have no experience with WIN-98B boxes, or WIN-NT4 boxes that are
asked to run PowerBASIC DOS applications. I've heard the WIN-98B is
really a subset, sort of, of WIN-NT4. It may well be that you could
get a cheap trick deal out of them this same way as we do in OS/2.

Just thoughts for you about how you can stretch every penny out of things!

-------------
Mike Luther
[email protected]

[Lance Edmonds]

Win98's DOS support is basically the same as Win95's, and therefore DOS services are handled by Windows quite differently to Windows NT and Windows 2000.

The key to successfully running multiple DOS applications is plenty of RAM, and adjusting the "Detect Idle Time" and "Background Suspend" settings in the Properties of the DOS boxes, plus releasing time-slices to Windows when the code is not running time-critical tasks, ie, when waiting for keypresses. I've posted code to show how to do this before (using a single interrupt call)


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

[Paul Mullen PC Guru]

I'm running out of memory too and would like to see either overlays or a protected mode DOS environment.

Some of the earliest compiled basic programs I wrote - BASCOM back in 1978 on CP/M micros used an overlaying linker called PLINK.
As I recall you defined blocks of subroutines that should be placed in each overlay. Obviously you can't call a routine in one overlay from a routine in another - only from a routine in "common" or another routine in the same overlay.

The linker then generated code which checked that the correct overlay was in memory, and if not loaded it, before each call.

Of course it would be even better to have a protected mode environment (apart from Windows) which would give access to a full 32bit environment. Since Powerbasic already has a 32 bit compiler for Windows Console mode (and is busy working on a Linux version) is there any chance of some kind of unified 32 bit compiler, cabable of running programs in any of these three environents? Or would it be a feasible project to write a DOS extender which could emulate the framework in which a basic console mode program would run in? Obviously TCP/IP etc would not be available.


------------------
The PC Guru, Austin Tx
Working on data recovery tools.

[Walt Decker]

Well, CHAIN, SHELL, and a TSR all have their uses; however, they are very limited in their scope and utility. Back in the days of 8 and 16KB memory machines, some BASIC versions had a MERGE function that would allow the programmer to and (and delete) code to the already running program (similar to overlays). This kept the size of the running program to a minimum. HiTech BASIC (for PCs) and Rocky Mountain BASIC (for HP workstations) have a facility to load and delete subs (both compiled and uncompiled), here again, keeping the running program to a minimum. PDS has the overlay facility. One of the nice thing about these add/delete facilities is that one can build a huge application using one interface and at the same time have each encapsulated and reusable for other applications. Another is that these add/delete facilities make it easy to start small and add to the application without making the runnining kernal application larger. Why have a spreadsheet, wordprocessor, date book, calculator, and data base in memory at the same time? From a menu, why have to shell to or chain to a spreadsheet when it could simply be loaded as an overlay and then shell or chain to a data base when it could be loaded as an overlay? Overlays or some other method to add and delete parts of code make sense and they also reduce "bloatware", one of Mr. Zales key selling points.

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

[Michael Mattias]

DOS extenders and overlay-linkage-editors are fine, sure; but good and careful design can make CHAIN'ed applications every bit as flexible and powerful as these tools.

What I see happen most often (and not just in the PC world: I see a lot more of it in the IBM mainframe world) is that you start with one little application. The users love it.. EXCEPT.. "could you please add this one little thing...?"

You add it. They love it. EXCEPT.....you add..they love..

LOOP UNTIL Out-of-Resources-with-cirrent-design.

If only applications designers would recognize that the application has not yet been written where the user says, "that's everything I could ever want" - and MEANS it.

Yes, designing for major enhancements in a resource-constrained environment is more difficult than just "getting the job done"; then again, if your program had been designed up front to allow for expansion (using CHAIN or whatever mechanism is available), then this "need" for new tools would be non-existent.

My $0.02.



------------------
Michael Mattias
Racine WI USA
[email protected]

[Mike Luther]

It would be nice, if it ever happened ..

if the source code were the same in DOS for getting
it done in WIN whatever..

Grinning, Ducking, and Running For Cover.



------------------
Mike Luther
[email protected]

[Michael Mattias]

if the source code were the same in DOS for getting
it done in WIN whatever..

Why are you ducking and running? The ability to make code "hardware and opeating system independent" is something which has been pursued with great vigor for years.

You already have "DOS BASIC" which runs the same on MS-DOS 3.1, MS-DOS 3.3....MS-DOS under Windows (hardware tricks excepted).

You have Microsoft "Visual BASIC" which is supposed to be more-or-less platform independent; you have all the 3GL languages which tend to be the same across multiple operating systems (including, of course, God's language, COBOL).

Unfortunately, I don't think anyone has it "quite" right yet; but lots of folks are going to keep trying.



------------------
Michael Mattias
Racine WI USA
[email protected]