Copy Link
Add to Bookmark
Report
QBNews Volume 3 Number 1
Volume 3, Number 1 March 29, 1992
**************************************************
* *
* QBNews *
* *
* International QuickBASIC Electronic *
* Newsleter *
* *
* Dedicated to promoting QuickBASIC around *
* the world *
* *
**************************************************
The QBNews is an electronic newsletter published by Clearware
Computing. It can be freely distributed providing NO CHARGE is charged
for distribution. The QBNews is copyrighted in full by Clearware
Computing. The authors hold the copyright to their individual
articles. All program code appearing in QBNews is released into the
public domain. You may do what you wish with the code except
copyright it. QBNews must be distributed whole and unmodified.
You can write The QBNews at:
The QBNews
P.O. Box 507
Sandy Hook, CT 06482
Copyright (c) 1992 by Clearware Computing.
The QBNews Page i
Volume 3, Number 1 March 29, 1992
----------------------------------------------------------------------
T A B L E O F C O N T E N T S
1. From the Editor's Desk
BASIC Alternatives by David Cleary ........................... 1
Receiving The QBNews ......................................... 3
Submitting Articles to The QBNews ............................ 3
2. The News Desk
Goings On in the World of BASIC
Crescent Software Expands BBS Service ...................... 5
Microsoft Expands Technical Support on Compuserve .......... 5
Microhelp Announces Network Library ........................ 6
EllTech Announces Printer Plus ............................. 6
Microsoft Announces the Visual Basic Professional Toolkit .. 6
Desaware Announces CCF-Cursors for Visual Basic ............ 7
Index Manager Now Available for Visual Basic and PowerBASIC. 7
3. Microsoft BASIC PDS 7.1
Converting ASM String Functions to BASIC 7.X by Jay Munro .... 9
Using Stub Files to Reduce EXE Size by David Cleary .......... 13
Using Overlays in Microsoft BASIC PDS 7.1 .................... 20
4. The QBNews Professional Library
Thanks for the Memories by Robin Duffy ....................... 23
5. QBASIC Corner
Extending the QBasic Interpreter by Brent Ashley ............. 28
6. Swap Shop - QB Source Code Exchange
Creating Vertical Menus by Bernard Veerman ................... 35
Windowing in BASIC by Mark Butler ............................ 38
Viewing Files in BASIC by Matt Hart .......................... 38
7. Algorithms
QuickInsert Sort Algorithm -a push from B$ASSN by Larry Stone 39
8. Fun and Games
Having A Ball - Solution to 12 Ball Problem .................. 43
9. The QBNews Volume 2 Annual Index .............................. 45
The QBNews Page ii
Volume 3, Number 1 March 29, 1992
----------------------------------------------------------------------
F r o m t h e E d i t o r ' s D e s k
----------------------------------------------------------------------
BASIC Alternatives by David Cleary
It seems to be in vogue today to bash Microsoft. This is undoubtably
because they have become the predominant software company in most
areas of computing. BASIC programmers biggest complaint is the fact
that QuickBASIC 4.5 has not been updated for some four years. They say
that Microsoft is insensitive to their customers needs. However, since
QuickBASIC 4.5, Microsoft has released BASIC PDS 7.1 and Visual Basic
1.0. Microsoft is the only major compiler vendor with a BASIC compiler
and has proven their commitment to BASIC in my eyes. Although PDS 7.1
addresses many of the features request for QuickBASIC, the fact that
it is a professional compiler and is priced like one leaves this out
as an option.
However, all is not lost. Even though you won't be able to find a
Borland or Watcom BASIC, there are a number of smaller software
companies that do provide BASIC compilers. If you feel Microsoft is
unresponsive to your needs, has lousy tech support, or has abandoned
the DOS market, then do yourself a favor and check out one of these
BASIC alternatives.
ZBASIC-PC/386
==============
32 Bit Software 800-322-4879 $149.95
BB Progression/3
=================
Basis International 800-423-1394 $199.95
Thoroughbred BASIC
===================
Concept Omega Corp 800-524-0430 $600 - $900
Workstation BASIC
==================
Emphasys Software 800-972-2742 $695
GFA BASIC for MS-DOS
=====================
GFA Software Technologies 800-766-6432 $235
387 BASIC
==========
Microway 508-746-7341 $250
NKR BASIC
==========
NKR Research 408-249-2612 $295
The QBNews Page 1
Volume 3, Number 1 March 29, 1992
Power BASIC
============
Spectra Publishing 800-245-6717 $129
True BASIC
===========
True BASIC 800-872-2742 $99.95
In future issues of The QBNews, I hope to have in depth reviews of
some of these products. In the mean time, give these companies a call
and ask for some product literature. You may find a product you like
much better than QuickBASIC.
The QBNews Page 2
Volume 3, Number 1 March 29, 1992
Receiving The QBNews
The QBNews is distributed mainly through BBS systems around the
world. Some of the networks it gets distributed through are SDS
(Software Distribution System) and PDN (Programmers Distribution
Network). Ask the sysop of your local board about these networks to
see if there is a node in your area.
The QBNews can also be found on CompuServe in the MSLang
(Microsoft Language) forum. It can be found in file area 1 or 2 of
that forum. Just search for the keyword QBNEWS. The QBNews will also
be available on PC-Link. I send them to Steve Craver, who is the BASIC
Programming Forum Host on PC-LINK and he will make them available. I
would appreciate anybody who could upload The QBNews to other services
such as GENIE since I don't have access to these.
I have also set up a high speed distribution network for people
who would like to download The QBNews at 9600 baud. The following
boards allow first time callers download privileges also. They are:
Name Sysop Location Number Node #
---------------------------------------------------------------------
Treasure Island Don Dawson Danbury, CT 203-791-8532 1:141/730
Gulf Coast BBS Jim Brewer New PortRichey,FL 904-563-2547 1:365/12
221B Baker St. James Young Panama City,FL 904-871-6536 1:3608/1
EMC/80 Jim Harre St. Louis, MO 314-843-0001 1:100/555
Apple Capitol BBS Bob Finley Wenatchee, WA 509-663-3618 1:344/61
RadioLink! Steve Craver Columbus, OH 614-766-2162 1:226/140
MedTechNet Bill Hliwa Buffalo, NY 716-688-1552 1:260/10
Finally, you can download The QBNews from these vendors BBS's:
The Crescent Software Support BBS 203-426-5958
The EllTech Support BBS 404-928-7111
The Microhelp BUG BBS 404-552-0567
404-594-9625
You do not have to be a customer of these vendors in order to download
The QBNews, but the Microhelp BBS only allows non-members 15 minutes
of time per call.
If you would like to receive The QBNews on disk, I offer a yearly
subscription for $20.00. This includes four disks containing each
The QBNews Page 3
Volume 3, Number 1 March 29, 1992
issue as it is published. If you would like a disk with all the back
issues of The QBNews, please enclose an additional $5.00. The pricing
structure is as follows:
Base Price for 1 Year - $20.00
Disk with Back Issues - $5.00
3.5" disk surcharge - $5.00
Canada and Mexico surcharge - $5.00
All other foreign orders - $10.00
The base price includes 5.25" 360k disks. Send a check or money
order in U.S. funds to:
The QBNews
P.O. Box 507
Sandy Hook, CT 06482
Please be sure to specify what archive format you want. The
QBNews normally uses PKZip as it's archiver.
----------------------------------------------------------------------
Submitting Articles to The QBNews
The QBNews relies on it's readers to submit articles. If you are
interested in submitting an article, please send a disk of Ascii text
of no more than 70 characters per line to:
The QBNews
P.O. Box 507
Sandy Hook, CT 06482
Articles can also be submitted via E-Mail. Send them via Compuserve to
76510,1725 or via FidoNet to 1:141/777. I can be reached at the above
addresses as well as on Prodigy as HSRW18A.
The QBNews Page 4
Volume 3, Number 1 March 29, 1992
----------------------------------------------------------------------
T h e N e w s D e s k
----------------------------------------------------------------------
Goings On in the World of BASIC
CRESCENT SOFTWARE EXPANDS BBS SERVICE
======================================
Crescent Software has expanded the Crescent Software Support BBS.
Crescent Software customers can now subscribe for enhanced technical
support through their BBS. Subscribers can download the latest
versions of all the Crescent Software products they own, plus receive
the kind of technical support that isn't possible over the phone such
as help modifying routines. The service costs $59 per year. You can
call Crescent Software at 800-35-BASIC, or 203-438-5300. All
QuickBASIC users are encouraged to call The Crescent Software Support
BBS at 203-426-5958 - 14.4K v.32bis.
MICROSOFT EXPANDS TECHNICAL SUPPORT ON COMPUSERVE
==================================================
Microsoft has reorganized all their tech support for software
developers under a new forum. The new forum is called Microsoft
Developers Services (GO MSDS).
Specifically, the Microsoft Developer Services area offers:
- Developer Forums. This set of forums covers information on Windows,
languages, tools, and utilities from a developers perspective. You can
use these forums to exchange messages with experienced Microsoft users
and Microsoft Developer Support engineers.
- Developer Knowledge Base. This up-to-date reference tool contains
technical information about Microsoft developer specific products
compiled by Microsoft Product Support. The Knowledge Base is full-text
searchable, and in addition to technical articles contains special
information regarding product bug lists, fix lists, documentation
errors, and Microsoft press releases.
- Software Library. A collection of binary files, sample code,
technical specification and utilities. The entire library is
keyword-searchable, and the files can be downloaded for use locally.
- Suggestion/Problem Report Form. This form can be used to make
product suggestions or to report a problem with a Microsoft product.
- Microsoft Service Requests. Microsoft now offers an optional,
private (fee-based per incident) technical support offering to help
solve your more complex development problems.
Robert Eineigl, Microsoft Support Engineer (CIS ID 76701,156) explains
what this means to BASIC programmers - "The restructuring will
The QBNews Page 5
Volume 3, Number 1 March 29, 1992
positively impact QB users in at least two ways: The concentration of
resources on the Knowledge Base will mean faster updates and one-stop
browsing for all developer-related issues. And finally Basic
developers/programmers, by being included with the more "stylish"
development languages, will garner more respect and attention to their
efforts. This move should be seen as MS's becoming more aware of and
committed to the importance of CIS as a support delivery medium."
MICROHELP ANNOUNCES NETWORK LIBRARY
====================================
Microhelp is now shipping the Microhelp Network Library, with versions
for both QuickBASIC/PDS 7.1 and Visual Basic. The Network Library is
designed to provide an easy to use wrapper for the network interface
routines. The library supports Novell, LANtastic, and NetBIOS
networks. The Microhelp Network Library costs $89 per version, or $169
for both the QB/VB library and one set of documentation. You can call
Microhelp at 800-922-3383 or 404-594-1185 for more information or to
order this product.
ELLTECH ANNOUNCES PRINTER PLUS
===============================
EllTech is now shipping the new Printer Plus library. Printer Plus
allows BASIC programmers to support over 400 printers without changing
a single line of source code. Printer Plus's features include:
- Over 50 text printing functions that allow you to control exactly
how your printed reports will look regardless of the printer used.
- Utilize advanced features found in modern printers while not
precluding the use of printers without those features.
- Utilities are provided that allow you to add new printer
descriptions to our database or edit existing descriptions.
Printer Plus has a list price of $249, but if you order before April
30, 1992, you can get it for $199. You can call EllTech at
800-553-1327 or 404-928-8960.
MICROSOFT ANNOUNCES THE VISUAL BASIC PROFESSIONAL TOOLKIT
==========================================================
"The Professional Toolkit for Visual Basic makes incredibly powerful
functionality and the latest and greatest Windows operating system
features accessible to programmers at all levels," said Michael Risse,
product manager, Professional Toolkit for Visual Basic, at Microsoft.
"The unique custom control mechanism in Visual Basic makes these
features as accessible as the click of a mouse."
Combining the Professional Toolkit with Visual Basic provides a
The QBNews Page 6
Volume 3, Number 1 March 29, 1992
single-source solution for a broad range of full-featured
Windows-based applications. Professional programmers can use it to
enhance existing applications created with Visual Basic as well as to
create new ones.
The new features include controls to enhance applications with the
following technologies:
- Object linking and embedding technology (OLE). Microsoft's OLE
technology lets developers easily create applications that can combine
spreadsheet, word processing, graphics and other OLE server
functionality into an application that's customized for specific
business uses.
- Pen-based computing. Programmers can extend their current
applications -- or write entirely new ones -- for Microsoft Windows
for Pen Computing.
- Multimedia. Developers now can easily write or enhance applications
for Microsoft Multimedia Extensions version 1.0, including video,
animation, CD-quality audio and other multimedia elements.
- Graphing. Pie and bar charts in 2-D or 3-D, in addition to nine
other charting styles, can now be added to applications easily with a
complete graphics package in the Professional Toolkit.
- Grids. Information can be presented in a table complete with
resizeable rows, columns and scroll bars. This makes the display of
tabular data a snap for programmers.
- Multiple Document Interfaces (MDI). The MDI control allows the
developer working with Visual Basic to create applications with
multiple child windows that are contained in a single parent form.
In addition, the Professional Toolkit gives programmers easy access to
the following tools and features:
- More than 15 new controls, including 3-D interface components;
animated buttons, gauges and spin buttons; and access to commonly used
dialog boxes.]
- The Windows Help Compiler, to create the custom, online Windows Help
files that users of Windows now expect in their applications.
- The Windows API Online Reference, an accessible guide to Windows
application programming interfaces (APIs) that makes it easier for
programmers to maximize their use of Windows.
- A setup kit that helps developers create standard installation
programs for their applications, plus sample applications, bitmaps and
a business clip-art library.
- Custom Control Development Kit.
The QBNews Page 7
Volume 3, Number 1 March 29, 1992
The Professional Toolkit for Visual Basic is available now for the
suggested retail price of $299. Microsoft Visual Basic with
Professional Toolkit is available for the suggested retail price of
$495. For a limited time, owners of Visual Basic can receive the
Professional Toolkit for a special price of $99.
DESAWARE ANNOUNCES CCF-CURSORS FOR VISUAL BASIC
================================================
Desaware is now shipping CCF-Cursors, a product that permits the
creation of custom cursors or mouse pointers for Visual Basic. Over 50
sample cursors and two demo programs are provided. Also, CCF-Cursors
also comes with the CCMOUSE custom control. This control supports
detection of mouse events for any Visual Basic control, including
those that do not normally detect mouse events. CCF-Cursors lists for
$35 and is available now by calling Desaware at 408-377-4770.
INDEX MANAGER NOW AVAILABLE FOR VISUAL BASIC AND POWER BASIC
=============================================================
Index Manager, the popular B+ Tree file manager for QuickBASIC has
been enhanced to support both Visual Basic and PowerBASIC. These two
new versions boast simple, one-function construction for ease of use
are written in assembler for small and fast performance. Index Manger
lists for $99 for the single user version and $250 for the network
version. Call CDP Consultants at 800-876-0098 for more information or
to place an order.
The QBNews Page 8
Volume 3, Number 1 March 29, 1992
----------------------------------------------------------------------
M i c r o s o f t B A S I C P D S 7 . 1
----------------------------------------------------------------------
Converting ASM String Functions to BASIC 7.X by Jay Munro
Life was easy when QuickBASIC only had one kind of variable length
string and it was always in DGroup. QuickBASIC used Near Strings with
descriptors in a simple format--two bytes as the length, and two bytes
as the offset into the String Segment, or DGroup. That all changed
with BASIC 7.x PDS.
While the Near String format still lives on with BASIC 7.x as a
compiler option, the QBX environment requires your assembler functions
to use Far Strings. The Far Strings data is located in segments other
than DGroup, with several to choose from. The Main module strings and
string arrays have one 64k segment, procedure level simple strings and
temporary strings share another 64k segment, and Common strings are in
yet a third 64k segment. That's a lot of space, but it does
complicate working with strings.
To begin with, the string and array descriptors for all strings are
kept in DGroup, regardless of where the data is stored. This is
important to keep in mind when working with Far Strings, since it is
still possible to run out of DGroup before you run out of Far String
space. Having the descriptors in DGroup let you pass the string to an
assembler routine as a Near Pointer, just as in earlier versions of
QuickBASIC.
The real differences between Near and Far Strings become apparent once
inside the assembler routine. To get the length of a Near String, the
first two bytes of the descriptor are the length. With Far Strings,
the pointer (or address) to the descriptor is pushed and the
StringLength function is called. Stringlength returns the length of
the string in AX. In our Trim routine, we move AX into CX for use in
the loop later.
For a Near String descriptor, the second two bytes of the descriptor
point to the string data that is stored in DGroup. To get the address
of Far String Data, the desciptor is again pushed and the
StringAddress function is called. The StringAddress function returns
the address of the string as a Far Pointer in DX:AX. An interesting
undocumented side effect of StringAddress is that CX contains the
length when it returns, along with the address in DX:AX. Microsoft
will not confirm this, and cautions against depending on undocumented
features because they are subject to change, but it does work in both
BASIC 7.0 and 7.1. You can decide for yourself if you want to drop
StringLength.
When StringAddress and StringLength are called, SS, BP, DS, SI, and DI
registers are preserved, but ES is not. You can see when running a
program under Codeview that ES returns with the segment of the far
string after the StringAddress call. Normally this is harmless, but
when your routine is juggling several incoming strings, ES may be
The QBNews Page 9
Volume 3, Number 1 March 29, 1992
pointing to another segment. The trashing of ES may go unnoticed when
all strings the routine is processing are in the same segment.
However, if the strings are from different segments, like Common and
Procedure level strings it becomes apparent.
The Far string descriptor format also applies to variable length
string arrays. To access strings in an array, the VarPtr of the first
element of the string is passed as shown in the following code
snippet, and the pointer is incremented by 4 to get each successive
string. The function AddEll adds up the lengths of the strings in the
array$().
'--- BASIC code
Declare Function AddEll&(Byval Address%,Byval NumEls%)
Dim Array$(1 to 200)
.... (fill array)....
TotalSize& = AddEll&(VARPTR (Array$(1),200)
;---- assembler code
.Model Medium,BASIC
Extrn StringLength:Proc
.code
AddEll Proc Uses SI DI, Array:Ptr, NumEls:Word
Xor DI,DI ;use DI to track total lengths
Mov CX,NumEls ;get numels (byval remember)
Jcxz Exit ;jump out if 0 els
Mov SI,Array ;get pointer to first descriptor
CountLoop:
Push CX ;preserve CX through count loop
Push SI ;push pointer
Call StringLength ;get length
Add DI,AX ;add length to counter
Pop CX
Add SI,4 ;point to next 4 byte descriptor
Loop CountLoop ;keep going til' done
Exit:
Xor DX,DX ;clear DX to return long
Mov AX,DI ;and return total count in AX
Ret
AddEll EndP
End
For QB45 or Near Strings, the code can be much more compact, and
thereby faster.
;near String version
AddEll Proc, Array:Ptr, NumEls:Word
Xor AX,AX ;use AX to track total lengths
Mov CX,NumEls ;get numels (byval remember)
Jcxz Exit ;jump out if 0 els
Mov BX,Array ;get pointer to first descriptor
The QBNews Page 10
Volume 3, Number 1 March 29, 1992
CountLoop:
Add AX,[BX] ;first word of is length
Add BX,4 ;point to next 4 byte descriptor
Loop CountLoop ;keep going til' done
Exit:
Xor DX,DX ;clear DX to return long
Ret
AddEll EndP
End
Now that we've discussed retrieving Far String information, let's move
on to our last subject--Far String Functions.
STRING FUNCTIONS
Far String Functions are only a little more complex than their Near
String counterparts. In a Near String function, the four byte
descriptor (LENGTH:ADDRESS) is created in DGroup, as is the data that
the address points to. With Far Strings, the four byte descriptor
must still be in DGroup, but the data can be in any segment. Unlike
Near String descriptors which are created by the programmer, the four
byte descriptor is created by calling BASIC's StringAssign function.
StringAssign is called with the Length, Segment and Address of the
data you want to assign, and the Length, Segment and address of the
destination. The StringAssign function can assign both variable
length and fixed length strings. With fixed length strings,
StringAssign uses the length parameter on the destination. When
assigning a variable length string, the destination length is set to
zero so StringAssign knows to create a descriptor and store the date.
The accompanying program, ZeroTrim illustrates the technique.
There are two caveats to be aware of when using Far Strings and
StringAssign. First, when StringAssign is called with the address of
the descriptor (or destination), it checks to see if the descriptor
contains a value or not. If it sees a value, StringAssign assumes it
is an old descriptor and will try to deallocate the string to make
room for the new string. On the first entry into your assembler
function, the descriptor should be null so a new descriptor is
allocated. However, if your function clears the descriptor between
calls, BASIC will end up with orphan data from old strings not being
deallocated. On the other side, if your program does a CLEAR command
after a call to a string function, variables on the BASIC side will be
cleared, but the descriptor stored in your assemblers Data area will
still exist. If the assembler routine then calls StringAssign, BASIC
will try to deallocate the data and you'll end up with a String Space
Corrupt message. The rule is don't call Clear once the program
starts, and don't clear the descriptor between calls.
If your program needs to free up the space, you may call the
StringRelease function to deallocate the descriptor. This is only
recommended if the function is not going to be called again, since
StringAssign will always release the old string before assigning a new
The QBNews Page 11
Volume 3, Number 1 March 29, 1992
one. The syntax for StringRelease is as follows.
.Data
Descriptor DD ?
.Code
Some Proc ....
..
..
Push DS
Push Offset Descriptor
Call StringRelease
Another problem programmers may encounter with Far Strings happens
when the assigning a zero length string. Under Near Strings, the
length portion of the descriptor just zeroed out and BASIC understood.
Far Strings are not quite so simple, but the concept is similar.
Though there are several ways to do it, the most reliable is to be to
point to an actual data area and tell StringAssign that the length is
zero. StringAssign will then deallocate the old descriptor if there is
one, and allocate a new one that BASIC recognizes as a zero length
string. Again, it is important to let BASIC go through the motions so
it deallocates the old strings.
As you can see, the conversion of assembler routines from Near Strings
to Far Strings is not too difficult. By using the Far String function
and watching your registers, the transition is almost painless. Once
a routine is converted to handle Far Strings, it may be used with
either BC 7.x compiler option. The Far String functions are
automatically replaced with near string code when you leave off the
/FS switch, eliminating the need for two version of the routines for
BASIC 7 support. If you need to support QuickBASIC 4.x, you will need
a second version for near strings only.
SOURCE CODE FOR THIS ARTICLE CAN BE FOUND IN FARSTRNG.ZIP
======================================================================
Jay Munro is a programmer at Crescent Software and also writes
utilities for PC Magazine in his spare time. He was given the task of
converting Crescent's QuickPak Pro to use Farstrings, and more
recently, converting QuickPak Pro for use in Visual Basic. Jay can be
contacted through The Crescent Software Support BBS at 203-426-5958,
or in care of this newsletter.
======================================================================
The QBNews Page 12
Volume 3, Number 1 March 29, 1992
Using Stub Files to Reduce EXE Size by David Cleary
Microsoft BASIC Professional Development System version 7.1 comes with
many "stub" files to help reduce the size of your EXE programs. By
linking with these stub files under certain conditions, you will see
reductions in EXE size of 2 - 15K. However, improperly using stub
files may result in your EXE actually getting larger.
Because of the complexity of the BASIC run time libraries, many times
routines will be included in your EXE even though they are never used.
For instance, when you do this:
OPEN A$ FOR RANDOM AS #1
the compiler doesn't know if A$ is referring to a file, or to the
communications port. Therefore, the compiler has no choice but to
include all the code to handle the communications port. What a stub
file does, in this instance NOCOM.OBJ, is replace the code that is not
needed with an empty procedure. This causes all external references
to be resolved and cause a decrease in EXE size.
The tricky part is figuring out when to use them. For instance, if you
changed A$ in the example above to:
OPEN "C:\INFO.DAT" FOR RANDOM AS #1
the compiler knows you want to open a file. It will not include the
communications routines in your EXE file. If you try and link with
NOCOM.OBJ, you will actually see an increase in EXE size.
There are two types of stub files provided with PDS 7.1. The first
type is used with stand alone programs (compiled with /O) are are used
to reduce the size of your EXE file. They include:
NOCGA, NOEGA, NOOGA, NOHERC, NOVGA, NOGRAPH Graphics stub files
NOCOM, NOLPT Device support stub files
SMALLERR Error message stub file
87.LIB Floating point emulation stub file
NOEMS, OVLDOS21 Overlay support stub files
NOFLTIN Floating point input support stub file
NOEDIT INPUT editting functions stub file
TSCNIO Text output stub file
NOTRNEMx.LIB Transcendental operation stub file
The second type of stub file is used when creating custom run time
libraries. They do not decrease the size of your EXE file, but rather
decrease the size of your BRUN file. They include:
NOEVENT Event trapping stub file
NOISAM ISAM support stub file
The following instructions on correctly using these stub files came
from a file located in the Microsoft Software Library on Compuserve.
You can access the Microsoft Software Library by typing GO MSDS at any
The QBNews Page 13
Volume 3, Number 1 March 29, 1992
! prompt.
When to Use the NOxxx.OBJ Graphics Stub Files
---------------------------------------------
When you code any graphics SCREEN mode, the compiler knows to generate
code that will require support only for that mode. Therefore, the
linker will only link in support for the screen mode that you are
using. If you only use SCREEN 9, the linker will only pull the EGA
graphics support out of the BASIC libraries.
The one time when all graphics support will be linked with your
program is if you use SCREEN with a variable such as the following:
SCREEN X%
In this case, the compiler does not know what graphics mode you will
be using until run time. Therefore, it is forced to generate code that
will cause ALL of the BASIC graphics support to be linked in. In this
case, you would use NOGRAPH.OBJ, or one or more of the following stub
files, to stub out support for those modes you will not be using:
NOCGA.OBJ, NOEGA.OBJ, NOOGA.OBJ, NOHERC.OBJ, NOVGA.OBJ
NOGRAPH.OBJ would only be useful if you are using SCREEN X%, where X%
is guaranteed to be zero. NOGRAPH.OBJ is only useful when building
custom run-time modules that will not support graphics. NOGRAPH is a
superset of all the other above graphics stub files and cannot be
linked with any of them.
When to Use NOCOM.OBJ or NOLPT.OBJ
----------------------------------
Normally, support for communications or printing will not be linked in
unless an OPEN "COMx:" or OPEN "LPTx:" statement exists in the
program. However, if the program contains a statement that resembles
the following
OPEN A$ FOR <mode> as #n
then the compiler must assume the A$ might be equal to "COMx:" or
"LPTx:" at some time during the program. Therefore, communications and
printing support will be linked in along with all other file support.
If A$ will never be used to open the "COMx:" port or the printer, then
the NOCOM.OBJ support module can be used to stub out support for
communications and NOLPT.OBJ can be used to stub out printer support.
This should reduce the size of the .EXE program.
When to Use SMALLERR.OBJ
------------------------
The QBNews Page 14
Volume 3, Number 1 March 29, 1992
SMALLERR substitutes smaller error message text strings for the normal
error messages and maps the BASIC error messages down to a few
messages. Use this only in a program known to be very stable.
When to Use 87.LIB
------------------
87.LIB could increase the size of the .EXE if the program does not
contain any math statements at all. However, use the 87.LIB stub file
(in the .OBJ argument list of LINK, even though it is a .LIB file) to
decrease the size of the .EXE file when the program contains a math
statement and will be run ONLY on machines with a math coprocessor.
When to Use NOEVENT.OBJ
-----------------------
The NOEVENT.OBJ stub file is useful only to reduce the size of a
customized run-time module that will not support event trapping.
NOEVENT.OBJ is NOT useful for reducing the size of your compiled BASIC
.EXE program.
If the program can be compiled without /V and /W, the program doesn't
require event trapping. In this case, mistakenly linking your BASIC
.OBJ modules directly with NOEVENT.OBJ may increase program size. If
the program requires /V or /W, you would also not want to link with
this stub file, since NOEVENT.OBJ is only useful for making customized
run-time modules.
When to Use NOEMS.OBJ
---------------------
In an overlaid program, this stub file will prevent the overlay
manager from using expanded memory (EM) even if EM is present. This
stub could be used if the program needed to use EM for other purposes
(such as ISAM) and did not want the overlay manager to use EM. This
stub file reduces code size only by about 1000 bytes. Do not use this
stub file if the program does not contain overlays or if it is an OS/2
protected mode program.
OVLDOS21.OBJ
------------
This stub file adds support for DOS version 2.10 to an overlaid
program. Any overlaid program that would want to work on DOS 2.10 must
have this file linked with it. OVLDOS21 is not needed (and should not
be used) if the program is not overlaid or if it is a protected mode
program. The stub file does not remove code, but always adds code and
functionality (about 500 bytes).
When to Use NOFLTIN.OBJ
-----------------------
Replaces the INPUT code with an "integer only" version. If you link
with this stub file, all forms of numeric input (INPUT, INPUT #, VAL,
The QBNews Page 15
Volume 3, Number 1 March 29, 1992
and READ) will have the following restrictions:
1. READ, INPUT, INPUT #, and VAL will no longer recognize leading base
specifiers on numbers. The following specifiers are illegal:
&H &O, &
2. READ, INPUT, INPUT #, and VAL will no longer recognize trailing
type specifiers on numbers. The following specifiers are illegal:
!, %, #, & and @
3. READ, INPUT, INPUT #, and VAL will no longer parse a number with
either a decimal point, E, or D in them. Thus, while 1E3 is a legal
BASIC integer, it will not be recognized.
4. Using a SINGLE precision, DOUBLE precision, or CURRENCY variable
with READ, INPUT, INPUT #, and VAL will cause the math support to
be linked in. The restrictions in points 1-3 above will still hold.
Also, using any other math related operation will pull in the
support pack without lifting the restrictions of 1-3.
The main size advantage to using this stub file occurs when READ,
INPUT, INPUT#, or VAL are the only statements that use the math
package. This stub file will then eliminate at least 11K of code. If
some other statement also needs the math package, the savings will be
less than 2K.
When to Use NOEDIT.OBJ
----------------------
This stub file replaces the editor used with the INPUT and LINE INPUT
statements. It removes the following functions from the editor:
1. No control character commands are recognized except for ENTER (done
editing) and BACKSPACE (removes the last character). All other
control characters are ignored, as are INS, DEL, HOME, END, and the
arrow keys. Function keys will still expand because this
functionality is performed outside the INPUT editor.
2. If output is redirected (using >) and input is not redirected (no
<), no characters will be echoed to the screen. The normal INPUT
editor will print the characters as you types them in this
situation.
3. No characters will be echoed to the line printer even if line
printer echoing is turned on.
You can obtain a 1K reduction in .EXE size using this stub file.
Linking with this file could increase program size if the program
never uses INPUT, LINE INPUT, LINE INPUT #, RANDOMIZE. If the program
does not have INPUT or LINE INPUT statements but does have LINE INPUT
The QBNews Page 16
Volume 3, Number 1 March 29, 1992
# or RANDOMIZE (with not parameters), there will still be some
savings.
When to Use the TSCNIOxx.OBJ Stub Files
---------------------------------------
Note: The statements affected by this stub file are subject to change
in future versions.
The TSCNIOxx.OBJ file provides a smaller, simpler text output package.
When it is linked in, the following differences from standard BASIC
will occur:
1. No graphics statements are supported. All the following statements
and functions will generate an illegal function call:
CIRCLE, POINT statement, POINT function, PAINT, PSET, VIEW,
VIEW SCREEN, WINDOW, PALETTE, PALETTE USING, DRAW,
PUT (graphics), LINE, PCOPY, PMAP, GET (graphics)
2. VIEW PRINT will not be supported. All programs will have an
implicit VIEW PRINT 1 TO <screen-size - 1> as is the normal
default. For programs linked with this stub file, the only way to
reach the bottom screen line is with the LOCATE statement, since
the VIEW PRINT statement is not available.
3. There will be no support for function key display. The KEY
ON/OFF/LIST statements will generate an illegal function call.
CTRL+T to an INPUT statement will be silently ignored. Softkey
definition and expansion will still be supported.
4. The COLOR statement will not accept a border parameter. Also, the
color parameters are sent directly to the hardware. Thus, on an
EGA or VGA card with a monochrome monitor, many values for COLOR
will cause text to not be visible.
5. Embedded control characters will not be supported for PRINT.
Currently, the following features (which need to be added to the
manual) are supported for the nonstubbed version of the PRINT
code:
Control
Character Description
--------- -----------
CTRL+G Beeps the speaker
The QBNews Page 17
Volume 3, Number 1 March 29, 1992
CTRL+I Moves the cursor to the next tab position, erasing
characters
CTRL+J Moves the cursor to the beginning of the next line
CTRL+K Moves the cursor to the top-left corner of the current
VIEW PRINT window
CTRL+L Clears the VIEW PRINT window, homes the cursor within
it
CTRL+M Moves the cursor to the beginning of the next line
CTRL+\ Moves the cursor to the right one space, stopping at
the end of the line
CTRL+] Moves the cursor to the left one space, stopping at
the beginning of the line
CTRL ^ Moves the cursor up one line, stopping at the top of
the VIEW PRINT window
CTRL_ Move the cursor down one line, stopping at the bottom
of the VIEW PRINT window
6. The SCREEN and WIDTH statements will not be supported. The program
will use whatever screen mode was available on start-up, unless it
is a graphics mode, in which case an attempt will be made to
determine if any text mode can be run in that graphics mode. The
screen will always be 80 columns, displaying on video page 0. The
number of lines will be determined by start-up conditions. The
screen state will not be restored when the program terminates.
7. CLS will not accept any parameters.
8. Underline cursors on an EGA card not in 25-line mode may not be
handled properly.
9. This stub file may not be used to build a customized run-time
module. It may not support the CHAIN statement.
The QBNews Page 18
Volume 3, Number 1 March 29, 1992
10. This stub file does not support CGA snow elimination during screen
output.
This "set" of stub files is dependent upon operating system and
near/far string support. Thus, there are four different versions of
the file:
File Description
---- -----------
TSCNIONR.OBJ Near string DOS version
TSCNIOFR.OBJ Far string DOS version
TSCNIONP.OBJ Near string OS/2 version
TSCNIOFP.OBJ Far string OS/2 version
Any program linked with one of these stub files should decrease in
size. The size decrease should be between 1.3K and 4.4K depending on
the statements used in the program and the library being linked with.
When to Use the NOTRNEMx.LIB Stub File
--------------------------------------
NOTRNEMR.LIB and NOTRNEMP.LIB remove support for transcendental
operations, including: SIN, COS, TAN, ATN, LOG, SQR, EXP, ^ (the
exponential operator), a CIRCLE statement with a start or stop value,
and the DRAW statement with the A or T commands.
When to Use the NOISAM.OBJ Stub File
------------------------------------
NOISAM.OBJ removes ISAM functionality from customized BASIC run-time
modules. NOISAM.OBJ is not useful when linking stand-alone (BC /O)
BASIC executable programs.
======================================================================
David Cleary is a software engineer for Vectron Laboratories in
Norwalk, CT and is also the author of Crescent Software's PDQComm. He
can be reached in care of this newsletter, on Compuserve as
76510,1725, on Prodigy as HSRW18A, on Fidonet at 1:141/777, and on the
Crescent Software Support BBS at 203-426-5958.
======================================================================
The QBNews Page 19
Volume 3, Number 1 March 29, 1992
Using Overlays in Microsoft BASIC PDS 7.1
The following information comes directly from The Microsoft Knowledge
Base. The Microsoft Kwowledge Base is a huge database of information
on all Microsoft products. Microsoft technical support uses the
Knowledge Base to help answer your questions. You can access the
Knowledge Base yourself through Compuserve. Just type GO MSDS at any !
prompt.
Title: How to Use Link Overlays in Basic PDS Versions 7.0 and 7.1
Document Number: Q51416
Publ Date: 7-OCT-1991
Product Name: Microsoft BASIC Compiler Product Version: 7.00 7.10
Operating System: MS-DOS
Summary:
When using the linker (LINK.EXE) to generate code overlays for
Microsoft Basic Professional Development System (PDS) version 7.0 or
7.1 under MS-DOS, you must put the modules you want to overlay in
parentheses on the LINK command line. The modules that make up one
overlay must be compiled with the same switches. Code is the only part
of the program that is overlaid. Data is not overlaid. Examples and
further restrictions for using linker overlays are given below. This
information applies to Microsoft Basic PDS versions 7.0 and 7.1 for
MS-DOS (but does NOT apply to earlier Basic compiler versions). Note
that link overlays are not needed and not supported under OS/2
protected mode, because OS/2 itself automatically provides a similar
feature to support swapping of very large .EXE programs in OS/2
extended and virtual memory.
More Information:
The following is an example of how to produce code overlays:
LINK test1+(test2+test3)+test4+(test5)+(test6),TEST1.EXE,TEST1.MAP;
where the following apply:
1. test1 (TEST1.OBJ) is the main module.
2. test2 and test3 (TEST2.OBJ and TEST3.OBJ) are separately compiled
modules that make up one overlay.
3. test4 (TEST4.OBJ) stays resident in memory along with the main
module (test1) at run time and is not swapped out of memory to
disk.
4. test5 and test6 (TEST5.OBJ and TEST6.OBJ) are two separate
overlays.
5. TEST1.EXE is the executable overlaid program created by this LINK.
6. TEST1.MAP is a text file (created by the above LINK) that tells
you the code sizes of all overlays and procedures.
To invoke an overlay, you call a SUB or FUNCTION in a module contained
in that overlay, and the Overlay Manager automatically moves the
overlay (if it is not already loaded) into DOS memory, overlaying any
previous overlay in memory.
You can call any module or overlay from any other module or overlay.
The QBNews Page 20
Volume 3, Number 1 March 29, 1992
Overlays provide an alternative to CHAINing when a program is too
large to fit into memory all at once. An overlaid program is made up
of a single .EXE file (which can be an advantage in some cases),
unlike CHAINed programs, which are composed of several .EXE files.
Restrictions on Using Overlays
------------------------------
The restrictions on using overlays in Microsoft Basic PDS versions
7.0 and 7.1 for MS-DOS are as follows:
1. Each Microsoft Basic overlay cannot exceed 256K in code (see LINK
.MAP for size of each overlay). You can have up to 64 overlays
per .EXE program. This means you may be able to make .EXE programs
up to 16 MB in code size under MS-DOS.
2. The main module must be the first module in the LINK command line,
and it must NOT be specified as an overlay. If you incorrectly make
the first module in the LINK command line an overlay, the machine
will hang when the program first loads.
3. When you create an overlaid version of a program, make sure that
each module contained in the program is compiled with the same
options.
4. You cannot use the LINK /PACKCODE or /EXEPACK option when linking a
program that uses overlays.
5. You cannot have a stub file as an overlay. Do not specify stub
files (NOxxx.OBJ) in the parentheses for link overlays, or the
program will hang. Stub files may only be specified outside
parentheses in the LINK command line.
Using Expanded Memory with Overlays
-----------------------------------
386Max (386MAX.SYS) from Qualitas, Inc. is an example of an expanded
memory driver that can be used with Basic PDS 7.0 and 7.1. Basic PDS
7.0 and 7.1 require an expanded memory driver that uses the
Lotus-Intel-Microsoft (LIM) version 4.0 Expanded Memory Specification
(EMS).
If you have loaded an expanded memory driver, and if all the overlays
can fit together at one time in expanded memory, and if each overlay
has less than 64K of code, then overlays are loaded from expanded
memory. Otherwise, overlays are swapped from disk, which is slower
than loading from expanded memory.
Assume that the overlaid program satisfies the above conditions for
using expanded memory. Note that the overlaid modules are not loaded
when the .EXE file is first invoked. They remain on disk until the
first overlay is called. When this occurs, all the overlaid modules
are loaded at once from disk into expanded memory. From then on, the
overlays are swapped from expanded memory into DOS memory, and the
disk is no longer used for loading overlays.
The overlay manager in Basic 7.0 and 7.1 requests expanded memory in
16K pages (blocks). The overlay manager only knows the size of the
largest overlay, and must make a "best guess" at the size of the
The QBNews Page 21
Volume 3, Number 1 March 29, 1992
smaller overlays. When the overlay manager estimates how many 16K
pages are necessary to hold all overlays at once in expanded memory,
the estimate could be over or under the actual number of pages needed.
If your overlays are all between 16K and 64K in size (according to the
LINK .MAP file), and if the estimated or actual size of all overlays
together exceeds the available expanded memory, the following
initialization error occurs when the first overlay is called at
run-time:
Insufficient EMS to load overlays
Note: This error is documented on page 656 of the "Microsoft Basic
7.0: Language Reference" manual for versions 7.0 and 7.1. You will
never see this error if all your overlays are smaller than 16K each.
If you want to force loading overlays from disk, thus avoiding the
possibility of this overlay initialization error in expanded memory,
you must link with the stub file NOEMS.OBJ (with no parentheses around
NOEMS.OBJ on the LINK command line). Alternatively, you can try
reconfiguring expanded memory so more of it is available for Basic
overlays. Another alternative is to make overlays similar in size.
DOS Memory Map When Using Overlaid .EXE Program
------------------------------------------------
[Low Memory]
- MS-DOS
- Main program and non-overlaid modules
- Contiguous overlay memory area, equal to the size of biggest
overlay
- DGROUP (default data segment, which is shared by all routines)
- Far heap (dynamic non-variable-length-string arrays)
- Basic's run-time support module if .EXE not compiled stand-alone
(BC /O)
[High Memory]
For more information on using overlays, see the following:
"Microsoft Basic 7.0: Programmer's Guide." pages 612-614.
Additional reference words: 7.00 7.10
COPYRIGHT Microsoft Corporation, 1991.
The QBNews Page 22
Volume 3, Number 1 March 29, 1992
----------------------------------------------------------------------
T h e Q B N e w s P r o f e s s i o n a l L i b r a r y
----------------------------------------------------------------------
Thanks for the Memories by Robin Duffy
For years QuickBASIC programmers have done some pretty incredible
things when it comes to using all the resources available on a PC. Of
all the things accomplished, the ability to use expanded memory was
heralded as a major accomplishment (at least I thought it was!). Now
QB programmers had oodles more of that precious commodity, RAM! Why,
several meg of RAM could now be used by programmers without thinking,
allowing them to create the most powerful of applications.
Without thinking? Well, not really. Expanded memory has its drawbacks,
one of which is the concept of bank switching blocks of this memory in
and out of the processor's addressable space. Also there was no
management of these blocks available to the programmer other than what
he could muster up for himself. He had to keep track of what data was
in what page and which pages were loaded where in the page frame.
Without some careful advanced planning it would be easy to get things
all mixed up beyond any hope of survival.
Another disadvantage I saw was the difficulty in saving a huge array
into this 64K page frame. A huge array by definition is larger than
the page frame itself. So, one would have to save the first 64K of the
array into the four available pages, swap pages, and then save another
64K chunk. I think there is a term for this sort of work around
programming - kludge! Why would you want to have all this beautiful
streamlined code in your program and then rely on a kludge?
Well, my thoughts took a different course after I tried programming
for expanded memory. I knew there was a different sort of memory
native to AT machines called extended memory. Extended memory differed
from expanded memory in several different ways, the most attractive of
which was the fact this memory was continuous for meg after meg. The
only problem with this memory was it was only available from the
processor's protected mode of operation. Now, I thought, how can I get
to this memory from a platform I am comfortable with? The answer was
obvious, but somewhat frightening!
Now enter a rather mysterious little device driver supplied with many
versions of DOS named HIMEM.SYS. HIMEM.SYS was barely documented (if
at all) as an extended memory manager, but precious little else could
be found out about it. Now here was something that could manage
extended memory for me, if only I could find out how to make this
thing work! Expanded memory has this dedicated interrupt (Int 67h)
that made interface simple, but HIMEM was written differently.
Instead of a clean system of interrupt function calls, or even
invoking a device name, HIMEM.SYS is used by calling the driver
directly as a procedure call! While direct calls to device drivers
can be done directly from QB with CALL ABSOLUTE, not every aftermarket
runtime library supported this QB keyword. Setting up the required
structures was also somewhat of a pain. The idea for an assembly
The QBNews Page 23
Volume 3, Number 1 March 29, 1992
interface to HIMEM.SYS was born!
HIMEM.SYS provides a variety of functions for managing extended
memory, the high memory area (1M + 64K) and the upper memory area
(memory between A000:0000 and 1M). It is important for user programs
NOT to issue calls for managing the high and UMB memory areas if some
other program is already managing those areas, especially DOS. The
popularity of DOS 5.0 meant I would have to be careful which functions
I chose to implement. After consideration I chose only those functions
that allocate, deallocate, move,
and report on extended memory. HIMEM
would perform a move to and from conventional memory, so I did not
require the use of the other functions.
I was pleasantly surprised when I learned HIMEM uses a handle based
system for managing blocks of memory instead of a more bulky system
such as page frames. For each block of XMS you allocate HIMEM assigns
a handle to reference the block by. This allows HIMEM to manage the
actual locations any way it pleases in a transparent manner - so if I
wanted to allocate a 1.5 meg block of XMS memory (certainly possible)
I could reference it at anytime with a single handle. Certainly an
improvement over paging! Another advantage of handles is a program
can use several blocks of XMS memory of varying sizes without regard
to the physical location of the memory or what's in it. Just use the
handle much like you would a DOS file handle and let it go at that.
There is one responsibility you as programmer must undertake when
deciding to use extended memory in your program. You must make sure to
release any XMS memory you allocate before your program ends its
execution. This memory is not managed by DOS at all, so DOS can not
automatically release XMS on program termination as it does for
conventional memory. If a program exits without releasing it, the
memory remains allocated until the next time the computer is booted!
Although the demo program I have included does not do this, you should
trap all possible means by which your program can be terminated.
Included with this text is my extended memory interface for
QuickBASIC, the XMS driver. When designing XMS I had considered using
a system of pointers to emulate a block storage device, and using it
like a disk drive. However, after some consideration I decided to
implement it similar to the manner Ethan Winer had implemented his
expanded memory interface for QuickPak Professional. The major reason
for this design decision is simulation of a block device would not
remove enough of the management required by the programmer. I think
that although somewhat limited, the XMS driver provides a good amount
of flexibilty while insulating the programmer from much of the work
involved.
Let's now take a look at the ten procedures that make up the XMS
driver for QuickBASIC. I won't get into the calling syntax here (it is
included as part of the ZIP file in XMS.DOC) but will instead provide
some comment on the operation of each. If you wish to see these
routines in action just run the small demo program included with the
driver package.
The QBNews Page 24
Volume 3, Number 1 March 29, 1992
INITXMS is the procedure to get the ball rolling. This procedure
checks for the presence of HIMEM.SYS and determines the availability
of XMS memory. This procedure returns the availability and size of any
XMS memory on the machine in two integers. The size returned is the
actual XMS available in K bytes (that is, this number times 1024 is
the actual size).
GETXMS is a function that allocates a block of XMS memory and returns
its handle. The only parameter for this function is the size of the
memory block you are requesting, in K bytes (1024 bytes is the
smallest increment in which HIMEM.SYS will allocate XMS memory). You
may specify a block of any size up to and including all available
memory! Block sizes of several meg are commonplace. If desired, you
may specify a number of different blocks for different purposes.
FREEXMS will deallocate (free up) memory that was allocated using
GETXMS. Simply call it with the handle of the block you wish to
release. See the above paragraphs for the importance of using this
call.
ARRAY2XMS is a procedure that will copy any continuous block of
conventional memory to an allocated block of XMS. This procedure will
copy the block of conventional memory into the XMS block at offset
zero into the block. One interesting use of this procedure is saving
huge arrays to XMS with one call. In fact, given enough extended
memory, you could conceivably copy the entire contents of conventional
memory to XMS! You can use this call with any far array. The only
limitation posed by this procedure is the number of bytes to move must
be an even number. Odd numbers are forced even without comment or
error.
XMS2ARRAY is the compliment routine to ARRAY2XMS. Its function is to
copy a block of memory from XMS to conventional memory. I have used
these two routines to save and restore the screen directly from XMS.
The only drawback to using this method to save and restore screens is
HIMEM.SYS knows nothing of retrace checking for CGA monitors, and may
cause some snow. Other uses include restoring huge arrays with one
call and loading code stored in XMS.
XGETELEMENT is one of those afterthought routines. If you know the
size of the array elements you have stored in an XMS block (and you
should), this procedure will allow retrieving a single element from
that block. The demo program uses this routine to display any random
element the user chooses. The procedure uses your element size and an
element number to determine where in the XMS block to start reading.
Please note this procedure assumes the first element of your stored
array is item number one, not zero. Also, your element size must be an
even number.
XSETELEMENT is the compliment procedure to XGETELEMENT and has
identical syntax. This procedure will allow the setting of any
individual element stored in XMS memory. The demo program uses this
procedure to change any chosen element to a new value of the user's
choice. These two routines can let you set up a "virtual" array in
The QBNews Page 25
Volume 3, Number 1 March 29, 1992
extended memory of any element size, up to and including all installed
XMS!
Next come three procedures that deal with error handling. These
procedures were inspired by Ethan's QuickPak Professional and really
bind the whole thing together. My personal salute to Ethan Winer for
such insightful design!
XMSERROR is a function that will return the current state of error,
but not the specific error code. This is extremely handy when you wish
to test for an error condition, but don't care what error has
occurred. Very neat code can be written for error handling as so:
.
.
CALL Array2XMS(SEG Array%(start%), XHandle%, NumBytes&)
IF XMSError% THEN
PRINT "Error transferring array to XMS"
(branch to error handling code here)
ELSE
PRINT "Array transferred"
END IF
.
.
The status of errors is updated after every call in this driver except
for INITXMS. Thus, any sucessful operation will clear the value of any
previous error.
It should be noted that if XMS memory is not available for any reason
(such as HIMEM not installed, extended memory not installed or none
available) this function will always show an error condition. This
way programming logic will not have to adapt much to the presence or
lack of XMS memory.
WHICHXERROR is a function that will return the actual code of an error
reported by XMSError. This routine would most likely be used inside an
error handling routine to determine the course of action required by
the program. If there is no outstanding error condition WhichXError
will return a zero.
WhichXError is designed so if XMS memory is not available for any
reason this function will always return a "Function not supported"
error. I thought it might cause some confusion if a call to a routine
in this driver fails because XMS is not available and the reported
error was "No Error"!
SETXERROR is a sub you can use to set the error code returned by
WhichXError. This sub will allow setting error codes in the range of 0
to 255 inclusive. I thought for completeness this procedure should be
included. I also thought about allowing this sub to work if no XMS is
installed but then decided against it. Again, some confusion could
result if you set the error code to zero when no XMS was installed.
So, if XMS is not available to the driver, this sub will have no
The QBNews Page 26
Volume 3, Number 1 March 29, 1992
effect on anything.
Well, that pretty much wraps it up. Included with the XMS package is a
sample program and source code that demomstrates use of most of the
routines in this package. One glaring error that stands out is a
CRTL-C will abort this program prematurly (it uses standard DOS I/O so
it can be interrupted easily) and lose the allocated memory until next
reboot. I did this intentionally so you could see the results of such
a programming practice. If you experiment, you'll see that when you
try to run the demo again, it will tell you there is no available XMS
memory!
These routines have been tested pretty thoroughly, but not completely.
It is after all just a prototype for something normally not possible
within a QuickBASIC program. I hope it provides you with many hours of
entertainment just pushing the driver to the limits!
I have only scratched the surface of the potential of this driver. I
am sure there are hundreds (perhaps thousands) of practical
applications for blocks of memory larger than those you can access by
any other means except straight protected mode programming. I would
be interested to learn just what feats can be accomplished using this
code as a starting point.
If you have any comments concerning the XMS driver package or would
like to ask me a question concerning it, feel free to contact
Sequental Software's support BBS at (606) 561-5766 24 hours daily.
There's no registration fee and you get full privs on the first call.
I'm usually on it every day, so your question should be answered in
about 24 hours or so. If you are more inclined to write, send your
response to:
Sequential Software Inc.
P.O. Box 53
Somerset, KY 42502-0053 USA
Make sure to put it to my attention. I will answer as soon as possible
by mail.
Have fun and good luck!
SOURCE CODE FOR THIS ARTICLE CAN BE FOUND IN XMS.ZIP
The QBNews Page 27
Volume 3, Number 1 March 29, 1992
----------------------------------------------------------------------
Q B A S I C C o r n e r
----------------------------------------------------------------------
Extending the QBasic Interpreter by Brent Ashley
With the widespread acceptance of MS-DOS 5.0, many people are
discovering and rediscovering the power of modern, structured BASIC.
This is evidenced especially in the various BBS network programming
echoes, where very often a reply is now prefaced with:
"Well, if by QBasic you mean the one that came with DOS 5.0 then
I'm afraid that can't be done; but if you mean the QuickBASIC
compiler, well then you simply..."
QBasic (the interpreter) differs from QB (the QuickBASIC compiler) in
a few ways, but mostly in its extensibility, or more to the point,
lack of it. Keen QBasic programmers soon run up against the
language's limitations, mostly as regards system-level programming.
While the obvious solution would be to buy QuickBASIC for its access
to DOS and BIOS interrupts and its easy extensibility via code
libraries, in many situations this is impractical. Perhaps your
company MIS department disallows language purchases by "common users"
(I hear bells ringing in heads all over the continent as you read
this!), or your personal budget doesn't allow for it yet. It would be
best to use a company-sanctioned tool, or one you already have, if
only it provided the functionality you needed.
One advanced feature Microsoft "left in" the QBasic interpreter is the
CALL ABSOLUTE statement. This statement allows you to call a
machine-language routine at a known place in memory, and to pass it a
list of arguments. At first glance it doesn't seem to be of much use,
but with a little imagination, you can use this feature to extend the
use of QBasic far into QB's realm.
I have written three assembly-language routines which, together with
their BASIC support routines, add the following to the QBasic arsenal:
o DOS and BIOS Interrupt calls
o Almost instant memory block copies
o Fast colour single-line box drawing
You will find these routines with ASM source, along with a demo
program containing many sample QBasic support routines, in QBASIC.ZIP.
Meanwhile, I'll explain here the methods I use to load and call binary
routines and some of the further-reaching implications. Keep in mind
that all of these routines work just as well with the QuickBASIC
compiler, as long as the CALL ABSOLUTE routine from QB.LIB is
available.
I'll try to encapsulate the essence of loading and calling a BIN file
from QBasic in a short example. This example program uses the
MEMCOPY.BIN file to quickly copy a block of memory so screen saves can
be done without PCOPY, which isn't supported by monochrome adapters.
The QBNews Page 28
Volume 3, Number 1 March 29, 1992
The source is followed by a discussion of its innards.
-------------- ASM Source ---------------------------------------
; MemCopy.ASM - by Brent Ashley
; Copies blocks of memory quickly
; - to be used primarily for screen saves.
;
.MODEL medium, BASIC
.CODE
MemCopy PROC USES si di ds es, \
FromSeg:PTR WORD, FromOfs:PTR WORD, \
ToSeg:PTR WORD, ToOfs:PTR WORD, \
Count:PTR WORD
; load ds:si with source, es:di with destination
mov bx,FromOfs
mov si,[bx]
mov bx,ToSeg
mov es,[bx]
mov bx,ToOfs
mov di,[bx]
mov bx,Count
mov cx,[bx]
; ds last (used to access data)
mov bx,FromSeg
mov ds,[bx]
; do the copy
cld
rep movsb
ret
MemCopy ENDP
END
--------------- QBasic code --------------------------------------
DEFINT A-Z
DECLARE FUNCTION LoadBin$ (BinFileName$)
CLS
FOR i = 1 TO 24 ' fill screen with letters
PRINT STRING$(80, 64 + i);
NEXT
ScrnSave 1 ' save screen
SLEEP 1 ' wait a second for user to see screen
CLS
PRINT "That screenful of letters has been erased."
PRINT : PRINT "Press a key to restore screen..."
DO: LOOP UNTIL LEN(INKEY$) ' wait for key
ScrnSave 0 ' restore screen
END
SUB ScrnSave (SaveRestore) STATIC
' save/restore a text screen
' save = nonzero, restore = 0
STATIC InitDone, ScrnBuf, VidSeg ' ensures local scope
IF NOT InitDone THEN
The QBNews Page 29
Volume 3, Number 1 March 29, 1992
REDIM ScrnBuf(1 TO 2000) ' 4000 bytes (80x25x2)
DEF SEG = 0
IF PEEK(&H463) = &HB4 THEN ' determine mon/colour
VidSeg = &HB000 ' mono
ELSE
VidSeg = &HB800 ' colour
END IF
DEF SEG
InitDone = -1
END IF
IF SaveRestore THEN ' save
BlockCopy VidSeg, 0, VARSEG(ScrnBuf(1)), VARPTR(ScrnBuf(1)), 4000
ELSE ' restore
BlockCopy VARSEG(ScrnBuf(1)), VARPTR(ScrnBuf(1)), VidSeg, 0, 4000
END IF
END SUB
SUB BlockCopy (FromSeg, FromOfs, ToSeg, ToOfs, Count)
' copy a block of memory
STATIC MemCopy$ ' ensure local scope
IF NOT LEN(MemCopy$) THEN MemCopy$ = LoadBin("MemCopy.BIN")
DEF SEG = VARSEG(MemCopy$) ' point to routine's segment
CALL Absolute(FromSeg, FromOfs, ToSeg, ToOfs, Count, SADD(MemCopy$))
END SUB
FUNCTION LoadBin$ (BinFileName$)
' Loads a binary file as a string
STATIC FileNum, Buf$
FileNum = FREEFILE
OPEN BinFileName$ FOR BINARY AS FileNum
IF LOF(FileNum) = 0 THEN ' file didn't exist
CLOSE FileNum
KILL BinFileName$
CLS : PRINT "Can't find "; BinFileName$; " - aborting."
END
END IF
Buf$ = SPACE$(LOF(FileNum)) ' size buffer
GET FileNum, , Buf$ ' load BIN routine
CLOSE #FileNum
LoadBin$ = Buf$
END FUNCTION
--------------------- end of example --------------------------------
The Assembly routine was written with Microsoft's QuickAssembler. I
used some of its advanced segment directives and high-level language
interface capabilities, but knowledgeable (read:masochistic)
programmers could generate similar .BIN files with DEBUG as long as
they were familiar with accessing stack parameters and cleaning up the
stack on return. All it does is to load DS:SI and ES:DI with the
source and destination and then copy the number of bytes specified by
Count, which is in the range 0 to 65535. The routine is assembled and
then converted to binary image with EXE2BIN. The resulting file is
called MEMCOPY.BIN.
The QBNews Page 30
Volume 3, Number 1 March 29, 1992
The QBasic code consists of a short main module which fills the
screen, saves it, erases it, and restores it, using our routine.
While only the ScrnSave procedure is called by the demo, ScrnSave
relies on BlockCopy, which in turn relies on LoadBIN$.
ScrnSave saves and restores the screen by reserving a block of memory
to use as a buffer. This allows fast screen saves on monochrome
adapters, which do not have extra video pages as do colour adapters.
The first time the routine is called, it dimensions the buffer array
and determines the adapter type and therefore the address of the
screen page. Then, and on any subsequent calls, it copies the the
screen contents between the buffer and screen memory, depending on the
value of SaveRestore.
The BlockCopy routine performs the copy requested by ScrnSave. On
first pass, it loads the ASM routine from its .BIN file on disk into
the string MemCopy$, which has been declared as STATIC. The STATIC
declaration causes it to retain its value between calls ensures it
isn't affected by any module-level variable of the same name which may
have been declared with the SHARED attribute. It then uses the CALL
ABSOLUTE statement to call the BIN routine. This is done by setting
BASIC's current DEF SEG to the routine's segment and then passing the
address of the routine to run, along with the parameters to pass. It
is interesting to note that CALL ABSOLUTE takes a variable number of
parameters, depending on the requirements of your routine. Note that
SADD is used to determine the address of the routine, since it is
stored in a string variable.
LoadBin$ is a general-purpose function to load these .BIN files from
disk into a string. It assumes the file is in the current directory
or that the path is specified in BinFileName$. The file is loaded
into a string which is then returned by the function, to be called
with CALL ABSOLUTE by your QBasic-level support routine.
Using the methods demonstrated in this example, it is possible to
extend QBasic's power as far as your assembly skills allow. It is
even possible to write support routines which would allow the creation
and use of BIN libraries. I had contemplated doing this but decided
that interest wouldn't be high enough due to the availability of the
QuickBASIC compiler, and the fact that multiple BIN files in a
"library" directory would be simple enough to implement under the
scheme outlined above.
There are some details and implications of the BIN routine methods
described above which aren't readily apparent.
Firstly, in exploring the CALL ABSOLUTE assembly interface, one will
soon discover that FUNCTIONs are not readily supported. The simple
solution to this will serve to exemplify an important aspect of
QBasic/BIN programming - the QBasic "front-end" routine.
We met the front-end routine in our example program, in the guise of
the BlockCopy routine. This routine served to insulate our main
The QBNews Page 31
Volume 3, Number 1 March 29, 1992
program from the details of loading and calling the BIN file. It was
called with only the parameters relevant to the task at hand, and in
turn called the ABSOLUTE routine with the additional BIN-file specific
parameters.
Since the front-end file takes care of some of the dirty details of
BIN file calls in easy-to-code-and-maintain QBasic, we can simplify
the assembly routine, often the hardest to write and most difficult to
maintain part of the hybrid program.
Take the example of a routine which uses the BIOS to print a
character. In QBasic, we would like to pass to the routine the
character, its positional row and column on the screen, and the
foreground and background colours in which to print the character.
Our calls to this routine might look like this:
BIOSPrint Char$, Row%, Col%, Fore%, Back%
Anyone who has written assembly routines for BASIC will attest to the
hassles involved in accessing BASIC's dynamic strings. It would be
nice to write the routine to receive the ASCII value of the character
instead as an integer. Furthermore, the BIOS routines use 0-based
screen positioning, as opposed to the 1-based positioning used in
QBasic. To insulate the user from confusion, the routine should
adjust QBasic row and column values to BIOS values, and even build
them into a single integer to be loaded into a register for the BIOS
call. Lastly, the BIOS routine will want a single integer colour
attribute, meaning you will have to program the conversion routine if
the separate colours are sent. Really, then, the BIN routine really
wants the parameters sent like this:
CALL ABSOLUTE(AsciiValue%, BIOSPosition%, Attribute%, BINAddress%)
Your front-end routine, then, can take care of all of these
conversions, thus minimising the assembly code so it performs only
that which QBasic can't do for itself:
SUB BIOSPrint (Char$, Row%, Col%, Fore%, Back%)
STATIC BINFile$
IF BINFile$ = "" THEN BINFile$ = LoadBinFile("BIOSPRT.BIN")
AsciiValue% = ASC(Char$)
BIOSPosition% = (Row% - 1) * 256 + (Col% - 1)
Attribute% = (Fore% AND 16) * 8 + (Back% AND 7) * 16 + (Fore% AND 16)
DEF SEG VARSEG(BINFile$)
CALL ABSOLUTE(AsciiValue%, BIOSPosition%, Attribute%, SADD(BINFile$))
END SUB
The front-end routine also answers the FUNCTION problem. Here is the
code for a fictitious CurDrive function which would act identically to
the one in the QBIN demo program:
FUNCTION CurDrive%
STATIC BinFile$
' returns logged drive (a=1, b=2, etc)
The QBNews Page 32
Volume 3, Number 1 March 29, 1992
IF BinFile$ = "" THEN BINFile$ = LoadBinFile("CurDrv.BIN")
AXReg% = 0
DEF SEG VARSEG(BinFile$)
CALL ABSOLUTE(AXReg%, SADD(BinFile$))
CurDrive% = AXReg% MOD 256 + 1
END FUNCTION
Since you can't return values to CALL ABSOLUTE in the same way you
would when writing assembly FUNCTIONs for compiled QuickBASIC, you
have to provide your assembly routine with references to variables to
be changed and then use the front-end routine to pass them to the
caller via a FUNCTION.
The second point I'd like to make is more far-reaching and has much
more potential for power - the use of strings containing BIN files as
parameters to your BASIC routines.
Anyone who has used Nantucket's Clipper 5.x product will know the
power of "code blocks". These are sections of code which can be
assigned to a variable and passed between routines like data.
Actually, the code is static in memory and the routines receive
references, but knowledge of these details is not necessary. In this
way (among others), the Clipper implementation differs from that of C
and PASCAL, for instance, where you use "pointers to functions", which
demand that you dwell on some of these details directly.
Let's say you want to write a generic sort routine. You want it to
support ascending and descending sorts, as well as sorting starting at
a certain column of the input strings.
The normal way to do this would be to provide a passed argument
specifying which of the hard-wired methods to use, for example:
CALL SortArray ( Array$(), TypeOfSort% )
Deeper inside the routine, you would have code similar to:
SUB SortArray (...
...
SELECT CASE TypeOfSort% ' choose hard-wired method
CASE 1 ' ascending
IF Array$(i) < Array$(j) THEN SWAP Array$(i), Array$(j)
CASE 2 ' descending
IF Array$(i) > Array$(j) THEN SWAP Array$(i), Array$(j)
CASE 3 ' sort from column 5 ascending
IF MID$(Array$(i),5) < MID$(Array$(j),5) THEN SWAP ...
...etc
If you were to write a series of ASM routines, however, each of which
took two string parameters, performed a comparison according to your
latest whim, and returned a true-or-false value, then saved these as
BIN files, you could simplify your routine to:
Compare$ = LoadBINFile( "MyAsmFn.BIN" )
The QBNews Page 33
Volume 3, Number 1 March 29, 1992
CALL SortArray ( Array$(), Compare$ )
SUB SortArray (...
...
IF CallBINFunc(Compare$, Array$(i), Array$(j)) THEN SWAP ...
You and your users can now write ASM modules yourselves to your specs
and extend the functionality of your routine without touching its
innards.
You could also use this method to send a user-defined filter condition
to your display routine, or to tell an event handling routine what to
do when it is triggered - all completely extensible without
recompiling your main code or even having access to source!
Unfortunately, the kind of flexibility that would really make these
methods shine (access to QBasic variables, definition of code blocks
in QBasic itself, pointers to functions...) isn't available with
external BIN files. Perhaps Microsoft has been thinking of something
like this for the future? I would be interested in anyone's ideas on
how to expand on these concepts.
I can be found lurking about many QuickBASIC conferences on the
various BBS networks, including Fido's QUIK_BAS echo, ILink, RelayNet
(RIME), and NorthAmeriNet (NANET). Feel free to drop by and say hello.
SOURCE CODE FOR THIS ARTICLE CAN BE FOUND IN QBASIC.ZIP
======================================================================
Brent Ashley is a Technical Support Analyst for the Ontario
Government, troubleshooting a province-wide data communications
network and providing hardware and software support to a 24-hour
micro/mainframe helpdesk operation. He can be reached in care of this
newsletter.
======================================================================
The QBNews Page 34
Volume 3, Number 1 March 29, 1992
----------------------------------------------------------------------
S w a p S h o p - Q B S o u r c e C o d e E x c h a n g e
----------------------------------------------------------------------
Creating Vertical Menus by Bernard Veerman
You don't always need a complex set of routines to perform WINDOW like
techniques. To avoid confusion with the word WINDOWS, from hereon I'll
use the buzzwords TABLES and PAGES. As a matter of fact, the basics do
have things in common, but I prefer to keep things clear (and fast). I
need tables in my programs like files, text and directories. These I
want to display, move forwards and backwards through it, select and
pick an item and that's it. The programming for that I did myself, be-
cause I couldn't find any flexible and uncomplicated software. What is
left, are some powerful subprograms that might be used by itself or
may be added to a (personal) library. The "tables" are made reentrant,
that means: use the table as you wish, destroy the existing screen and
recall the table any time you need it. The advantage is, the table
attributes and pointers are popped from a stack and allow you to con-
tinue where you left off. Want to relocate the table, just open it
again and tell it where to pop up. Basically there is nothing more than
2 calls:
TABLOPEN, pushes attributes and pointers to an internal stack;
TABLSLCT, displays the table and handles keystrokes.
the syntax of both functions is:
TABLOPEN TNR, ROW, COL, HGT, WID, SF, SB, BF, BB, TY$
TNR = table number, in this example valid between 1 and 6.
Array TablDefs could be part of your library.
ROW = row where table is to be displayed on the screen. If you intent
to use a frame around your tablepage, ROW is the display line
where the frame will start. Height and Width are adjusted by the
function.
COL = column where table is to be displayed on the screen. See ROW for
comments on Height and Width.
HGT = is tableheight in lines. Validation is left out the program to
keep the coding simple and clear. You may add validation if you
wish, it won't be difficult. HGT will be 2 less if a frame is
used.
WID = is tablewidth in characters. Also no validation, same as HGT.
WID also will be 2 less if a frame is used.
FS = foreground color of screen. See COLOR instructions as explained
in your DOS manual. VZCOLORS.BAS includes the dutch names for
colors, brightness and blinking. No validation is done on colors
escpecially equal fore- and background colors might cause confu-
sion. Something like black characters on a black background. If
The QBNews Page 35
Volume 3, Number 1 March 29, 1992
you do this careful, you will have no problems.
BS = background color of screen. See FS parameter.
FB = foreground color of bar. The bar will run up and down over the
table entries and is advised to have a different color than the
screen to make it visible.
BB = background color of bar. See FB parameter.
TY$ = type of frame, if you need one. "" (null string or character)
means that you don't want a frame. "S" will create a single
line frame, "D" a double. Lowercase is allowed. In the coding
you find a routine called DRAWBOX as you'll find in any library,
so if you have one of your, than use it.
After declaration of your table(s) nothing happens until you call the
table handler TABLSLCT. Since all attributes and pointers are pushed
on the stack TablDefs, it simply uses the table number to pop them
back to where you need them. All, except two (PTR and CUR), are
treated as CONSTANTS until you change them. PTR and CUR are saved as
soon as you leave the table handler for further use. The table handler
returns them when you access the table again. This is one of the nicer
features, because in this way tables are reentrant. For a good impres-
sion of how things work, look in the example program where you find
the 3 OPEN's and then how they are used.
The full syntax of the table handler is:
TABLSLCT TNR, Table$(), Entry$
TRN = table number, between 1 and 6, by using this number you will
make the table handler refer to the stack entry where attri-
butes and pointers for this table are stored.
Table$() = name of the table you want to use. The table must be decla-
red with a DIM statement and filled with the data you want
to be handled by the table handler.
Entry$ = will return your pick from the table or "<ESCAPE>" if you
used the escape key. This is very convenient if you need
to know if an escape was used.
The table handler uses a couple of functions and a stack to store the
attributes and pointers. The stack and the internal subprograms are
strongly advised to integrate in a (personal) library so that you
don't have to worry about these things when you're using the table
handler. So again convenience is very important. Just fancy this:
DIM Titles$(250)
now fill array with data
TABLOPEN 1, 250, 6, 60, 16, 20, WT, ZW, ZW, WT, "S"
The QBNews Page 36
Volume 3, Number 1 March 29, 1992
TABLSLCT 1, Titles$(), Book$
now, talking about powerful programming! To explain these statements
in brief:
DIM Titles$(250) allocate array for 250 titles
fill array with titles
TABLOPEN 1, 200, 6, 60, 16, 20, WT, ZW, ZW, WT, "S"
| | | | | | | | | --- single line frame
| | | | | | | | +----- bar: black on white
| | | | | | | +----- screen: white on black
| | | | | | +--- table with 20, including frame
| | | | | +--- table height 16, including frame
| | | | +--- column to display table
| | | +--- row to display table
| | +--- actual number of entries used in array Titles$
| +--- table number in stack TablDefs
+--- call to declare table
TABLSLCT TNR, Titles$(), Book$
| | | ------- returns your pick or "<ESCAPE>"
| | +--- tell table handler to pick from array Titles$
| +--- use attributes and pointers as declared for table 1
+--- call table handler
In a matter of facts, this is all you have to do. The demo-program
shows how you can use the table handler. To summarize, for the user
two sub programs are called to handle tables:
1. TABLOPEN
2. TABLSLCT
the table handler itself uses some internal subprograms and needs a
stack to store the attributes an pointers, they are:
1. TablDefs(), reasonable dimension is (6, 12).
2. DRAWBOX or any other similar function.
3. TABLDISP, this one displays a table page.
4. TABLLINE, this one switches lines from normal to reversed video
and back.
5. TABLLOAD, this copies the attributes and pointers to the handler.
SOURCE CODE FOR THIS ARTICLE CAN BE FOUND IN TABLE.ZIP
======================================================================
Bernard Veerman is a professional IT staff member at Amsterdam
Schiphol Airport in the Netherlands. He has been using QuickBASIC
since version 2.0, and has a number of shareware utilities available.
He can be reached at the following address:
Bernard Veerman
Donizettihof 5
2402 EH ALPHEN ad RIJN
NETHERLANDS
======================================================================
The QBNews Page 37
Volume 3, Number 1 March 29, 1992
Windowing in BASIC by Mark Butler
Preface by David Cleary
The last issue of The QBNews contained an assembly language windowing
library written by Christy Gemmel. This proved to be on of the most
popular articles ever in The QBNews. However, some people said "The
ASM routines are great, BUT, I program in BASIC and I want to see
BASIC routines to do that." You've got your wish. A little while ago,
Mark Buttler posted this code in the Fidonet QuickBASIC echo, and I
was quick to capture it. It is comprised of three routines. They are:
Explode (UpRow%, LCol%, LoRow%, RCol%)
Expand (UpRow%, LCol%, LoRow%, RCol%)
ScreenClear (LineColor%)
They are contained in WINDOW.BAS. Explode will pop a window on the
screen instantly. Expand will create a window that expands little by
little. ScreenClear is a neat little special effect for clearing the
screen. Load WINDOW.BAS up in your QB editor and enjoy.
----------------------------------------------------------------------
Viewing Files in BASIC by Matt Hart
This is another gem that was posted in the Fidonet QuickBASIC echo by
Matt E. Hart, QB Guru (echo joke). It is a complete routine that
allows viewing of a text file of up to 16384 lines without the use of
temporary files. The routine supports the arrow keys, page up and
down, home and end, and escape.
' View any size text file without
any temporary files. ' Keeps the SEEK position of each line in a long
integer array - ' which does limit this to 16,384 lines of text (and
makes this ' program easy, small, and fast.) Key controls are up,
down, ' left, right, page up, page down, end, home, and escape.
Although the program is laid out as a stand alone application, you
shouldn't have too much trouble integrating it into your own programs.
The code is contained in VIEWFILE.BAS.
The QBNews Page 38
Volume 3, Number 1 March 29, 1992
----------------------------------------------------------------------
A l g o r i t h m s
----------------------------------------------------------------------
QuickInsert Sort Algorithm - a push from B$ASSN by Larry Stone
One of the fastest, all purpose sort algorithms, is QuickSort.
QuickSort is one of the sort routines supplied with the Microsoft
program, "DEMOSORT.BAS". Speed is achieved by picking a random pivot
point then moving every element bigger to one side of the random point
and every value smaller to the other side. QuickSort then recursively
calls itself from within its two areas of code that deal with those
elements greater or smaller than the pivot point.
I like QuickSort but, alas, there are a couple of limitations that
prevent me from incorporating into my code. The first is the fact
that the pivot point is randomly selected. This means that the
floating point library is loaded into the program. This is no small
matter. The floating point library can add upwards of 10,000 bytes to
one's final EXE size and, if the program is designed to avoid using
floating point routines, this then becomes a prohibitive cost.
The floating point library can be avoided by substituting a "homemade"
random routine - one that uses LONG integers in lieu of real numbers.
An outstanding replacement one could use is found in the book,
"Microsoft QuickBASIC Programmer's Toolbox", by John Clark Craig.
Craig's random generator is a QB version of two routines described in,
"The Art of Computer Programming", Vol. 2, "Seminumerical Algorithms",
by Donald Knuth. The random generator is an excellent replacement for
QB's because it not only doesn't use floating point but also, it has a
sequence length greater than 2^55 with a possible 256^83 possible
sequences. That's an awful lot of random numbers!
The real disadvantage to the QuickSort is the fact that it uses
recursion. If there is a lot of data to sort, this recursive routine
will blow the top of the stack. This can be overcome by setting a
larger stack. Placing the statement, "CLEAR,,16384" at the top of the
code will establish 16K of stack space. Conversely, "STACK 16384&"
will do the same with PDS and the linker option, "/ST:16384", will do
it if one compiles using PDQ. However, there is no free lunch.
Increasing the stack size is accomplished by a comparable reduction in
code and string space in DGROUP.
Two other, quick sort routines may offer relief. The WAVE sort,
developed by Richard F. Ashwell for GW-BASIC is somewhat slower than
the QuickSort but on large sorts, it really shines. Another extremely
fast sort that on average, is just a smidgen slower than the
QuickSort, is the ripple sort algorithm that MicroHelp supplies with
some of their tools. However, it seems logical that the absolute
fastest sort should be an insertion sort - ie, sorting the data while
it is gathered, intuitively, is faster than other techniques that
requires two separate steps, a gathering followed by sorting.
Unfortunately, BASIC insertion sorts are notoriously slow. They are
The QBNews Page 39
Volume 3, Number 1 March 29, 1992
slow for two, related reasons. They require loops that must touch and
compare array elements, one at a time, until the insertion point is
located. This is generally accomplished by STEPping a FOR...NEXT loop
in a negative direction, pushing each element "up the ladder" until
the appropriate element is freed for insertion with new data. In three
words, slow, slow, slow.
"I-INSERT.BAS" overcomes the, up-to-now, inherent slowness of BASIC
insertion sorts by incorporating two separate processes into its
algorithm. The first part of the algorithm uses a modified binary
search to quickly locate the appropriate insertion point. The binary
search algorithm is not the generic binary search. Although, like any
binary search, it looks for a match between an array elements data and
the data to be inserted, it also looks for the appropriate spot where
the existing array data has greater value on the up-side and lesser
value on the down-side. The test data used by I-INSERT contains 150
random integers. On average, the binary search requires 5 steps into
the array to locate the appropriate insertion point for each value
inserted. The maximum number of steps required (for this data group)
is seven and the minimum is one.
The binary search is fast, not only because it minimizes the number of
steps needed to locate the insertion point but also speeds along due
to the nature of its architecture. If you look at the code, you will
note that mathematics are limited to a single expression that adds the
begin value to the ending value. Although the result of this is
divided by two, the division is integer division which QB will compile
as a shift instruction - "middle% = (begin% + ending%) \ 2". The math
like instructions, "begin% = middle% + 1" and "ending% = middle% - 1"
are compiled as INC and DEC instructions to the CPU - again, very
fast. The search performs five tests. The first test is the
conditional entry into the loop, "DO WHILE begin% <= ending%". Two of
the tests are simple comparisons. One test isn't even a test but,
rather, a fallthrough if the previous three tests within the loop are
false. The slowest portion of the search is the first test. It tests
two conditions and if the condition is met, then tests whether the
insertion point is located.
The second algorithm that comprises I-INSERT is the code that moves
the existing data upwards in order to free the appropriate element for
data insertion. It too, contains a single mathematic expression
composed of a compiled SUB and IMUL instruction:
"MoveBytes% = (LastElement% - middle%) * LEN(Arry%(Low%))"
The actual moving of the array's elements is performed by a call to
the routine, "QBMemCopy". This routine is an ALIAS for the QB
procedure, "B$ASSN". B$ASSN copies a specified number of bytes from
one memory location to another memory location in one, very quick
move. B$ASSN requires six parameters: FromSegment, FromOffset,
BytesToCopy, ToSegment, ToOffset, and BytesToTransfer. All are
integers and all must be passed by value. Well, to speed things up
just a wee bit more, the ALIAS for B$ASSN, "QBMemCopy", was declared
using only four arguments: FromAddress, BytesFrom, ToAddress, and
The QBNews Page 40
Volume 3, Number 1 March 29, 1992
BytesTo. Reduction in the number of arguments was accomplished by
using the "SEG" directive which will push the segment and offset onto
the stack. Although the stack still has the same number of arguments,
execution time is again improved because the code does not require a
VARSEG and VARPTR instruction (QB is already aware of the variable's
address so a simple SEG directive suffices). BytesFrom and BytesTo are
still passed by value.
I-INSERT does have some limitations. The first is that B$ASSN can only
move 64K bytes at a time. And, as presently written, it can only move
32K bytes. If you need to move more than 32K but less than 64K then
make the following modification to the code that establishes MoveBytes:
M& = 1& * (LastElement% - middle%) * LEN(Arry%(Low%))
MoveBytes% = M& - 65536 * (M& > 32767)
If you need to move more than 64K bytes then you must do it in
"chunks".
Because B$ASSN performs its copy in a forward direction, you must DIM
another array of equal size to the array you will be inserting into
(or equal to your largest "chunk"). QBMemCopy, the ALIAS for B$ASSN,
first copies a block of memory, bounded by the insertion point to the
last existing array element, to the scratch buffer or working array.
From there, it copies back to the original array but places the data
up one element from their original positions. Once this is
accomplished, the new value is then inserted.
A speed improvement and memory reduction can be achieved using the
MicroHelp routine, MhMove in lieu of B$ASSN. MhMove is smart enough to
realize that data is being moved within the same segment. When MhMove
"sees" this, it reverses the direction flag thereby, allowing for the
copy to be performed only once. As a consequence, MhMove does not
require the work array as a temporary scratch buffer which means that
the memory allocated for B$ASSN to make its first copy to does not
have to be allocated - hence, both a speed and memory improvement.
Using I-INSERT's QuickInsert routine is as easy as eating apple pie.
As your code reads in data, pass QuickInsert the value, the next array
element that is available (LastElement%), and the array in which to
insert the data. The work array or scratch buffer is DIM SHARED as
TempSortArray%() and is not passed in the arguments list (If you use
MhMove or a similar ASM routine then TempSortArray does not even need
to be created.) That's all there is to it.
It needs to be noted that the QuickInsert routine will not execute
from within the QB or QBX environment. This is because neither
environments will recognize the ALIAS for B$ASSN. You must compile it
to run it. Also, if you desire to test its speed against other sort
procedures, to be fair, these procedures need to be timed from the
point in which data is first copied into an array because QuickInsert
is sorting while the array gets filled.
By-the-way, B$ASSN, among other things, is used by QB to copy data
The QBNews Page 41
Volume 3, Number 1 March 29, 1992
from TYPE to TYPE and fixed-length strings to variable length strings.
As a consequence, a lot of QB internal string handling code will be
included with your program if you use this routine. This won't be very
noticeable if your program already uses string handling routines. But
if it doesn't use strings then you should be aware that your EXE size
will substantially increase by declaring and using B$ASSN.
Two final notes. I was originally going to name the routine the "Stone
Insert Sort" but false modesty prevented that. The second is a
challenge. I challenge you, the reader, to discover other QB internals
that can be applied in ways to perform insert sorts on strings and
string arrays.
SOURCE CODE FOR THIS ARTICLE CAN BE FOUND IN I-INSERT.ZIP
======================================================================
Larry Stone is the author of the shareware file manager "SERVICES" and
is also a frequent contributor to The QBNews. He can be contacted in
care of this newsletter.
======================================================================
The QBNews Page 42
Volume 3, Number 1 March 29, 1992
----------------------------------------------------------------------
F u n a n d G a m e s
----------------------------------------------------------------------
Having A Ball - Solution to 12 Ball Problem
I've received exactly one entry into our little 12 ball problem
contest. Luckily, it was correct. A hearty congratulations goes out to
Jim Eccleston of North Vancouver, BC Canada. He wins our grand prize
of a one year subscription to The QBNews. Here is how Jim did it.
----------------------------------------------------------------------
Not very elegant but functional solution to "BALLS" in BALLS.BAS from
Jim Eccleston
North Vancouver, BC
Accompanying info for solution program (in .BAS file also)
Flowchart for weighing sequence structure above follows, with balls
represented by alpha characters A thru L. ( I was less confused! )
Letters shown in the balance pans. Outcome is Left, Balanced, Right
L suffix in letter pairs = underweight, H suffix = overweight
1st Level Weighing
+------+------+
| EFGH | IJKL |
+------+------+
|
+-------------------+---------------------+
2nd Level | | |
+------+------+ +-----+-----+ +------+------+
| IJKE | LABC | | BCD | JKL | | EFGI | HABC |
+------+------+ +-----+-----+ +------+------+
| | | | | | | | |
3rd Level | | | | | | | / |
+---+---+ | +---+---+ | | | +---+---+ | +---+---+
| J | K | | | E | A | | | | | F | G | | | I | A |
+---+---+ | +---+---+ | | | +---+---+ | +---+---+
KL IL JL | EH LL * | | | GL EL FL | IH HL *
| / | \ \
+---+---+ / | \ +---+---+
| G | H | / | \ | K | L |
+---+---+ / | \ +---+---+
GH FH HH | | | KH JH LH
+---+---+ +---+---+ +---+---+
| C | D | | A | L | | C | D |
+---+---+ +---+---+ +---+---+
CH BH DH AH * AL DL BL CL
* = Innaplicable
The QBNews Page 43
Volume 3, Number 1 March 29, 1992
Find above a solution to the Having a Ball problem which I'm sure
will arrive far too late from the frozen north to stand a chance at
the prize unless there's a Canadian section :) , but the feature
is a great addition and I hope it is continued. The problem reminds
me of one I saw in the 60's that used a set of base 3 weights.
Am sending also a small piece of video chewing gum you may want to
use for entertainment purposes or your readers might enjoy.
Best Wishes for this New Year and many thanks for a job
exceedingly well done.
Jim Eccleston.
----------------------------------------------------------------------
All files are contained in the file BALLS.ZIP. Jim's solution is in
the file WINNERS.BAS while Charles Graham's solution (originator of
the problem) is in the file BALLS.BAS. I've also included a small
program Jim sent in with his entry that I think is quite interesting.
It is in the file WORMS.BAS. Load it into QB and enjoy.
The QBNews Page 44
The QBNews Master Index for Volume 2 March 28, 1992
Article Name Vol Issue
======================================================================
Algorithms
Cardan's Method for Solving Cubes...................... 2 3
Improved Cloning Algorithm............................. 2 2
Playing Around with Random Numbers..................... 2 1
Reversing Color Attributes............................. 2 1
Assembler
Event-Driven Mouse Support Library..................... 2 3
Fast Screen Printing................................... 2 2
Pop-Up Windows......................................... 2 4
Setting Error Levels with QB........................... 2 1
CALL INTERRUPT
A Bug Free CALL INTERRUPT.............................. 2 3
Add BASIC 7's DIR$ Routine to your QB Programs......... 2 2
Everything You Wanted To Know About a Program.......... 2 1
How to Copy Files with QB.............................. 2 2
Charles Graham
ASCII Art -- A Piece of Computer History............... 2 2
Having a Ball.......................................... 2 4
How I Came to Know and Love ANSI.SYS................... 2 1
Lines with Style....................................... 2 3
Christy Gemmel
Fast Screen Printing................................... 2 2
Pop-Up Windows......................................... 2 4
Communications
A Look at Crescent Software's PDQComm.................. 2 2
PDQComm 2.5 from Crescent Software..................... 2 1
Using COM3 and COM4 with QB............................ 2 4
Copyrights
Intellectual Property Protection....................... 2 1
Cornel Huth
A Bug Free CALL INTERRUPT.............................. 2 3
Daniel R. Berry
Working with the Rodent................................ 2 2
David Cleary
Add BASIC 7's DIR$ Routine to your QB Programs......... 2 2
Having a Ball.......................................... 2 4
How to Copy Files with QB.............................. 2 2
Setting Error Levels with QB........................... 2 1
Special Preview of Visual Basic........................ 2 2
David Postler
Intellectual Property Protection....................... 2 1
The QBNews Master Index for Volume 2 March 28, 1992
Article Name Vol Issue
======================================================================
David Rice
Create Bar Charts in Text Mode with QB................. 2 2
Create Pie Charts with QB.............................. 2 2
Dick Dennison
Using COM3 and COM4 with QB............................ 2 4
Ethan Winer
QB's Hidden Data Copying............................... 2 3
File IO
Add BASIC 7's DIR$ Routine to your QB Programs......... 2 2
Getting and Setting File Attributes.................... 2 1
How to Copy Files with QB.............................. 2 2
Fred Sexton Jr.
Manipulating Sprites in SCREEN 13...................... 2 3
Fun and Games
ASCII Art -- A Piece of Computer History............... 2 2
Having a Ball.......................................... 2 4
Lines with Style....................................... 2 3
Graphics
A Graphics Mouse Cursor Design System.................. 2 2
Create Pie Charts with QB.............................. 2 2
Fonts in a Can......................................... 2 3
Lines with Style....................................... 2 3
Manipulating Sprites in SCREEN 13...................... 2 3
Reading Print Shop Graphics in QB...................... 2 1
J. D. Hildebrand
Spill the Wine......................................... 2 3
James Young
Playing Around with Random Numbers..................... 2 1
Jim Harre
A Look at Crescent Software's PDQComm.................. 2 2
John Richard De Palma
BASICZen............................................... 2 2
Keith Rolland
Everything You Wanted To Know About a Program.......... 2 1
Larry Stone
Fonts in a Can......................................... 2 3
Improved Cloning Algorithm............................. 2 2
The QBNews Master Index for Volume 2 March 28, 1992
Article Name Vol Issue
======================================================================
Larry Stone
Lines with Style....................................... 2 3
Mike Welch
Introduction to QuickSHARE............................. 2 1
Reading Print Shop Graphics in QB...................... 2 1
Monte Ferguson
Detecting Desqview from
QB............................. 2 1
Mouse
A Graphics Mouse Cursor Design System.................. 2 2
Event-Driven Mouse Support Library..................... 2 3
Working with the Rodent................................ 2 2
QBNews Professional Library
Event-Driven Mouse Support Library..................... 2 3
Fast Screen Printing................................... 2 2
Pop-Up Windows......................................... 2 4
Ray Crumrine
The UEVENT Bug......................................... 2 4
Richard Jones
Cardan's Method for Solving Cubes...................... 2 3
Richard Randles
Getting and Setting Bits............................... 2 1
Rick Cooper
Getting and Setting File Attributes.................... 2 1
Reversing Color Attributes............................. 2 1
Screen IO
Create Bar Charts in Text Mode with QB................. 2 2
Fast Screen Printing................................... 2 2
How I Came to Know and Love ANSI.SYS................... 2 1
Pop-Up Windows......................................... 2 4
Reversing Color Attributes............................. 2 1
Shareware
Introduction to QuickSHARE............................. 2 1
Source Code
A Bug Free CALL INTERRUPT.............................. 2 3
Add BASIC 7's DIR$ Routine to your QB Programs......... 2 2
Cardan's Method for Solving Cubes...................... 2 3
Create Bar Charts in Text Mode with QB................. 2 2
Create Pie Charts with QB.............................. 2 2
The QBNews Master Index for Volume 2 March 28, 1992
Article Name Vol Issue
======================================================================
Source Code
Creating Smaller QB EXEcutables........................ 2 1
Detecting Desqview from QB............................. 2 1
Event-Driven Mouse Support Library..................... 2 3
Everything You Wanted To Know About a Program.......... 2 1
Fonts in a Can......................................... 2 3
Getting and Setting Bits............................... 2 1
Getting and Setting File Attributes.................... 2 1
How I Came to Know and Love ANSI.SYS................... 2 1
How to Copy Files with QB.............................. 2 2
Improved Cloning Algorithm............................. 2 2
Lines with Style....................................... 2 3
Manipulating Sprites in SCREEN 13...................... 2 3
Playing Around with Random Numbers..................... 2 1
Reading Print Shop Graphics in QB...................... 2 1
Reversing Color Attributes............................. 2 1
Setting Error Levels with QB........................... 2 1
Using COM3 and COM4 with QB............................ 2 4
Working with the Rodent................................ 2 2
T. G. Muench
Creating Smaller QB EXEcutables........................ 2 1
Tony Elliot
Event-Driven Mouse Support Library..................... 2 3
Tools
A Look at Crescent Software's PDQComm.................. 2 2
Custom Control Factory for MS Visual Basic............. 2 2
PDQComm 2.5 from Crescent Software..................... 2 1
Tricks and Tips
Creating Smaller QB EXEcutables........................ 2 1
QB's Hidden Data Copying............................... 2 3
The UEVENT Bug......................................... 2 4
View Print
BASICZen............................................... 2 2
Spill the Wine......................................... 2 3
Visual Basic
Custom Control Factory for MS Visual Basic............. 2 2
Special Preview of Visual Basic........................ 2 2
Warren G. Lieuallen
A Graphics Mouse Cursor Design System.................. 2 2
