Linux, PowerBASIC, and interoperability with Windows

By Frank Cox

(Updated on October 11, 2009)

A combination of Linux and the DOS version of the PowerBASIC compiler is a powerful solution for simple (and not so simple) programming tasks. You can create blazingly fast fully multi-user databases and other applications that run under Linux. As PowerBASIC was designed to run at reasonable speed on XT's, 286's and 386's, it runs like nobody's business on modern multi-gigahertz CPU's. It is also an easy way to write programs on Linux machines that can be instantly copied to and run on MS Windows with no changes required at all, as many versions of Windows can run DOS programs natively. (I am not sure if DOS programs can be run on Windows Vista.) This article describes how to get everything working on Linux, and provides handy programming tips for integrating a DOS program written in PowerBASIC with the rest of your desktop.

April 16, 2007: I wrote the original version of this article on February 6, 2005. Now it's two years later and the project of using PowerBASIC/DOS on Linux has continued. As new requirements and tasks have come up, I have done more software development using PowerBASIC/DOS in the Linux environment. Accordingly, I have decided to update and expand this article to include some of the new ideas for integrating DOS-based programs written in PowerBASIC that I have come up with over the past while.

June 30, 2007: Added section on using /dev/random to seed the PowerBASIC random number generator.

November 28, 2007: Added section on using 64-bit (x86_64) Linux.

January 29, 2008: Added note regarding PowerBASIC for Linux release announced in 1999.
October 29, 2008: Updated the link to the announcement to point to The Internet Archive due to the fact that the original message from Dave Navarro has now been deleted from the PowerBASIC website. Also added another link to an additional statement.

October 11, 2009: Added note regarding DOSEMU and Fedora Linux versions 10 and 11. Updated references to Fedora 7 and 8, and added reference to Centos 5. Added reference to BAS.

A few years ago, I was asked by a friend of mine to write a database program for him to run on his Windows 98 and Windows XP computers to keep track of classified ads for his small publishing business. This presented a neat problem for me, because while I have several computers, none of them run any version of Windows at all, and I don't have any Windows development tools (compilers and whatnot) either.

After giving this matter some thought, I decided that the easiest way to gain immediate cross-compatibility with between my Linux machines and his Windows computers would be to write the program to run under DOS. DOS programs run natively under all versions of Windows, and there are two DOS emulators available for Linux.

In the “old days”, I used to do a fair bit of programming using PowerBASIC, which is an excellent, very fast, and reasonably priced BASIC compiler for DOS that includes loads of extensions and improvements over what you may think of as BASIC: structured programming, types and unions, bit operations, and a whole lot more. It is still available for sale at the PowerBASIC website.

Note: Due to the attitude that the PowerBASIC owner and staff have displayed toward me over the past few years, I can no longer recommend that anyone purchase PowerBASIC tools or compilers. This is unfortunate, because the technical quality of the compiler is quite good.

Accordingly, I dusted off my old PowerBASIC disks and manuals, and proceeded to install them on my (at the time) RedHat Linux 9 desktop machine. (Having gone through many upgrades since this article was first written, I now run Fedora 11 and Centos 5 on my computers.) I had never attempted to use PowerBASIC since I retired my old DOS machines a few years before and switched to using Linux exclusively, so this was a rather an adventure. I downloaded and installed DOSEMU, a DOS emulator for Linux. As I use RedHat Linux distributions, it's very simple to install DOSEMU using the rpm that's available on their site. While DOSEMU is capable of using any DOS version that you happen to have laying around, FreeDOS comes built-in to the currently available DOSEMU rpm and the whole thing can be installed with a simple “rpm -i dosemu” command. (Another DOS emulator that's currently available is DOSBOX, and I assume that PowerBASIC would run fine on that too, but since DOSEMU has always met my needs I have never downloaded and installed DOSBOX to be sure.)

I have an icon on my desktop that is the FreeDOS logo. When I click it I run xdosemu, which creates a virtual DOS machine in a window on my Gnome desktop.

You'll notice that the last line here says “SHARE installed.” I will get to the reason for that shortly. FreeDOS (and DOSEMU) comes with a version of SHARE. Here is my complete autoexec.bat, which is installed in the virtual drive C: that DOSEMU creates under the real directory named ~/dosemu/freedos:

@echo off
path c:\bin;c:\gnu;c:\dosemu;c:\utility
set HELPPATH=c:\help
set TEMP=c:\tmp
set BLASTER=A220 I5 D1 H5 T6
prompt $P$G
unix -s DOSDRIVE_D
if "%DOSDRIVE_D%" == "" goto nodrived
lredir d: linux\fs%DOSDRIVE_D%
rem uncomment to load another bitmap font: only if supported by DOSEMU
rem loadhi display con=(vga,437,2)
rem mode con codepage prepare=((850) c:\cpi\ega.cpi)
rem mode con codepage select 850
rem chcp 850
rem uncomment the following to load cdrom support
rem shsucdx /d:mscd0001
echo "Welcome to dosemu %DOSEMU_VERSION%!"
unix -e
loadhi share

This autoexec.bat file is exactly what comes out-of-the-box when you install DOSEMU, with the exception of the last line that loads SHARE.

Here is PowerBASIC 3.5 running on my Fedora Core 6 machine in a window on my desktop:

PowerBASIC runs great under DOSEMU, and it compiles programs at an absolutely blistering pace.

Over 5600 lines compiled and a completed executable written to disk in a tiny fraction of a second, on a 3.2GHz Pentium 4.

Over the course of time the little classified ad database that I initially wrote grew and grew some more, as these things tend to do. Then one fine day my friend decided that he was tired of Windows and all of the problems associated with it (viruses, down-time, and the overall frustration factor) and he asked me to set up a new application server for him using Linux.

The original rather simple single-user database program has now turned into a multi-user suite of programs that manage everything from classified ads to subscriptions; it even creates colour-separated plates for printing presses. It's currently running on a 3.2GHz Intel CPU with 3gb of ram. The operating system is Fedora Core 6, and the Linux Terminal Server Project allows multiple X terminals (currently 6) to be attached so multiple employees can be using, searching and updating the various databases simultaneously. DOSEMU also allows each user to have multiple DOS sessions open, so he can have one window open to do database searches and another open to make new entries if desired.

(The X terminals are Neoware Capio 616 thin clients. These thin clients make great LTSP terminals. They are very small (about the size of a hardcover book) and fanless so they make absolutely no noise when running, and they use less than 30 watts of power. You can occasionally buy them on ebay for less than $20 each.)

PowerBASIC for Linux

PowerBASIC for Linux has been promised “real soon now”, in various emails and newsgroup postings starting from 1998. However, I notice that the front page of the the PowerBASIC website has recently been changed to eliminate mention of of PowerBASIC for anything other than DOS and Windows. This is unfortunate, as a native Linux version of PowerBASIC would be a very neat toy indeed.

NOTE: On his web forum, Bob Zale (owner of PowerBASIC) asked me to substantiate my claim that PowerBASIC for Linux has been promised “real soon now”. When I did so, he deleted my post in the forum and banned me. (Bob seems to be a much better programmer than a public relations person.) Since I make the same statement here in this article, and to avoid any future confusion about this matter, the most explicit mention of a PowerBASIC for Linux release date by a PowerBASIC employee that I have found is here. It was posted on the PowerBASIC web forum by Dave Navarro on March 25,1999, and states “Yes, as announced at Fall Comdex 98, we will have a compiler for Linux some time this year. No other information is available at this time.All other offical posts over the course of the past ten years have been much more general, of the “we're working on it” and “It's a priority” variety, though this archived copy of the aboutpb.asp file from the PowerBASIC website around 2003 also says that Linux is coming soon, right beside a photo of Bob Zale.

Again, due to the attitude that the PowerBASIC owner and staff have displayed toward me over the past few years, I can no longer recommend that anyone purchase PowerBASIC tools or compilers. If you're interested in further details surrounding my current situation with PowerBASIC Inc, you can read a discussion of this issue on the Google Groups archive.

This article will show how to use PowerBASIC/DOS on a Linux system.

IMPORTANT NOTE REGARDING FEDORA 10 AND 11: (This section updated October 11, 2009) Sometime during the updating cycle for Fedora 10, certain programs that use the PowerBASIC directive DEFINT A-Z started crashing. To this day I have no idea why that happens; one day I discovered that PowerBASIC/DOS programs that used to work fine on my recently updated Fedora 10 machines suddenly didn't work any more. Thankfully, the production systems that depend on my PowerBASIC/DOS programs run on Centos 5, which so far appears to be immune to whatever it is that causes the programs to crash.

You can download a test program that causes this crash to immediately occur here:

I periodically try running the above program to see if one of the frequent Fedora updates might magically solve this problem, since one of the updates is what appears to have created it in the first place. And there is good news to report: A recent upgrade to Fedora 11 has once again caused some things to start working, but other things still crash. And I still have no idea what quit or what has been fixed, but my testing so far seems to indicate that the crash no longer occurs when using the correct $_cpu_emu setting. DOSEMU seems to work fine using its default configuration on a fully updated Fedora 11/i386 computer. On a fully updated Fedora 11/x86_64 computer, you must change the default setting of # $_cpu_emu = "off" to read $_cpu_emu = "vm86sim" in /etc/dosemu/dosemu.conf or ~/.dosemurc. This isn't a complete fix but it seems to work better with it than without it.

A complete DOSEMU bug report regarding this issue can be found here:

PowerBASIC (and other DOS programs) on 64-bit Linux

I started running 64-bit Linux on some of my computers starting with Fedora 8. The good news is that DOSEMU runs fine on when it is compiled for x86_64 (which is reasonably painless process, by the way.)
PowerBASIC/DOS itself runs fine on x86_64, and programs compiled with PowerBASIC/DOS also run fine. That's the good news.

The bad news is that PowerBASIC/DOS programs (and every other DOS program that I've tried so far, though I don't use much other than PowerBASIC/DOS) run approximately 13 times more slowly on x86_64 than they do on the very same computer with 32-bit Linux. This is not as big of an issue as it may initially appear, because even 13 times slower on a 3+GHZ computer is faster than computers were running in back in the days when DOS was king of the hill.
For an interesting description of the reason this happens, I highly recommend this brief article. In short, running i386 Linux allows your CPU to use a “Virtual86” mode, while x86_64 Linux requires that the whole thing be emulated in software which obviously takes more horsepower and therefore runs more slowly.
My conclusion is that if you want to run the occasional DOS program (like PowerBASIC and programs compiled with PowerBASIC) on Linux, then x86_64 may be worth using depending on what other native Linux programs you normally use and require. On the other hand, if you are setting up a server for the main purpose of running DOS programs on it (like I do) then i386 (32-bit) Linux is the way to go, simply because a 13 times increase in speed is obviously worth having. There are other pluses and minuses to running 64-bit versus 32-bit Linux that are beyond the scope of this article.

Most modern CPUs can run 64-bit Linux. If you want to determine if yours can, run this command:

grep lm /proc/cpuinfo

If your CPU has 64-bit mode support the output will include the “lm” flag. If it doesn't, then your CPU is only capable of running 16-bit or 32-bit code.

SHARE – The Heart of Multi-User File Access

You can't have multiple users updating files simultaneously without worrying about collisions. The solution to this simple file locking. The SHARE program that comes with freedos works fine with PowerBASIC applications. You get an error 75 on any collisions and can handle them with an "on error" structure.

sub openrandomfile($,filenumber)
shared ad
on error goto share_violation
open$ for random access read write lock read write as # filenumber len=len(ad)
on error goto 0
end sub

sub openoutputfile($,filenumber)
on error goto share_violation
open$ for output access write lock read write as # filenumber
on error goto 0
end sub

sub openinputfile($,filenumber)
on error goto share_violation
open$ for input access read lock read write as # filenumber on error goto 0
end sub

if ERR <> 75 then
print "Error:";ERR;" at pgm-ctr:";ERL
end if
errorpositionholder=csrlin*25 + pos(0)
locate 1,1
print "*"
delay .25
locate 1,1
print " "
locate errorpositionholder\25, errorpositionholder mod 25
resume 0

The sub openinputfile, openoutputfile and openrandomfile above are an easy way to include automatic file locking in your program. As you can see, when one of the sub's is called, the error handler is set to go to the share_violation routine if there is any error, and the file open attempt will be re-tried over and over,four times per second, until the file becomes available.

The section in red prints an asterisk in the top left-hand corner of the DOS window while it is waiting for a file to become available. This is purely a cosmetic touch but it prevents users from thinking that the program has locked up if it's just waiting for a file to become available.

Who is Running a Program?

The simplest way that I have found to keep track of who is using a PowerBASIC program under DOSEMU is to write a script that calls whoami and puts a file into the user's home directory with his username. Then applications can read the active username as follows:

open "d:\whoami" for input as #1
line input #1, whoami$
close 1

Now we have the username in whoami$. I use this stunt with an employee timeclock (punch-in and punch-out, generate shift reports) that has a different menu for the supervisor.

Sharing Access With Groups and Symbolic Links

Here is my "rundosemu.scr" script that is called from an icon on everyone's desktop when they want to access the database and other PB programs:

umask 002
whoami > ~/whoami
unix2dos ~/whoami

I have a symbolic link in everyone's ~/dosemu/freedos directory that points to a directory under /opt. I can just cd to the shared directory under /opt and read and write the database there.

umask 002 allows everyone in the user's group to have read and write access to files written by that user. As long as you belong to the right group, you can read and write to the shared database files.

The last line of everyone's autoexec.bat calls another batch file; this is the first three lines of the second batch file:

@echo off
loadhi share
cd c:\barghntr

c:\barghntr is a symbolic link to /opt/barghntr.

This is all completely transparent to the user and automatic, of course. frontend just calls a menu that exits with various errorlevels that are handled by the rest of my second batch file to call other PowerBASIC programs as required. Clever use of symbolic links can cover a multitude of sins in that regard.

Using this scheme, you can read and write "shared data" to files under your symbolic link to /opt, and read and write "private data" to anywhere under "d:\" that you like. And your shared database (or whatever) is easy to backup because it's all in one place under /opt; I have a cron job set up to do a nightly rsync to a remote machine and the day's data is always backed up with no user intervention required.

Printing Reports and Using Fonts

One way to get pretty reports (assigning fonts and whatnot) from PowerBASIC applications is to write the report to a html file, then import it into OpenOffice for viewing and printing. OpenOffice honours a chr$(12) in a html file, so you can put page breaks where-ever you like.

Here is an example that prints three stars centered in a report:

print #2, "<P ALIGN=CENTER STYLE=";chr$(34);"margin-bottom: 0in";chr$(34);"><FONT FACE=";chr$(34);"Dingbats";chr$(34);">V V V</FONT></FONT></P>"

I used this method to generate reports for quite some time, and then one day realized that if I could create a PDF as an output file instead of a simple HTML document, I could use Acrobat Reader (or Evince, or XPDF, or any other PDF reader program that you wish to use) to display the report for the user to view or print, or save or whatever.

(Acrobat Reader is currently the only PDF viewer on Linux that is really up to the job of handling all PDF files. PDFs seem to come in many different flavors, and all of the open source PDF viewers fall down in one way or another when rendering or printing certain files. Acrobat Reader is the only program that consistently “just works” so the best current option is to simply use Acrobat Reader to display all PDF files. Hopefully this situation will change soon, or eventually.)

The steps involved in creating and viewing a PDF file from a PowerBASIC program are (1) write a HTML file, (2) create a Postscript file from that HTML file, (3) create a PDF from the Postscript file, and (4) crank up the PDF viewer program to display the final result.

I am by no means a HTML wizard. When figuring out how to format a HTML report, my usual practice is to type a sample into OpenOffice and save that as a HTML file. I can then study the structure of that HTML file and write my PowerBASIC program to create a file that looks the same.

I use html2ps to create the Postscript file from the HTML file written by my PowerBASIC program. As html2ps is very picky about the structure of the HTML file that it will process, I have found it best to run the HTML file through HTML Tidy first. (You can install HTML Tidy on Fedora Core 6 by running the command “yum install tidy.) This will also make your PowerBASIC program a bit more robust as your report will (hopefully) not fail to be created if an unexpected character appears in your data.

You should remove or modify certain characters in the data that you intend to include in the HTML file. These characters include “<”, “>”, and “&” as they will screw up the HTML tags. At the least, they will make your report look strange; at the worst they will cause the report to not be created at all.

Here we create our HTML file:

open “d:\report.htm” for output as #1
print #1, "<HTML>"
print #1, "<BODY LANG=";chr$(34);"en-US";chr$(34);" DIR=";chr$(34);"LTR";chr$(34)">"
print #1, "<P ALIGN=CENTER><IMG SRC=";chr$(34);"~/pictures/graphic.png";chr$(34);"NAME=";chr$(34);"Header";chr$(34);" ALIGN=BOTTOM </P>"
print #1, "<P ALIGN=CENTER STYLE=";chr$(34);"margin-bottom: 0in";chr$(34);"><FONT FACE=";chr$(34);"Times New Roman";
print #1, chr$(34);"><FONT SIZE=1 STYLE=";chr$(34);"font-size: 16pt";chr$(34);">";
print #1, "Report Text Here</FONT></P>”
print #1, “</BODY>”
print #1, “</HTML>
close 1

As you see, we can also include graphics in the report if desired.

Now we process the report and display it for the user:

open "d:\report.scr" for output as #1
print #1, "tidy -f /dev/null -o ~/report.tidy.htm ~/report.htm"
print #1, "html2ps -2 -o ~/ report.tidy.htm"
print #1, "ps2pdf ~/"
print #1, "rm ~/report.tidy.htm ~/report.htm ~/"
close 1
shell "unix dos2unix ~/report.scr"
shell "unix chmod 700 ~/report.scr"
shell "unix ~/report.scr"
kill "d:\report.scr"
call header
locate 12,20
print "Close ACROBAT READER to exit this program"
shell "unix acroread ~/report.pdf"

Counting Pages in a Postscript file

When dealing with printing and imposing of documents, there are many occasions where it is necessary to count the number of pages in a Postscript file before further processing or printing.

You can count Postscript pages by counting the number of times %%Page appears in the file. Obviously, you could open the .ps file and start reading through it with line input commands, but it is immensely faster to use the output from grep as demonstrated here:

open "pagecnt.scr" for output as #1
print #1, "cat | grep \%\%Page\: | wc -l > pagecnt.tmp"
print #1, "unix2dos pagecnt.tmp"
close 1
shell "unix dos2unix pagecnt.scr"
shell "unix chmod 777 pagecnt.scr"
shell "unix pagecnt.scr"
kill "pagecnt.scr"
open "pagecnt.tmp" for input as #1
line input #1, temp$
close 1
kill "pagecnt.tmp"

Using this routine you can count a 200 page document in a fraction of a second. Counting the same document using line input commands takes about 30 seconds.

Note that if you are using colour-separated output from Scribus (and maybe other desktop publishing programs), each page of the Postscript output consists of one colour. The pages are in order of Black, Cyan, Magenta, Yellow. Therefore, Page 1 of Black is page 1 in the Postscript file. Page 2 of Black is page 5 in the Postscript file.

Working with PDF files, Imposing Documents, and a RIP

Professional printing generally requires the creation and manipulation of PDF files. Fortunately, you can get Postscript out of just about everything that runs on Linux, either directly or indirectly. You can take the Postscript output from Scribus, OpenOffice or what-have you, and convert it to a PDF using ps2pdf. After you have your PDF in hand, you can do all sorts of magic using pdftk.

Here is an example of a complete software imposition and RIP using ps2pdf, pdftk and Ghostscript:

open "d:\impose.scr" for output as #1
print #1, "#!/bin/bash"
print #1, "ps2pdf -dPDFSETTINGS=/printer -sPAPERSIZE=ledger imposed.pdf"
print #1, "pdftk imposed.pdf cat ";
for temp=1 to totalpages
print #1, trim$(str$(temp));
if temp mod 2 =0 then ' even numbered page
print #1, "E ";
else ' odd numbered page
print #1, "W ";
end if
next temp
print #1, "output 11x17.pdf"
print #1, "rm imposed.pdf"
print #1, "gs -dNOPAUSE -sDEVICE=psmono -r1200 -sPAPERSIZE=11x17 -dCOLORSCREEN ";
print #1, "-dDITHERPPI=";trim$(str$(linescreen));" 11x17.pdf -c quit"
print #1, "rm 11x17.pdf"
print #1, "ps2pdf temp.pdf"
print #1, "pdftk temp.pdf cat ";
for temp=1 to totalpages
print #1, trim$(str$(temp));
if temp mod 2 =0 then ' even numbered page
print #1, "E ";
else ' odd numbered page
print #1, "W ";
end if
next temp
print #1, "output 11x17.pdf"
print #1, "rm temp.pdf"
close 1
shell "unix dos2unix ~/impose.scr"
shell "unix chmod 777 ~/impose.scr"
shell "unix ~/impose.scr"
kill "d:\impose.scr"

Sending Email from a PowerBASIC program

There are many occasions where it is convenient or necessary to send status reports, notices and reminders by email. The easiest way to have a PowerBASIC program send out automatic email is to use email.

After installing and configuring email, you can send messages like this:

open “d:\email.txtfor output as #1
print #1, “This is the email.”
close 1
open "d:\subemail.scr" for output as #1
print #1, "/usr/local/bin/email -s "+chr$(34)+"Email Subject Line"+chr$(34)+" " +recipient$+" < ~/email.txt"
close 1
shell "unix dos2unix ~/subemail.scr"
shell "unix chmod 700 ~/subemail.scr"
shell "unix ~/subemail.scr"
kill "d:\subemail.scr"
kill "d:\email.txt"

Cron – Fully Automated & Scheduled Jobs

Cron allows users to commands automatically at predetermined times. You can run a program once per hour, twice per month, every five minutes, or pretty much any time you wish.

You can run a DOS program as a cron job by writing a two-line script like this:

/usr/bin/dosemu -dumb -I 'keystroke "cd barghntr\rprogram ARGUMENT\rexitemu\r"'

This script loads dosemu and “types” the following commands at the DOS prompt:

cd barghntr
program argument

The \r is a return character.

We change to the directory C:\BARGHNTR, load a program named PROGRAM.EXE and feed it a commandline argument ARGUMENT (which can be read in PowerBASIC using the command$ function). After running the program, we type exitemu to quit and get out of dosemu. If you don't include exitemu, the job will stop after running the program and wait forever.

Notice that we use dosemu here and not xdosemu.

Note also that your DOS program must not require or wait for for any user input.

Call this script from your crontab and it will run your DOS program at any interval that you desire.

Random Numbers

The “standard” randomize timer function of PowerBASIC doesn't work too well when you're running a PowerBASIC program at the same time every day from a cron job. The timer keyword returns the number of seconds since midnight. On a sufficiently fast computer (meaning just about any computer today), a cron job will fire up and the program will seed the random number at exactly the same second every time when you use the timer keyword, so your random number series will always be the same. This isn't the behavior that you normally want to see.

Therefore, a better solution is to use the Linux /dev/random device to seed the PowerBASIC random number generator instead. This way we get a truly random seed number.

open "d:\randomiz.scr" for output as #1
print #1, "/usr/bin/od -An -N2 -i /dev/random > ~/random.txt"
close 1
shell "unix dos2unix ~/randomiz.scr"
shell "unix chmod 700 ~/randomiz.scr"
shell "unix ~/randomiz.scr"
kill "d:\randomiz.scr"
shell "unix unix2dos ~/random.txt"
open "d:\random.txt" for input as #1
input #1, a$
close 1
kill "d:\random.txt"
randomize val(a$)

In this example we extract a 2-byte decimal integer from /dev/random using od. In the od commandline demonstrated here, -An is to turn off the address from displaying, -N specifies the number of bytes that we want to to extract, -i indicates that the display format is an integer.

You can increase the number of bytes, and therefore the size of the random number that you pull from /dev/random, by increasing the value of N.

We could keep on using the /dev/random device every time we want a random number for use in the program that we're running, but it's faster to use the built-in PowerBASIC random number generator and get a seed value from /dev/random.

Having said that, numbers that you pull out of /dev/random in this way will likely be “better” random numbers than the ones that are generated by the built-in PowerBASIC random number function. The /dev/random numbers will actually be more truly random than what you get from the built-in function. Depending on the program that you are writing, this may be of value and the extra overhead caused by pulling all of your random numbers from /dev/random may be worthwhile.

For most purposes, pulling the initial seed value from /dev/random and using the built-in function after that will be sufficient.

Secure Remote Data Acquisition

You can set up a secure transaction and retrieve data from an online credit card processor. Here is an example that will retrieve a report from a real online credit card processor:

open "d:\ccard.scr" for output as #1
print #1, "wget -O ~/ccdata.txt --secure-protocol=auto --post-data=";
print #1, chr$(34);"loginCompany=CompanyNameloginUser=admin&loginPass=123456&rptStartMonth=";
print #1, left$(DateMath(date$,-1),2);
print #1, "&rptStartDay=";mid$(DateMath(date$,-1),4,2);
print #1, "&rptStartYear=";right$(DateMath(date$,-1),4);
print #1, "&rptEndMonth=";left$(date$,2);
print #1, "&rptEndDay=";mid$(date$,4,2);
print #1, "&rptEndYear=";right$(date$,4);
print #1, "&rptStatus=0&rptCardTypes=";chr$(34);
print #1, ""
print #1, "unix2dos ~/ccdata.txt"
close 1
shell "unix dos2unix ~/ccard.scr"
shell "unix chmod 700 ~/ccard.scr"
shell "unix ~/ccard.scr"
kill "d:\ccard.scr"

We use the DateMath function from dateunit.pbu to calculate the dates that we want to include in this report (specifically, today and yesterday). dateunit.pbu comes with PowerBASIC/DOS in the /example directory.

After this, we can processs ccdata.txt:

open “d:\ccdatafor input as #1
do until eof(1)
line input #1, a$
gosub getfields
gosub getfields
gosub getfields
gosub getfields
gosub getfields
gosub getfields
gosub getfields
gosub getfields
gosub getfields
gosub getfields
gosub getfields
gosub getfields
gosub getfields
gosub getfields
gosub getfields
gosub getfields
gosub getfields
gosub getfields
gosub getfields
gosub getfields
gosub getfields
gosub getfields
gosub getfields
gosub getfields
gosub getfields

Other credit card processors may require report requests to be sent using a different format. I created this routine using information provided by the payment processor. Again, this works exactly as written with at least one online credit card payment processor.

Remote Access

One advantage of running DOS programs with DOSEMU under Linux is that you can access and run the programs remotely. You can easily run PowerBASIC programs on VNC-through-SSH and if your network connection is fast enough you won't know that you aren't sitting in front of the host machine when you do it. And best of all, you don't have to write any networking code at all – DOSEMU and SSH handle the whole thing automatically and transparently.

Other BASIC versions for Linux

I have played around a bit with a few other BASIC compilers and interpreters for Linux.

I have played around with the following Linux BASIC compilers:


So far, this is my favourite BASIC interpreter for Linux. I have written a couple of small programs using BAS and it performs quite well.


This is by far the most advanced BASIC compiler for Linux that I have seen to date (with the exception of REALbasic, discussed below). Its roots as a kind of QuickBASIC knock-off for Linux are very apparent. However, as development of this compiler progresses it seems to be turning into its own language that's similar to BASIC, rather than trying to be a real BASIC compiler. As an example, gosub is not supported in the default mode. There is ongoing work underway to convert Free BASIC into a GCC front-end. FreeBASIC is also available for Windows. As the name indicates, FreeBASIC is free software.

Blassic: The Classic BASIC

Now THIS is an old-school BASIC interpreter. It is very similar to GWBASIC and will in fact run many GWBASIC programs as-is without any modification at all. You could use this to play games out of the old “100 BASIC Computer Games” books. On a more practical note, you can also write scripts in Blassic, If you're looking for a really basic BASIC interpreter just works in exactly the way that you would expect a BASIC interpreter to work, this is it. I have used BLASSIC to write some scripts for managing various aspects of creating PDF files and counting pages. BLASSIC is free software.


XBasic is a BASIC compiler that looks very cool. It uses a system called Imake to compile itself when you first download the archive. To get it to compile on Fedora Core 6 (and possibly other modern Linux distributions) you do the following:

cd src
Edit the Makefile and remove the line “==> Makefile.tmp <==”
Then type make

(Many thanks to Markus Hoffmann, author of XBasic, for assisting me with getting this figured out.)

XBasic is free software.


REALbasic for Linux “Standard Edition” can be downloaded at no charge. The “Professional Edition” is sold on a subscription basis for a yearly fee. I have downloaded and played with the Standard Edition. It looks and feels similar to Visual Basic on Windows. It has a nifty IDE where you can draw your screens and buttons and whatnot. REALbasic is also available for Windows and Mac, but Linux is the only platform where the compiler is free of charge.


As you can see, it is very simple to write and use PowerBASIC programs on a Linux machine, and it is also easy to take advantage of Linux's networking features to enhance the usefulness of your programs. PowerBASIC programs compile and run amazingly fast on modern CPU's.

Other articles written by Frank Cox can be found here.

Frank Cox owns and operates the Melville Theatre in Melville, Saskatchewan, Canada, and has been playing with computers for over 30 years.

January 28, 2008

Creative Commons License
This work is licensed under a Creative Commons Attribution-Share Alike 2.5 Canada License.