How to make QBasic apps utilize memory above 640k ??? 3

[BobTheMad]

What is the best/easiest way to code a QBasic application to utilize memory above the conventional 640k barrier? I have a program I have written that has to perform SO many functions that it sometimes hits this barrier & crashes. I would love to just re-write the whole darn thing in VB 6.0, but unfortunately it has to run off a DOS 5.0 platform, so this is not an option.

Thanks in advance.

 

[Karl Blessing]

I dont belive you could, not unless you some how wrote a Extended memory manager in Assembly for QBasic, you cant use extended memory the way QBasic comes (unless you would rather spend months writing up peeks and pokes, or write everything to disk, then retreive at indexes what you need)

Other than that I dont know off the top of my head.
Karl
kb244@kb244.com

http://www.kb244.com

Experienced in : C++(both VC++ and Borland),VB1(dos) thru VB6, Delphi 3 pro, HTML, Visual InterDev 6(ASP(WebProgramming/Vbscript)

http://www.brainbench.com/transcript.jsp?pid=629151

 

[Alt255]

You could write the contents of unused variables and arrays to the hard drive and then deallocate the memory with the ERASE statement or REDIM the arrays to the smallest size or release the content of large strings by reducing the size to zero bytes. When the variables are needed again you could REDIM the arrays and read them from the hard drive.

All of this could end up being a bit complex for a QB app. The fact remains that most "Out of Memory" errors in QB occur when BASIC runs out of program storage space... relatively easy to solve but it might be dependent on the version.

What version are you using? I could be wrong but I think QB7 allows storage in extended memory.

Alt255@Vorpalcom.Intranets.com

"What this country needs is more free speech worth listening to."[tt]
Hansell B. Duckett[/tt]​

 

[BobTheMad]

Here is what I am using


Microsoft BASIC Compiler Version 7.10
Microsoft Segmented-Executable Linker Version 5.10

Not sure what version of the QBX.exe I am using, could not find the version number.

 

[MiggyD]

If you're using QBX then most likely it is Version 7 or 7.1.

Have you looked at the help files? HELP > CONTENTS > QBX Memory and Storage > (then) Using Extened Memory (or) Using Expanded Memory. ???

There is a notation that the system must be using HiMem.sys in order for the /ah command to be used and segments to be accessed.

-- MiggyD

 

[BobTheMad]

The section you refer to is for gaining extra memory when running at design time. The options are not available when compiled.

 

[Alt255]

Ooof! Well, it was a thought. I have QB7 but I have always stuck to QB45.

You can write some rather large applications with QB but you have to watch your PzNqz.

Break up the large modules into smaller modules (you really don't want to see any BAS files larger than about 40kb in size). Watch the way you are sharing variables across modules (check your COMMON statements to make sure each module actually needs to use a variable). Wherever you can, keep your variables local to a procedure. Use the $DYNAMIC metacommand. Eliminate any imtermediate variables (when possible). Use ERASE and REDIM with judicious prejudice (I heard that in a Steven Segal movie), that is to say "Wipe 'em out when you're through with 'em."

It's a real pain but it's worth it.

BTW, are you receiving an error that says "Out of Memory"? That doesn't come from hitting the 640kb ceiling.

Alt255@Vorpalcom.Intranets.com

"What this country needs is more free speech worth listening to."[tt]
Hansell B. Duckett[/tt]​

 

[BobTheMad]

The most common thing that occurs is that the system either will crash to DOS (with no error message), or will simply lock up, and require a cold-boot to restart. I get the occasional 'Out of string space" error, but that is another issue that I am working to resolve.

 

[BobTheMad]

Just as a side-note, the application has been broken down into 8 .bas files with sizes of:

173,637
69,786
75,684
124,743
55,745
110,324
102,511
140,137

... as you can see it is a HUGE applcation Thought for the day: Beware of Gods who cannot laugh...

 

[Karl Blessing]

well then dont try to load every module at once. and not try to load every variable as global all at once.
Karl
kb244@kb244.com

http://www.kb244.com

Experienced in : C++(both VC++ and Borland),VB1(dos) thru VB6, Delphi 3 pro, HTML, Visual InterDev 6(ASP(WebProgramming/Vbscript)

http://www.brainbench.com/transcript.jsp?pid=629151

 

[Alt255]

Hmmm... I think I see part of your problem....

One other thing to check: open each module and do a File/Save As. Make sure the option to save as "Text - Readable by Other Programs" is checked. It only takes one large module saved as "QuickBasic - Fast Load and Save" to corrupt your string space and blow QB right out of the water.

Yes, it can dump you to the command prompt without even telling you what the error was. I never understood why MS even included this option. I guess it came from a time when even a few kilobytes of disk space were a valuable commodity.

Alt255@Vorpalcom.Intranets.com

"What this country needs is more free speech worth listening to."[tt]
Hansell B. Duckett[/tt]​

 

[BobTheMad]

First, in response to Alt255's suggestion... all the modules are set as "Text - Readable by other applications". I am confident that the reason I am getting the "out of String Space" error, is that I have too many string-constants declared. I am working on reducing this.

Second, in response to kb244's post. All the modules have to he complied together in order to have all functionality available. I have also been VERY careful to have all variables declared locally, and to keep the static variables to a minimum...

I am beginning to think that a complete re-write may be necessary if I cannot find a way to utilize memory past the 640k conventional limit. This would be a HUGE undertaking, but I am confidant that I could make it MUCH more efficient than the original author(s) did. The only problem is that it would literally take weeks, if not months, to complete.
Thought for the day: Beware of Gods who cannot laugh...

 

[MiggyD]

To BobTheMad:

Have you considered CHAINing the modules? Kind of like the way DLLs work (at least now-a-days or so I'm told). They are called upon when needed.

So if each module can be a self-contained unit (prog) then you can consider using the chain command and pass the variable(s) to the next module (don't forget to use COMMON stmt.) and then re-insert the new values into the main module. I had writen a large program once, 5 seperate BAS files and ended up using the CHAIN command for them.

One was password verification & Main Menu;
second was file maintenance;
third was for various reports;
fourth was for data entry;
fifth was activity log & for encrypting and storing deleted record incase a record was deleted by accident (I don't know if accident is the word I should use here..more like speedy fingers w/o brains..I would think).


To Alt255:

I, too, have QB 7 but prefer 4.5, glad to see I'm not alone on this.

--MiggyD

 

[Guest_imported]

Could I suggest maybe using a RAMdrive and filing each array in a random access file might save memory. Different arrays could be given different filenames, and access and retrieval should be very fast.

 

[Guest_imported]

To PeaBea:

That IS the problem here. If you acivate a RAM drive then you'll be reducing more of the conventional memory so that DOS 5 can locate the actual location of the RAM drive after it passes gate 20. But, on that note...

BobTheMad...have you checked to see if the config and autoexec files are activating ONLY NECESSARY programs? and FILES/BUFFERS are set to a minimum required?

You may want to look into that.

-MiggyD

 

[Guest_imported]

To Miggy Df:

I'm obviously missing the point you were making. I have only recently started using the net and just found this forum, so I am at a disadvantage in probably having missed earlier correspondence.

My point was really further to Alt255 (Jan 4 & 9), who suggested filing strings and variables to hard disk. Using DOS 6.22 and QB 4.0 my finished programs are always compiled as Exe files. All of these apps used multiple arrays, and to avoid the dreaded 'out-of-memory' I split them into separate, smaller, programs linked with the 'Run' statement. Variables and arrays needed by the next program are filed and picked up by the new program. Fortunately, I haven't had a crash yet because of an oversize program and variables (fingers crossed).

My problem has always been getting arrays large enough to cater for a growing database. Faced in one app with a lot of records in a 6-field array, I decided to group them, 250 at a time, and file them. No problem reading them because successive files could be read into the 250dim array, but to sort them meant shelling out to a commercial sort prog which joined then all together before sorting. Back in QB, the resulting long file was read in 250 at a time and split up into separate files again. It would have been nicer to have kept within QB!

Now I've tried to use one of those apps on a machine using the AMD Athlone 600 and Window 98 DOS within that environment and it crashes when I try to 'shell'! Which makes this discussion particularly interesting to me.

What I was suggesting was that for speed of access these files could be held in RAMdisk as one long random access file. It should be possible to sort them there just as if they were arrays (I have yet to try it).

I don't see a RAMdisk as reducing conventional memory. Under DOS 6.22 I use QEMM as memory manager(far better utilisation than Microsoft's) and as an experiment I have just made a 2Meg RAMdisk in extended memory and optimized it. Dos's MEM now tells me that only 6k of conventional memory have been used and that the largest executable program size is 624K.

Anyone know how to make a Ramdisk from within Windows? The Windows 'Help' file is strangely silent.

 

[Guest_imported]

To Miggy Df

Addendum: Sorry - slip of the finger! available prog size should have read 634K

 

[MiggyD]

To Peabea:

I agree, a RAM drive is an excellent choice for speed. Unfortunately, BobTheMad, didn't indicate that he was using a memory manager. So I threw caution to the wind. In that respect, he had no memory manager optimizing the system (which is DOS 5 not 6.22).

What do you mean you try to "shell"? You mean File>DOS Shell? or SHELL "RunMyProgy.exe "? You should post it in a seperate posting.

--Miggyd

 

[Guest_imported]

To MiggyD:

Dos 5 has a memory manager. I meant 'shell' to MyProg.exe

Thought I'd try out Ramdisk as a means of storing arrays. I made a random access file with 10000 records each with 2 fields, and filled them with 4-digit random numbers using a for/next loop.

It took .1 secs to write the data to disk and .1 secs to retrieve it. All records were sorted into numerical order using a modified Qsort routine. It took 3.9 secs! Reducing the records to 1000 brought the sort time down to .28 secs, and the load and retrieve times were too fast to measure using TIMER.

I then tried filing to hard disk instead of Ramdisk. Surprise, surprise! There was no change in the times! I assume they were being sorted in write cache. This is available using SMARTdrive.

I have now modified the program which was causing me problems and it is successful. The screen barely flickers when it changes program to do the sorting.

If BobTheMad's problems are because of array sizes then I hope this may be of help.

 

[MiggyD]

to Peabea:

What I meant by DOS 5 is that in BobTheMad's post--he mentions DOS 5 but you stated 6.22, that's all I wanted to clarify.

I'm glad that you were able to make your program work. If you really want to make a comparison as far as speed from RAM to hardware, shut off SmartDrive. You're correct that the writeback feature is a very determining factor, but there may be other members in other countries or business(es) that are not necessiarily uptodate or have the latest technologies readily available.

Just out of curiousity, did you use RUN "MyProg.exe" in the initial program that caused a problem? Or did you stick with SHELL "MyProg.exe" ?

--MiggyD