QBASIC ASM LIBRARIE


QBASIC( intrepreter)

INTREPRETER and RUNTIME-COMPILER

First confusion to deal with: I will only cover the QB intrepreter that comes for free with older versions of DOS, is on the CD of win95, and can be obtained on the microsoft pages in a package called olddos.exe for everyone else. So let us start with a link for this olddos.exe package

Also, to definitively get this compiler-thing-question to pieces, here is the link for the most QB-compatible shareware compiler on the net( called 1stbasic and a product of POWERBASIC)

QBASIC is not a compiler. QBASIC compiles at runtime your *.bas programs, and does this each time you run a program. It is possible to write a *.com file for this intrepreter though. For an example you can look at the file edit.com which you could also start with the command qbasic\edcom and which does not execute properly when no QBASIC is available. However, ....
It is not simple to do this, you have to spawn QBASIC as a child process from your *.com file, which is not the easiest thing to do and the program still needs qbasic on disk.. Furthermore, when you can do that, you know of course already a dozen or more ways to write a standalone program with the same functionality in PB, or assembler. So in practice QBASIC is never used as creator of *.com programs, certainly not with the shareware compilers around.

INCLUDING SUBS/ FUNCTIONS OF OTHER MODULES

A rather serious problem with QB intrepreter that I will no longer support has to do with the impossibility to include functions from other modules in a program which you are building. Say you have developed functions for bitmanipulation and stored them together in one file, and you are developing say a program for direct screen read/write. It is possible that you discovered then that you need to read two bits of the PCinfo to determine where the screensegment is located. Now you have to first go the long way of manually copying the function from your bitoperation file to your projectfile, before you can go on. Though this might not seem lots of work, I can assure you that when lots of functions are concerned this becomes highly irritating. In fact this seems to be the reason you seldom looks at QBASIC librarys.

In compilers like QB4.5 and PB the situation described is overcome in two ways:

  1. You can open subs/functions of other modules when writing a program.
  2. You can $include functions of other modules, after which you can call them.

For this reason I made xs2inc.zip, a program which pops up all available functions in the directory you specify, and let you include them in the basfile. In addition this package contains a program which you can use to automate the inclusion of subs/ functions of other modules. With this two includer programs we have an easy interface for including subs and functions. While including them is becoming simple, developing librarie functions and subs for QBasic is getting really useful. New questions arise. For instance you might start to wonder what the properties of librariefunctions and subs are. In my limited experience some things can be advisable:

  1. Use one directory for all your libraryfiles because you can then easily include them.
  2. Store your librarys in a textfile because that way you can overcome the 64K.
  3. Make choices in developing functions so that only the most useful ones survives.
  4. Document your functions so that we can follow the choices made
In my view useful functions are midlevel. They are not so obvious that we can easily write them each time necessary. On the other hand they are not so difficult that the goal and function can not be understood in short time.Also they are frequently used functions. I for myself do not put something in a lib when I do not frequently have used the function in one of my programs

I will include a few libraries I made of which certainly the stringlib has been very useful for me. The files will be updated quit regularly for a while so you have to check every once in a while. Included are the following areas: stringfunctions, assembler functions, directory functions, bitoperation functions, directwrite functions, getPc_tables functions, and more..

USING INLINE ASSEMBLY

Another feature of QBASIC is that it is very suited for people who are just starting to learn the real basics of programming, being assembly language. Before you can use an assembler like VALARROW with its overhead, QBASIC gives the opportunity to write some real programs in assembler.
From the higher language point of view assembly is often used to speed up things, or to get some functionality that is otherwise unreachable. You can think of accessing more then one page in screen 13, or getting the path of the currently executed program, or read/write absolute disksectors when functionality is concerned, and you should think of direct screen write/ direct keyboard read/ when optimalization is concerned. I think it is important to know that there is still another more important reason to use assembly in HLLs, which is fully acknowledged on my valarrow pages. Assembly gives you direct control and therefore a lot of times you might just feel good, or, like I dare to say, know that it is good, to use assembly because that way it is more elegant, more clear what you are doing. Futil as this might seem, for me it has opened lots of roads of programming which I thought before where to difficult or to artificial. In this catagory should you place a redirectable findfirst/findnext which I developed, because I wanted a dir in a string/ file, and did not felt satisfied with the shell/skipp three lines/ etc approach. Also a direct writeNattributes sub felt in this catagory, as did a function which I have written to spawn a child process from within QBASIC( which can be used in stead of shelling ).

For this and various other reasons did the compilers like PB and QB 4.5 has made various ways of using assembly in their basic. Again I will be so free to sum up:

  1. Most of the times you can directly use an assembler created obj. file as a sub in your basic program.
  2. Apart from that you could insert opcodes, or mnemonics after some sort of keyword being it inline or asm. The compiler will translate this for you.
  3. Still other ways are designed, were you can fill in registers and an interruptnumber before calling something like CALL INTERRUPTor INT86 or whatever.

So there are at least three ways to do the same things in most compilers. At the risk of being rude I call this overdetermination another proof of indecision. In fact one method would suffice. The way things are overdone here are another pointer to the importance of assembly even in HLLs, so i take it that you will be motivated to learn something about assembly by know.

Next you will not look at me writing something of a ASM2QBASIC introduction here, mainly because there exist at least two very good ones. One is the book of P.NORTON : "Machine language for the IBM PC ", and the other one is a linked online asm_tutorial. The last one covers also the use of assembly in PB in detail! Okay, as I said earlier at this first stages of learing assembly QBASIC is very useful. At least I thought we could make it very useful, in combination with a program called debug.exe which is also part of dos/windows95. Since the aforementioned tutorial/book as well as the debug part of this pages both extensively review DEBUG I skip it here ( by the way in the asm snippits collection is an excellent debug-tutorial in directory txt).

What I thought would be most useful is to make some debug interface for QBASIC. That is why there has been developed an assembly editor for QBASIC, which is something like an assembler in that it makes it possible for you to use assembler mnemonics and comments which it translates into a QBASIC valid assembly function. In addition this package contains a program which you can use to automate the use of assembly mnemonics inside your QBASIC programs.

PARSING THE COMMANDLINE:

It will not be difficult to find some sources on the net for some QB language which have some statement like parse$=command$ in their programs. When you try to run them in QBASIC you will be discouraged in two ways. First of all the intrepreter will give you some message that this feature is not supported...and second when you want to use a string with the same name the intrepreter will not allow that too. The first is of course the more problematic here. The only thing QBASIC will allow you to do is to run some program before the IDE is started. But what if you do not want to start the IDE at all ? Then there does not seem to be a solution. Also when you want to start a program using some parameters with it that will be very difficult since you can not specify anything but a filename after "/run". Since of course a commandline parsing should be possible i made some quick solution to this situations. It is a shell program which you should use in stead of starting QBASIC directly. This little program takes in either nothing( starting up the IDE), or a programname( run a program without getting into the IDE at any moment), or a programname with parameters( run a program with parameters without getting into the IDE at any moment). The only thing you have to do is to specify '#qbcommand$ in this exact syntax somewhere( prefarably directly after declare statements) in your program. You are allowed to refer to this string everywhere in your program since QBASIC will treat qbcommand$ in a statement like for instance PRINT qbcommand$ as an empty string.
This xs2com program will give you the functionality that is common with standalone programs using command$. However, the way i am working through the QBASIC IDE is far from ideal, i am not using an exec function for executing qbasic, i did not store the commandline at PSP:&H80 enz,enz. The little program at hand is only useful for purely functional and testing exercises. It is now possible to pass different parameters to your QBASIC program, a feature modern programming can not do without. Say for instance you have a program which can give some information about disks. You might want to pass directly the drive you want the information about, instead of going to the ide, and putting in some LINE INPUT. In fact the diskinfo.bas program included in Lpctables.bas will do exactly that. Typing after the doscommand "QBSHELL DISKINFO.BAS A "will return some information about your current A drive...
A second warning is necessary however..do not use this shell for chaining between different files. For that purpose you should use the commands like CHAIN and COMMON. In fact it is possible to write a shell for QBASIC using CHAIN and COMMON. That way you only have to start the SHELL file in the IDE, from where you can RUN another program while passing the desired commandline as COMMON SHARED variable..

LIBRARIES\ LIBRARIEFILES:

DISCUSSIONS:

In this section you can have a look at *.txt files which you can also run in QBASIC. Hell, when given the time i might even translate the non executable parts of it to HTML. When you are running the file in QBASIC often SLEEP commands are delimiting some commented sections of the discussion.
They will often take even the absolute beginner by the hand and discuss some topic up to the level where some more complicated programming can occur. In fact often i will try to develop some rudimentair program discussing the topic...... This section and the librarie sections are interdependent in that without the appropriate discussion you are stuck again with some MORE routines, and with only discussion you might lack the appropriate functions for future developments of your own. This discussions should also lead the novice to the level where he "needs" the libraries!

DIR_LISTERS_discussion :
Will discuss Dos' DIR with xdir,ddir,bdir10 and various sources from ABC( directory DOS). Choices will be made and accordingly an QBASIC REDIR function developed.
DIR_discussion :
Will discuss the other directory functions including the ones described in QBASIC help like CHDIR, RMDIR and MKDIR. Program designs and functions will be developed.
Filehandling_discussion
Will discuss and develop various methods for filehandling which will try to combine the flexibility of DOS filehandling with the easyness of QBASIC filehandling.
SCAN_discussion:
Will discuss programs which scan for a string on disk ( for instance PCmags search.bas). A program will be developed.
TEXT_mode_discussion
Will discuss and develop various methods for handling textmode like directwrite, scrolling( not only horizontal) and buffering. Offsetting at a very newbie level this discussion ends with the development of a high quality texteditor, without losing itself in any unnecessary difficulties.
PC_tables discussion:
Will discuss availability of the PC_TABLES like PSP, FAT, MCB, ENVIRONMENTBLOCK for QBASIC and the usefullness of the info in those tables.
HANDLERS discussion:
Will discuss the possibility and usefullness of interrupt_handlers in QBASIC. Various usefull functions will be developed in the process.
INTERRUPT discussion:
Will discuss the CALL INTERRUPT/INT86/CALL ABSOLUTE way of calling interrupts in BASICs. Included will be the way registers are set/read [shared regtype or regs function]. Choices will be made and accordingly a QBASIC int86 function will be developed. The sources from ABC attempting to do the same will be considered
MEMORY_discussion:
Will discuss all available memories and there big usefullnesses for QBASIC. Extra dataspace and a pcopy routine will be developed, among other things.
ASM discussion:
Will discuss the original integer/data way of creating assembler subroutines with MarkKims string way of doing the same. A possibility of using assembler procedures/variables within the subroutines will be included.
QBASIC_inside_discussion :
Will discuss some known features off QBASIC like its datasegment, the intrepreterarea, what interrupt QBASIC sets/unsets, how the program QBASIC is structured itself (unassemble source).


The parts called DISCUSSION and LIBRARIES will be the working area of this QBASIC page so do not be surprised if somefile is changed or another one uploaded. Also, still not every promised thing is there yet, but given time, they will be......
LINKS

On a lot of QBASICpages you can find tons of links to other pages. There are two major reasons this quantity is not equal to the quality. First the links itself are often barely documented....Often just a oneliner is describing the page. No attempt is made to describe further the contents of pages whatsoever. When you are looking for some tutorial, book_description, utility, or program i don't think such a huge list will help you. The second problem is even making things worse: when you are arrived at a randomly choosen QBPAGE there is often a list of downloadable products, with, again bare documentation. When you are looking for some program in some arrea of programming, say the MOUSE handling, i do not think those pages will be of great help. A lot of times there is no attempt to describe a package, its magnitude, its system(language) requirements, etc..In that case it would be no wonder if you first downloaded the other five MOUSEprograms before you got the right one(...). I could not count anymore the times i downloaded a file which i believed would unpack to a *.bas file and in fact consisted of *.exe files/or libfiles.

It might be clear by now that you would not find tons of links on this page. I am introducing another system here. It is thematic in its design. You can search topics, programs, and i will add a lot of documentation surrounding a link to that program/topic. I will not, in general, link pages, but links to programs on a page. Of course i could not document all of this, when i do not use that programs myself. So that is the garanty you got here. Not quantity but quality counts. To get a preview of the minimal requirements for links i for once link to a page here: the ABC homepage , and the links there are reasonably well documented. When you are symphatic to the idea , and you have reasonably well document some links, or can do that, i will be delighted if you mail them to me. The task is already huge....enough..

ABCDEFGHIKLMNOPQRSTUVWXYZ

LATEST CHANGES

15 december 1996

31 december 1996

5 januari 1997:
  • Get some lies out of the ASM discussion and added some important informations asm_discussion,corrected some answers and added a new way to pass longs, integers, strings to call absolute procedures
  • Added a first draft of memory_discussion.
  • Added a few functions in process to nuseall.zip
10 januari 1997:
The QBASIC part of this pages will shortly be halted in favor of the VALARROW part. When there is still attention given to the QBASIC part this will be heavily directed toward the cosmetics of the page, as well as to working through of existing programs, libraries, discussions. I could use some help in documenting links in an descriptive way too..........
.
MAIL_ME
I am open for reactions, suggestions as to how to move on, and for a smaller part for contributions. Contributions in the sector of libraries will be encouraged though!

When you want to react by e-mail : touchwind@geocities.com




Next - Next 5 - Random - E-Mail - Join?

1