🚀 go-pugleaf

In article <9211052103.AA07580@horton.jhuapl.edu> randy@horton.jhuapl.edu (Randall L. Schrickel NDM) writes:

>[QBX memory woes]

>I'm now spending all of my time trying to figure out this problem instead of
>writing and debugging new code!

Welcome to the big leagues. Until you've reached the point where most of
your time is spent trading off memory limits, you're not a REAL Quick 
Basic programmer.

Reread all of the manual discussions on QBX and BC memory handling 
at least fourteen times. Get all of the KnowledgeBase additions and
errata to the PDS manual (GEnie, CIS, or is there an FTP option?).
Then experiment wildly. Above all, remember that _any_ variable
length string array DIM/REDIM uses something like eight bytes per
array element in DGROUP. The only way to get out of this is dynamic
fixed length string arrays, which means that you lose most of BASIC's
string-handling advantages.

Finally, know that there are lots of odd, undocumented requirements
for QBX to run. I found that memory problems got tractable only 
after I went with a single QBX module. I then wrote a utility 
program to break up that muthuh-module into lots (28 at last count)
of modules for BC compilation and RTLINK overlaying.

If anybody is interested in that utility, please e-mail me. It saved
a programmer who was crying the blues on GEnie.
 
If your program is going to get 
big (> 20K lines, say), PDS may not be the system to use. 

I haven't ported my application over to QBDOS yet--it may be better.
At least string literals aren't in DGROUP.

In article <61805@mimsy.umd.edu> biow@cs.umd.edu (chris biow) screws up:

>I haven't ported my application over to QBDOS yet--it may be better.
                                         ^^^^^
Uh, make that VBDOS...

>At least string literals aren't in DGROUP.

Also, I should add that MicroHelp's QUIRKS.TXT file is a good 
compilation of Microsoft Basics' problems.

In <9211052103.AA07580@horton.jhuapl.edu> randy@horton.jhuapl.edu (Randall L. Schrickel NDM) writes:

>The application I'm working on is rather large (16,000 lines) and is getting
>rather difficult to handle under QBX. Specifically, running out of memory.
>The program itself seems to run fine, it's only when I exit the program and
>return to QBX that I get "out of memory" errors. I have looked at the docs and
>Winer's book to death. I print out all the fre numbers (-1, -2, -3, "foo", 
>and foo$) plus STACK before and after each array DIM, but haven't learned 
>anything from that. Actually, I learned that most of the numbers DON'T change -
>which doesn't seem right. Changing some string arrays from fixed length to 
>dynamic (which I expected to free up some DGROUP) only made things worse (it
>then died with "out of memory" during the execution, when it tried to dim one
>of the string arrays). I'm running on a machine with 8 Mb, qemm, dos 5, and I
>use the /ea switch when starting QBX (no huge arrays). Other people I've talked
>to say it must be DGROUP, but my fre() experiments have not shown this to be 
>necessarily true. Any other suggestions? Does VB/DOS handle memory any better?
>I'm now spending all of my time trying to figure out this problem instead of
>writing and debugging new code!

>much thanks - randy@aplcomm.jhuapl.edu

try using the /ah (arrays high) and /nof (nofrills) switches at the command
line.  Also put "rem $static" (it might be "rem $dynamic"  I can never remember
which one).  That should let you use more memory.

/Nof - takes away some of the fun stuff like help out of QBX...that way there
	is more memory for code/data
/ah - puts arrays into the far heap.  rem $static (like before, it may be
	rem $dynamic.  Gimme a break..its been awhile :) will make the data
	space be allocated at compile time, not at run time.

Hope this helps.
Its not ALL that quirky....
Brian Wheeler
-- 
******************************************************************************
* Brian 'Nautical' Wheeler - These are my opinions, do you hear me?  MINE!
* "Wombats are our friends" - Me
******************************************************************************

bdwheele@silver.ucs.indiana.edu (Brian Wheeler) writes:

[...]

>/ah - puts arrays into the far heap.  rem $static (like before, it may be
>	rem $dynamic.  Gimme a break..its been awhile :) will make the data
>	space be allocated at compile time, not at run time.

[...]

REM $DYNAMIC causes data space to be allocated at RUN TIME.
REM $STATIC causes data space to be allocated at COMPILE TIME.

In article <da.721294303@coombs> da@coombs.anu.edu.au (Daniel Austin) writes:
>bdwheele@silver.ucs.indiana.edu (Brian Wheeler) writes:
>
>[...]
>
>>/ah - puts arrays into the far heap.  rem $static (like before, it may be
>>	rem $dynamic.  Gimme a break..its been awhile :) will make the data
>>	space be allocated at compile time, not at run time.
>
>[...]
>
>REM $DYNAMIC causes data space to be allocated at RUN TIME.
>REM $STATIC causes data space to be allocated at COMPILE TIME.
>

One other note:  Arrays are ALWAYS dynamic in the QBX environment,
regardless of the REM $STATIC or REM $DYNAMIC statements.  As the
name implies, these statements are compiler directives.  QBX will
completely ignore them.

Also, if anything, /Ah will make your executable larger, and leave you
with less memory than before.  This is because additional instructions
are required to implement huge pointer arithmetic (which is what /Ah
does - it allows huge arrays).

Phil Cooper