Too big to compile?

[ACRRHODES]

I have a 90-something Kb program (incomplete, too) that refuses to compile avec Q-Basic 4.5. I forget what error message it gives me - I'll add that when I find out - but I'm wondering if there is a size limit on compiling files. ***
Dammit Jim, I'm a programmer, not a doctor.

 

[qbasicking]

Yes, it appears to me that the limit is sixty - some kilobytes, I don't know why, but I had the same problem

 

[logiclrd]

The QuickBASIC compiler allocates a single segment for each module's code, of which about 45,000 bytes can actually be used to store the machine code. Depending on how the code is written, the .BAS file may be larger or smaller, but once it is used up, it cannot generate any more and would not be able to generate a valid executable for your code, so it aborts. However, you can have multiple modules in the same program. Look for the 'Create File...', 'Load File...' and 'Unload File...' items in the File menu. If they are not there, make sure 'Options'->'Full Menus' is set.

When the program is compiled, BC.EXE will be invoked separately for each .BAS file, and then LINK.EXE, which usually takes a single .OBJ and links it against the standard compile library BCOM45.LIB, will instead take all of the .OBJ files and link them against each other as well as the compile library.

Sharing data between modules is accomplished through the keywords COMMON and COMMON SHARED. Personally, though, I have experienced problems with these, and prefer to pass the required data in as parameters to the SUB or FUNCTION. If you have many calls to a SUB or FUNCTION which would need a whole whack more parameters if it had to pull in all the SHARED variables it used, you can write a "proxy" to it. First, move the SUB to the other module, and then rename it to 'ProxiedMySub' (if, for example, it is called MySub), and augment it with the parameters needed to bring in the variables. Then, in your main module, make a SUB by the original name of the SUB that takes the original parameters, and have it call the ProxiedMySub with those parameters as well as all the shared variables that it needs. I have used this method successfully.

Ultimately, however, very large projects end up becoming very difficult to accommodate in conventional memory; for porjects that get this large, it is better to use a language such as C in a 32-bit environment. However, this switch is not to be taken lightly, as you will usually need to use a completely different programming approach

 

[Guest_imported]

if your program is too big to compile, then don't use Qbasic to do it. There's a smaller compiler called BCOM. Infact, I believe that the Qbasic text editor calls upon the program to compile it. I'm sure this will free up enough to compile your program.

horrorclown@yahoo.com

 

[logiclrd]

QBASIC itself can only deal with a single file and does not output compiled code in any form. Internally, it does compile each line when you move the cursor off of it, which allows it to execute the lines more quickly in the interpreter (but it's still horrifically slow).

QuickBASIC uses the same approach but much more efficiently implemented for running the code in the IDE (the "interpreter&quot, but is packaged with an executable called BC.EXE which takes a .BAS file and outputs a standard Microsoft Linker Object (.OBJ file). Then, the standard Microsoft Linker from the time can take a collection of these objects and hook them all up -- "link" them -- into an executable that can run on its own. This approach is very standard and is used by nearly all compiled languages today.

If QuickBASIC claims to be having difficulty compiling the application, it is in reality not QB.EXE or QBX.EXE that is having trouble, but BC.EXE itself. These multi-module projects break up the source code into multiple .BAS files. Then, BC.EXE is run separately for each .BAS files and produces a separate .OBJ file for each one. This splitting allows you to reduce the size of the .BAS files, and allows for multiple segments of code. This is how massive QuickBASIC programs that have several hundred kilobyte executables are created (largest I have seen is about 450 kilobytes).