BAPI - QBASIC RAD and SDK
January 4, 2004

Note: a new version of this software is available BUT it's a port to PowerBASIC, and is no longer compatible with QBASIC.
Does anyone still use QBASIC? Consider migrating if so...

Here is the product of many years' of my part-time effort. BAPI is a set of QBASIC routines that can be dropped into a QBASIC program and used as if they were functions of the language. This is identical in functionality to the #INCLUDE feature of C, however as BASIC does not have this directive, you must insert the library into each program you write. Each program ends up pretty large, for a QBASIC program, but the BAPI is easy to write with, and makes developing relatively sophisticated tools quite rapid.

There are 50 routines in version 16 of the library; key features:

To use this library, you need:

Included with the library is a management tool, BAPISDK. This makes it easier to manage a collection of BAPI-based programs. The tool itself is BAPI-based, so you can see how it works (full source is included). BAPISDK is most useful during compilation, and for quickly inserting the newest version of the BAPI into a different program which also uses it.

Both the BAPI itself, and BAPISDK, the management tool, are 100% compatible with QBASIC 1.1, FirstBasic 1.0, and PowerBasic 3.5.

I'd like to think that this library makes it easier to program in QBASIC. I'd love to hear from anyone who tries it out.

A few notes on FirstBasic vs. QuickBASIC and/or PDS 7.1. Although QuickBASIC and PDS both enjoy a superior development environment, FirstBasic has one feature in particular that sets it apart from the Microsoft offerings. I'm not sure quite how it does it, but in tests, it seemed to allocate half the amount of memory to strings, compared to the Microsoft compilers - meaning that arrays twice as large can be constructed with FirstBasic. For this reason, programs that compile and execute with FirstBasic may not execute when compiled under QuickBASIC or PDS. For example, this code fragment, which allocates a substantial quantity of memory to a number of arrays, causes an 'out of memory' runtime error when compiled with either Microsoft product, but works flawlessly when compiled with FirstBasic 1.0:

 p.size% = 2000: p.cfgsize% = 25: d.max% = 16: inimodmax% = 100: inielemax% = 200
 DIM infile$(p.size%), dirinfo$(p.size%), lst$(p.size%), tmp$(p.size%), cfg$(p.cfgsize%, 2), dosenvar$(p.cfgsize% * 2), alt%(26)
 DIM m.p$(d.max%), m.m$(d.max%), m.d$(d.max%), b.str$(d.max%), g.p$(d.max%), g.m$(d.max%), g.d$(d.max%), g.i$(d.max%)
 DIM g.l%(d.max%), g.lmax%(d.max%), g.hide%(d.max%), g.c%(d.max%), g.f.x%(d.max%), g.f.y%(d.max%)
 DIM inimod$(inimodmax%, inielemax%), iniele$(inielemax%) 

OK, so that's a lot of memory, the thing is, FirstBasic doesn't even blink, while Microsoft dies at runtime!

And another thing. Compiled FirstBasic programs are fast. Although using the /FPa switch with PDS 7.1 clearly outperformed FirstBasic, FirstBasic clearly outperforms QuickBASIC and PDS without the /FPa switch. Since PDS + /FPa is still not gonna let you use the extra memory FirstBasic provides, FirstBasic, in my view, is the superior product.

compilertests/second (5-test average)
QuickBASIC 4.51494.1542
FirstBasic 1.02792.6872
PowerBasic 3.52872.0426
PDS 7.11583.5906
PDS 7.1 with alternate FPU routines (/FPa)3583.7126

Testing performed using numshow.

Note: a speedtest for PowerBasic 3.5 for DOS has been added for reference purposes. Yep, it's fast too, even faster than FirstBasic (not surprising, since FirstBasic is the shareware version of the PowerBasic compiler), and it compiled my FirstBasic programs out of the box. For 16-bit apps, I'd now use PowerBasic.

Note: a speedtest for QBASIC 1.1 is not included, as it is not a compiler.