Announcement

Collapse
No announcement yet.

Overlays

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Michael Mattias
    replied
    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]

    Leave a comment:


  • Mike Luther
    replied
    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]

    Leave a comment:


  • Michael Mattias
    replied
    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]

    Leave a comment:


  • Walt Decker
    replied
    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.

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

    Leave a comment:


  • Guest's Avatar
    Guest replied
    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.

    Leave a comment:


  • Lance Edmonds
    replied
    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>

    Leave a comment:


  • Mike Luther
    replied
    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]

    Leave a comment:


  • Walt Decker
    replied
    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.

    Leave a comment:


  • Guest's Avatar
    Guest replied
    How 'bout the Shell statement?

    Leave a comment:


  • Matthew Berg
    replied
    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.

    Leave a comment:


  • Walt Decker
    replied
    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.

    Leave a comment:


  • Lance Edmonds
    replied
    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>

    Leave a comment:


  • Matthew Berg
    replied
    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.

    Leave a comment:


  • Michael Mattias
    replied
    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]

    Leave a comment:


  • Walt Decker
    replied
    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.

    Leave a comment:


  • Lance Edmonds
    replied
    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>

    Leave a comment:


  • Walt Decker
    started a topic Overlays

    Overlays

    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?
Working...
X