Running GW-BASIC under Windows

Now, on disk in the same folder that GW-BASIC is running from, there will be a text file called LISTING.BAS (or LISTING.TXT) which can be opened by any Windows word processing or text editing program.

At the risk of overstating the obvious, see how the above can also be an effective alternative to LLIST, the command we used to use to generate paper listings of our programs.

Sidebar: The above trick of naming a file after LIST can also be done for a block of lines, naturally. Like, "LIST 3000-3500,"module". This too is a mighty handy trick. In this case, a file called MODULE.BAS would be generated that contains only the lines specified. Moreover, because it is actually an ASCII text file, it can be merged into another GW-BASIC program with the MERGE command.

One of the most frequently asked questions about running GW-BASIC programs on Windows machines is why LLIST and LPRINT no longer work like they used to. In December of 2003, I wrote an article on this very subject: "Why LLIST and LPRINT No Longer Work". Below is a condensed version of that answer and some further insight.

This problem is not unique to Windows or GW-BASIC. We used to have "intelligent" printers. That is where font tables were stored, for example. Now, font tables are on disk, and they are accessed by printer drivers built into the operating system or different Windows application programs. If a GW-BASIC program says LPRINT CHR$(9);"Hello", chances are, nobody will intervene to convert the control code to a tab, nor will it likely ever even get to the printer as such. A lot of maybes come into play in such situations. Below are some of them.

If you have an old dot-matrix printer hooked to your computer's parallel port via a Centronics cable, and if your Windows Printer Properties are set up accordingly, you probably do not have a major problem. Maybe. If any of the preceding assumptions are not true, all bets are off.

The most frequent problem encountered by nearly all modern color-ink-jet users is the time lag that is necessary when a printer is first provoked. (This delay is deliberate, needed to ensure that the print heads are warm enough for the ink to flow.) Such time lags were never expected in days of yore.

When we programmers say LLIST, we suppose there is a printer out there somewhere ready to go to work. If the printer does not quickly return a signal that it did it, GWBASIC.EXE presumes the printer died and it returns an error condition: "Printer not ready". At that point, if you hustle, and send the same command to the printer again, it might work. On one of my machines with a Lexmark Z12 attached to it, this sometimes works. But only sometimes.

Even with machine configurations where tricks such as the above work, we have no choice but to put up with what happens on our monitor. Here is what is going on: The GW-BASIC interpreter sends a string of bytes to the printer (so it thinks). That string is intercepted by the operating system. Windows slam-dunks your program out of sight because it has to switch the screen from "console mode" so that it can show you the dialog box associated with your printer. Afterwards, after whatever happens (or doesn't happen), there you sit with a blank look on your face: It is up to you restore your console-mode screen by clicking on your GW-BASIC job down in the "system tray" at the bottom of the screen.

To a certain extent, the above may be a tolerable scheme when doing LLIST of many lines of a program. Maybe. For doing LPRINT of a few characters at a time, forget it: This scheme is worthless. So is using PRINT #1 after having done an OPEN "LPT1" FOR OUTPUT AS 1 because that is effectively how LPRINT works anyway. The second case, however, presents a relatively easy opportunity. By changing the OPEN statement to something like OPEN "printjob.txt" FOR OUTPUT AS 1, all PRINT #1 statements will send strings to a disk file that can later be printed en mass by a Windows program such as Notepad. Maybe, that is, assuming that all output is in fact text-type data.

Another consideration is whether an application treats printed output as a batch or it spits out little chunks on an interactive basis. Report writing programs typically generate their output as a steady stream from start to finish. Interactive programs are like those for POS jobs that print lines one at a time as a cashier enters each item. Programs that are batch oriented can usually be made to work on Windows machines. Those that do stop-and-go printing will most likely be intolerable in a Windows environment.

The above point needs to be reiterated: If an application wants to print lines one at a time, do not blame Windows or GW-BASIC if you are trying to do it on the wrong kind of printer. This sort of problem is not necessarily a fault of GW-BASIC. In fact, the same problem can occur in other languages. Modern ink jet printers are page printers, not line printers. By remembering that LPRINT means Line Print, we are not so apt to attempt something that maybe our hardware simply cannot do.

Another critical aspect can be whether a program outputs "control codes." In days of yore, we made our printers do what we wanted by use of special codes. To switch from normal to italics, for example, on an Epson LX 810, LPRINT CHR$(27);CHR$(52) made sense. For a different kind of printer, it is nearly impossible to predict what will happen if you send it codes like this. That has always been true, by the way. (Most control codes are make and model specific; rarely do the same codes produce similar results on different printers.) On a Windows machine with a modern printer, code sequences such as the above may produce some really funny results. Caveat, and remember that such problems might be your fault because you are sending geek to a device that doesn't speak geek.

Attitude is the key to printing with GW-BASIC on Windows machines. Send all desired output to a disk file, then later, open that file with Notepad or a similar program to send it to a printer. An advantage to this modus operandi is in being able to do fancy formatting on the screen before committing it to paper. The tradeoff is, of course, we can no longer write GW-BASIC programs that do elaborate print formatting. Even columns of figures and such will not often come out aligned as desired. In some cases, it may help to condition a word processing program to use "Terminal" font. Like I said, attitude is one key to solving these problems. Valium and Tylenol may help too, gee whiz.

DOS rules apply here, not Windows. Thus, file names cannot be more than eight characters, followed by a dot (period), followed by not more than three characters. Legal characters are A-Z, 0-9, plus any of ^$~!#%&-{}()@`' and underscore (_). No name may contain any spaces anywhere.

Although it is also possible to include characters from the "upper 128" of the old "Standard PC Character" set, those for drawing boxes, for example, will NOT look the same in Windows displays of folders and files. Moreover, other weird things can happen to uninformed users.

In GW-BASIC it is possible to create a file with a name like "DUH"+CHR$(246) and one called "DUH"+CHR$(251). From within GW-BASIC, or while doing a SHELL, these two will appear as DUH with an appended division sign or a square root sign. In the wacky world of Windows, however, both of these names would be displayed as DUH_.BAS because any code from the 128-255 set will be shown as an underscore. Not only is this mind-boggling, such names would also look like one that really does have an underscore character in the same position. Now, since we all know you cannot have two names exactly alike in any one folder, this sort of nonsense can really blow your mind.

Another one is the oddity that may seem craziest of all: Files with names containing "invisible characters" from the 128-255 set CANNOT be deleted by Windows programs regardless of their attribute settings. If you get a Windows error 1026, suppose immediately that this is why. The easiest way to get rid of such junk is via DEL in DOS command mode or KILL from within GW-BASIC. If you do not know the exact character code in the offending position, simply substitute a question mark in the corresponding position during DEL or KILL. (Caveat: Use of wild cards will affect ALL files having similar names.)

As has always been true, upper and lower case letters in file names may or may not be significant. In DOS--thus also in GW-BASIC--lower case letters are treated as if they were in fact upper case. In fact, DOS always displays all letters as upper case, even if some are lower case in the disk directory itself. Windows, on the other hand, will normally display the truth, so to speak. Even so, even when it displays mixed upper and lower case letters as such it is fibbing just a little. Like DOS, Windows also treats all letters as upper case for all file-referencing purposes.

Suggestions: GW-BASIC programmers ought to use file names that only contain the characters A-Z or 0-9 and forego the weird ones. Additionally, always be alert to the fact that GW-BASIC will automatically append dot-BAS to any file name that does not specify an extension. This can be an especially mean stunt when you are inclined to use the same name for both a program and a data file. To keep me from hurting myself, my habit is to always specify extensions on data file names (such as dot-DAT, for example).

Lastly, remember that a GW-BASIC SAVE will save a program in its "tokenized" form. Although the option of adding a comma-A after a SAVE command will cause the same program to be written to disk as a text file, it too will have a dot-BAS extension unless you specify otherwise. Either can be re-loaded and run as a GW-BASIC program, of course, but Windows programs will be thoroughly confused by a file that was not saved as ASCII text. In the event you load a GW-BASIC program into a text editor such as Notepad and all you see is gibberish, chances are, you forgot do an ASCII save like, SAVE "myprog",A. Also, see Listing, and see that LIST ,"myprog" will automatically make the file an ASCII text file.

By and large, disk file processing in GW-BASIC on modern computers is much easier than it used to be. Today's computers are so fast we no longer have to worry so much about how long it will take to do something. Interpret my meaning as, less brain strain is needed to ensure our coding is as optimum as possible. An article that I wrote last April (2003) covers this notion in depth: "Low-Tech Data Processing".

Not covered there, however, are two problems that can arise in the Wonderful World of Windows that we never had to worry about on old DOS machines. One of them has to do with shared files. Or rather, NOT shared files would be a more apt expression. This symptom most often presents itself in GW-BASIC as an Error 70, "Permission denied." The solution is simple, by the way. In fact, according to this sage, if you practice one of my favorite tenets, this error will never occur: Never start a second copy of GWBASIC.EXE running. To do so is really living on the edge--the dangerous edge, that is.

DOS is a single-thread operating system. GW-BASIC was designed to run in that environment. Although OPEN for SHARE is possible, seldom is it ever a good idea. It was originally meant for "local area networks," i.e., two different operators on two different computers could perhaps share access to a common file. What that concept did not envision was, two different GW-BASIC programs running on the same computer, taking turns whacking at a common file. So, do not do it and life will be a lot simpler, and your system will be a lot safer.

By the way, another funny error that may crop up if you choose to ignore my advice is an Error 189, "Unprintable error." In a way, "unprintable" is amusing because it did just print it. As for the code 189, that is not documented anywhere that I know of. If you are feeling foolhardy you can probably provoke it in a second GW-BASIC program that tries to open a file already opened by another similar program using the same name and file number. Meanwhile, if you clobber your disk directories, don't call me names.

Other file processing anomalies can occur for no obvious reason because Windows is smarter than DOS. Routinely, when we PUT a record to disk it actually only goes to a buffer in memory. When all of the operating system's buffers are full, it will then write out the contents of old buffers to disk. Finally, when a CLOSE is done, any unwritten records are copied to disk, then disk directories and FAT sectors are updated. That is how DOS does it (sort of, anyway). Windows, on the other hand, may not update disk directories just because a GW-BASIC program said CLOSE. Rather than staying up half the night trying to figure out why file sizes are not right on successive opens of a given file, make it a habit to always do a RESET after a CLOSE. As has always been the case, RESET forces the operating system to purge all disk buffers and physically update the disk.

DOS calls them "directories", Windows calls them "folders". These two words are synonymous, really, when referring to directories, paths and trees. Any directory or folder may contain files. Under the File names heading herein are rules specific to naming files in a DOS or GW-BASIC environment. Those rules are essentially the same for naming directories or folders. (Only 8-character names are allowed, for example, with no spaces, only a limited number of special characters, and no dot-extensions.) Besides this "small folder names" problem, GW-BASIC users need to be cognizant of some specific aspects of running under Windows.

The "default" folder or path when running a GW-BASIC program is the one you were in when you launched GWBASIC.EXE. If you started the interpreter by itself, directly, the default location at that point is the same as the one where GWBASIC.EXE is stored.

If you started GWBASIC.EXE via a Windows shortcut, the default folder or path will be as specified in the properties for that shortcut.

If you start a GW-BASIC program by clicking on its BAS name, the default location at that point is the same as where the BAS file is stored. (Where the interpreter is stored matters not a whit in this case.)

The constant repetition above about "default location" may be critical to some applications. The GW-BASIC language includes commands like CHDIR, MKDIR, and RMDIR. Respectively, these work the same as the DOS equivalents, CD, MD and RD. Similarly, the GW-BASIC commands FILE, NAME, and KILL are counterparts to the DOS commands DIR, REN, and DEL. Most of the time most any GW-BASIC program will work correctly in a Windows world regarding all of this. For those who enjoy skating on the edge, however, maintain an awareness that GW-BASIC programs have the potential of doing some serious harm to files and folders. While you are thus engaged, Windows is fundamentally oblivious of what a GW-BASIC program is doing.

One other final warning is appropriate: When you finally exit GWBASIC.EXE (via the GW-BASIC command, SYSTEM) you ultimately return to the location you were at when you launched GW-BASIC operations. A (possible) difference that we are used to under DOS is, we exit into whatever directory a CHDIR might have sent us to. Because under Windows, when done with GW-BASIC operations you will always be back where you were before you went on vacation, old schemes that depended on BAT files for run-to-run linking may or may not work as they do under DOS. Ho hum, maybe, but a real migraine can ensue if you do run into this can of worms.