Compiler memory problem

[markar]

I'm hoping someone can help me with my compile problem. I've got a fairly large program that QB just won't compile. It fails with the error "BC: Out of memory" when I try to compile it. It works in the QBX environment but won't compile. If I delete a few executable lines from the program, it will compile.

I'm using QB 7.1. Running in the DOS window under WinXP Pro. I've tried it using both the old and new DOS windows (COMMAND.COM and CMD.EXE). I've compiled from within QBX and from the command line.

I've broken the program up into multiple modules and verified in the MAP file that none of the code segments is close to 64K. It really seems related to how much DOS memory I have available. On some machines with less DOS memory, I can't compile the last version that worked on my machine.

I am interested in what the limit is that I am running into so I can figure out how to edit my program to minimize memory usage. I have not seen anything documented except for the 64K limit. I can post the MAP file if that will help. When you look at the output from the BC compiler, it always says something like
44660 Bytes Available
25642 Bytes Free

When it fails it says 0 Bytes Free. But when it just barely succeeds it also says 0 Bytes free. I suspect there is some 64K limit inside the compiler and the available number is the space it has left to work with once it loads. But what uses up this space and how do I minimize my usage?

And before you suggest it, I would love to port to FB, but I can't because we have a collection of business-essential programs that use ISAM, the database library included in QB Professional 7.1. As far as I can determine, no one has ever ported that library. We might be the only people in the world still using it.

Thanks for any suggestions you might have,

Mark

[Antoni Gual]

First of all I would ask about ISAM in the FB forums, perhaps someone may know of an ISAM lib for 32 bits C. A tool for automatic translation of the headers to FB exists.
If you must stay with PDS:
Have you tried to compile from the command line? This way you avoid the overhead of the IDE, pretty large in PDS 7.1.
Something like this (I'm a QB4.5 user and I use command line compiling there everyday, but I'm not sure about PDS, check the documentation)

Code:

bcx module1.bas  /o /s,,;
...
bcx modulen.bas /o /s,,;

link module1.obj  ... modulen.obj,,,bcom45.lib isamlibname.lib;

You compile every module separately and link all them all with the ISAM lib at the end.
If the program is really too large to be linked in a single piece, PDS allows you to use overlays, where the modules are stored in a separate file at runtime and are automatically loaded into slots in the .exe file when needed. I can't help you there, as I have never used this feature.

[markar]

Maybe I wasn't clear. I normally compile from the command line, although I've tried it both ways. I don't normally use QBX for anything except debugging.

The failure is in the compile of the module. If I can get it to compile, the link with the other modules will work just fine. No overlays required.

The last time I hit this problem, I tried pulling a bunch of routines out to a separate module, but it made hardly any difference. I ended up solving it by trimming out some hardly-used functionality and unused variables. So it's not the pure size of the module. Maybe it has something to do with the complexity or depth of nesting.

Once I deal with this issue, I may check the FB boards for help with ISAM. Unfortunately, ISAM is not a library - it is actually a TSR you need to run before running any QB program that uses the database functionality. Fortunately it can be loaded into high memory. So actually I guess I would be looking for help translating the old ISAM calls into MySql calls or somesuch.

[Moneo]

Hi Mark, from a fellow New Yorker (Manhattan),

Sounds like you painted yourself into a corner with ISAM.

Anyway, I'd like to help streamline your program so it will compile, if I can. Send me a .TXT version, not a .BAS, to my email address:
moneo@prodigy.net.mx

Regards.
*****

[Atrapado]

you can begin reading in the MSKB, here and here.

[Atrapado]

When you look at the output from the BC compiler, it always says something like
44660 Bytes Available
25642 Bytes Free

Explanation of Compiler "Bytes Available" and "Bytes Free"

[markar]

you can begin reading in the MSKB, here and here.

The first article describes a compiler out of memory bug when doing certain calculations on a user type passed to a SUB. This looked promising, since I do this all the time in my module, but the changes I made that pushed the module from compiling to failing didn't actually touch any element of the user type. But it is definitely something to keep in mind.

The second article describes a bug using the SWAP command on a array elements immediately after an arithmetical operation. This doesn't apply to my program.

The Explanation of "Bytes Available" article is more helpful, but not quite detailed enough. It confirms that the compiler has a 64K internal workspace, and that it uses it for the symbol table, the line number table, and for working storage. This explains why I was able to work around this problem earlier by re-using variables (ugh). I don't have any line numbers, so that's no help. And there is no real description of how to minimize the compiler's use of working storage.

The only suggestion they offer is to break chunks of functionality off into other object modules. I have been doing this and have reached the limit without doing more major changes than I wanted to do right now. Interestingly, the last time I hit this problem, I pulled out about 500 lines of subroutines to a new object file. This did not reduce the memory usage enough and I still could not compile. This is when I ended up reusing variables. So the working storage usage seems not to be directly related to lines of code, but maybe to complexity.

This program is one that I inherited and I still haven't pulled out all the global variables. This is what makes it tricky to pull out any of the remaining routines. It is also tough to debug, because I do most of my work on a remote machine in our offices in LA. Unfortunately, this program uses graphics on screen 12, which is incompatible with Remote Desktop Connection. My home machine has about 10K less memory available in the DOS box due to some drivers, and because of that (I think) QBX will not even load the program. It crashes as soon as I try to open the file.

None of these problems are insurmountable, they just make it more difficult to make major changes to this program.

To sum up - it sounds like my best bet is to try and pull out more functionality into other modules. And to reduce the number of variable names in the module to reduce the size of the symbol table.

Mark

[markar]

By the way, how did you find these articles? I can't come up with any combination of search terms in the KB that will show them.

you can begin reading in the MSKB, here and here.

[RyanKelly]

If you are using any third party include files, try coding a replacement with only the symbols you use in your module.

[markar]

That's actually a pretty good idea. The only 3rd party include I use is mouse.bi, which doesn't have much in it, but I do use 6 of my own include files, and I could probably trim them down to the declares and variables I actually use.

However, unless each declare statement takes up 100 bytes of workspace, it probably won't be enough to make much of a difference. I'll do some experiments.

If you are using any third party include files, try coding a replacement with only the symbols you use in your module.