Run vs. Chain

If you have questions about any aspect of QBasic programming, or would like to help fellow programmers solve their problems, check out this board!

Moderators: Pete, Mods

Post Reply

Run vs. Chain

Post by Zhaedow » Fri Jul 30, 2004 4:00 am

So I'm working on an RPG that is reminiscent of Ultima III or IV. I started it about 4 or 5 years ago and then just stopped... Anyway, I'm getting back to it and have forgotten a LOT (most of my non-anotated code was gibberish a couple days ago). At any rate, I'm wondering if it would be better to use RUN or CHAIN when linking modules? Any feedback would be good. Thanks.

User avatar
Posts: 79
Joined: Tue Jul 27, 2004 11:44 pm
Location: Alone and forgotten


Post by Levi » Fri Jul 30, 2004 11:00 pm

I found this at a website: ... ingQB.html

It explains the difference and possibilities. I'd suggest using the Chain command cause it will allow you to send information. However modules and qbasic files are slightly different if I understand them right. Though they are the same thing to use Run or Chain forces a program to run in place of your current program. So unless each module was only for like a subroutine to work and send back information I'd suggest looking into how qb4.5 or qb 7.1 does module inclusion. Of course I don't understand the purpose of using modules in this particular sense if you have scripting files that are suppose to take over the game or to split the game into sections. I'm not sure, of course even if you did have it to simply keep the game from getting cluttered I don't think that Chain or Run work with Exes unless you run the exe itself. Like ti won't interrpret Qbasic commands for you just because you say Run or Chain. Of course if you plan on simply giving the source code it won't matter.

Well good luck, and welcome back to QB.

Here's the tutorial.
Running QBasic files is really quite easy, and there are two ways of doing it, Run and Chain. We'll start off with Run. This has very few options, and the code is as follows:
run "c:\your\file\name\filename.bas"

If you don't specify the .bas extension then QBasic assumes it to be .bas. That was the easiest way to run QBasic files. Now for the hard part, a way to send variables along to those programs you're supposedly running. To do that, you use a Chain command. However, that isn't enough. You have to specify which variables to send along with the Chain command, by using a 'common shared' statement. Here's an example:

common shared yourvariable$ 'you can use any type of variable you want
chain "c:\your\file\name\filename.bas"

To send more than one variable, put a comma between each variable in the 'common shared' statement. I'm not entirely sure this works, because I don't use these commands much. The reason is, if you put these in your program, you can't compile it to an EXE
Later days,

May those who love us love us
And those who don't
May the good Lord turn their hearts
And if he doesn't
May he turn their ankles
So we'll know them by their limping
-Irish prayer


Thanks Levi

Post by Zhaedow » Mon Aug 02, 2004 12:11 pm

While I don't recall my original purpose for having multiple compliled modules your information helped quite a bit. Run does not allow variable sharing while chain does. So, chain it is. Thanks so much for your help.

User avatar
Posts: 826
Joined: Sun Jul 25, 2004 4:24 am
Location: Quebradillas, PR

Post by Nodtveidt » Tue Aug 03, 2004 10:00 am

While developing The Wrath Of Sona, I realized that I would have to split my engine into two seperate EXEs in order to make the game fit into 640k. Of course, sharing variables between them was the difficult part on the surface. But an idea hit me...Windows uses virtual memory, so why can't I? So...I did. :D

Here's how you can do it:
*Right before you load your next program, store all the variables you need in a temporary file. I always use a file called VIRTUAL.MEM but you can use anything.
*When your next program loads, have it look for your temporary file. If it exists, open it, read the variables, and delete the temporary file.

Use the technique as much as necessary to share variables between infinite numbers of programs, provided you keep your variable structure stable.

If you are simply running out of memory in single-module programs, consider using multiple modules in the same project, and using COMMON SHARED/DIM SHARED.

Post Reply