Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

multi-tasking

Status
Not open for further replies.

qbasicking

Programmer
Aug 19, 2001
628
US
I know that I am pouring gasoling on a dormant flame w/ this post, but...

I want to make Qbasic multi-task. I was so close w/ my old program GIOS, but I ran out of room (160K) b4 I had a chance to finish it. I just want to build something simple like Windows 2.0. Not an OS, just the GUI.
I want to run small programs w/o ever unloading the main one, and be able to switch between them.
Does anybody have any tricks?

keep these things in mind when you respond

*I am assembler illiterate
*I think using SHELL is cheating
*CHAIN won't let you pick up where you left off in a
program.
 
Chain won't let you go back, but you could pass parameters back and forth that would allow you to jump to the correct place. So in actuality you could use the results of one program to define what processes next. Slow, but if you were to have a ramdisk as the parameter passing location it shouldn't be unreasonable.
This doesn't allow for your desire to keep part of the program resident.
Probably would keep the programs on the ramdisk also. Or maybe on a second one. Ed Fair
efair@atlnet.com

Any advice I give is my best judgement based on my interpretation of the facts you supply.

Help increase my knowledge by providing some feedback, good or bad, on any advice I have given.

 
thanx edfair, but I deffinatly want the main program to be running at all times. And for the input to go through it first

To anybody (maybe someone who build Windows) Windows 2.0 is a .exe running off of DOS 3.3. Win.exe is running the whole time and all input goes through it first (It also goes through the MS-DOS Executive). How did Microsoft do that? More-so 2.0 is only 200K. I wouldn't think it would be so complicated.

*If you're not familiar with 2.0 the MS-DOS Executive is like the Program Manager of 3.1
*Somebody has got to have some tricks up there sleeve;
Homer Simpson- you tried this, what've you got?
 
Of all the literature I've read over the years, I believe that Windows was mostly written in C. I remember when VB for Windows (ver 1 and 2) came out. One of the selling points is that you can create windows in Windows without having to learn a whole bunch of C nor C++ commands.

Thats probably why it's so small.

--MiggyD It's better to have two heads to solve a problem from different angles than to have tunnel vision to a dead end.
 
o - well, i guess i should learn C++. I would eventually like to make an os in it, but...
I'm still looking for tips on multi-tasking. Remember CHAIN doesn't work - i need to be able to carry over my subs (mousedriver, fontloader, master-command control, ect.)
 
qbasicking,
What's wrong with duplicating your subs in other programs? You surely don't need ALL the subs from your main prog in them.

With a bit of pre-planning you should be able to split your full program into a number of smaller programs and dump a file to carry various parameters between them.

My latest full program is over 400K split between 6 smaller programs and you cannot tell that it's not one continuous program. I use 'Run' not 'chain'.
 
actually I do use all my subs almost the whole time. My subs include a mousedriver, a font driver, a timing function, >10 menus, an icon monitor, and a system monitor, all of which are called in every DO-LOOP, WHILE-WEND or FOR-NEXT ect.
Another problem is that the subs are so big and complicated the actually prgram is only 20-25K

*I have CHAINed together the loader and my program, this cut the program down by 5K -- thanx
 
Just a suggestion (if you intend on using subs quite often):

Create a library of the most often used ones.

Again, only a suggestion.

--MiggyD It's better to have two heads to solve a problem from different angles than to have tunnel vision to a dead end.
 
to Miggyd:
What do you mean create a library?
I don't understand your post.
 
If you have SUBs that will be utilized several times throughout your program, it would be easier to have them in a library...chop your program into several seperate modules...and load the library(ies) so that you have instant access to those routines while coding and for debuging (not to mention compiling).

As long as it's well thought out libraries can provide constancy in code, faster debuging execution, and a "sort of" piracy deterant if one is extream (you know...start a windows program and, BAM!..."Error xx: You are missing file 123WinSuks.dll"...well it's the same idea with QB libraries -- you can't run something that's only a peice of a whole.)

This works with QB 4.5 and above--these versions allow library intergration. I don't recall which version of QB you have, but if you need to run your mouse drivers with a line similar to this: QB /L QB.QBL then you should be able to construct your own libraries.

--MiggyD It's better to have two heads to solve a problem from different angles than to have tunnel vision to a dead end.
 
thats why i didn't understand your post - i have qb 1.1
I will probably get 4.5 soon so I will be able to do that - thanx
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top