Have a Question?

00617: Read.me file for PROGRESSION/4 rev 2.42


Read.me file for PROGRESSION/4 rev 2.42


                           Note to Readers 

This file contains information on the new features and bug fixes for BBxPROGRESSION/4, REV 2.3 through REV 2.42. Enhancements and features added to REV 2.2 and earlier releases can be found in the errata.doc file that comes with this product. 


BBxPROGRESSION/4 REV 2.3 through REV 2.42 
README file 
October 7, 1996 

The following items are discussed in this README file: 


NEW FOR REV 2.42 for Windows 
1. SYSPRINT Enhancements 

2. Improved NetWare support 
3. No more Novell User Map 
4. Access Novell print queues without a capture 

5. Font Selection under MS-Windows 
6. Multiple Workstation Environments 
7. New Printer Capabilities under MS-Windows 


1. General 
2. UNIX 
3. Novell versions 
4. MS-DOS 386 
5. Microsoft Windows 



Each time the SYSPRINT device is opened, a list of all fonts and sizes which will perform well with the selected printer is placed in FIN(chan,IND=2). The template for this data is returned using the function TMPL(chan,IND=2). Only fonts which are fixed width and not italicized or strikeout are considered. 

FIN(chan,IND=1) on a SYSPRINT channel now returns the physical pixel counts on the device for the offset to printing area; printer physical pixel width and height; font width and height; and the printing area width and height along with the current selected font face name. The template for this data is returned in TMPL(chan,IND=1). The template currently has this format: 


xres is the number of printable pixels (or dots) available horizontally on the print page. This value will be smaller than yres if the page is portrait. It will be larger if the page is landscape. This value does not include any unprintable areas defined by the printer or print driver. It is in printer units. 

yres is the number of printable pixels (or dots) available vertically on the page. This value does not include any unprintable areas defined by the printer or print driver. It is in printer units. 

xppi is the number of pixels (or dots) per inch on the horizontal as defined by the printer for the page. 

yppi is the number of pixels (or dots) per inch on the vertical as defined by the printer for the page. 

xoffset is the value returned by the print driver for the unprintable area of page. This value is for the horizontal dimension and specifies the printer units on either side of the page that are not printable. 

yoffset is the value returned by the print driver for the unprintable area of page. This value is for the vertical dimension and specifies the printer units on either side of the page that are not printable. 

pwidth and pheight are similar to xres and yres but include the unprintable areas of the page. You can compute the dimensions of the page in inches if you divide these values by xppi and yppi, respectively. 

char_width and char_height are the current values being used by the interpreter for computing character and line spacing, respectively. These values are based on either the last font selected using the ‘FONT’ mnemonic or on the values of COLS and ROWS/LINES given on the alias line. If COLS and ROWS/LINES were not used but SPCOLS, SPLINES, EPCOLS, EPLINES, CPCOLS, and CPLINES were used instead, then the char_width and char_height is computed based on the fonts selected for these modes and the values reported will depend on what mode was selected by the software before retrieving the FIN() information. 

pagepos is the current line position on the page that will be used for the next printed output. The is a zero based value, with zero being the top margin of the page. 

tmargin and lmargin specify the top and left margins, respectively, for the first line of the page. If no top or left margin is specified, they default to the unprintable area reported by the Windows printer driver. These values are in device coordinates. 

font is the current font being used for printing. 

The FONT= SYSPRINT mode has been reworked. FONT=SYSTEM and FONT=DEVICE are obsolete. FONT=<fontname> is now used, and any font valid for the device (such as those enumerated in FIN(chan,ind=2)) may be used. 

        ALIAS LP SYSPRINT “printer” dialog,font=”Courier New” 

This forces a particular font to be used, and the number of available columns and rows is determined by the page size available to the Windows driver. 

A ‘FONT’ mnemonic has been added to the SYSPRINT device so that any valid font may be selected at any time after opening the device, by using the following syntax. 


The appropriate font from the font family in <fontname> will be selected. If <cpi> (characters per inch) and <points> are given, new print columns and rows will be computed to match the <cpi> width and <point> (72 points per inch) height. If the <cpi> and <points> are not specified, an attempt is made to map the font to the current cols and rows selected. 

Four new modes have been added to provide additional control over the SYSPRINT device: COLS=<val>, ROWS/LINES=<val>, TMARGIN=<val>, and LMARGIN=<val>. 

COLS and ROWS/LINES set the CP and SP values both at the same time. Most programs really only want one size or another, and forcing the system to choose two fonts when one would do can cause the interpreter to resort to slower TrueType fonts, even when a faster device font is available. Example: 

ALIAS LP SYSPRINT “printer” dialog,cols=80,rows=66 

If COLS= and ROWS= are specified, and FONT= is not, the number of columns and rows will definitely match the number requested, and the interpreter will use the best available device font to fit, given the page area available from the driver. If no font can be found to provide the requested number of columns and rows, an !ERROR=1 is returned on the OPEN. 

If COLS=, ROWS=, and FONT= are specified, the interpreter will attempt to find the closest match to all three parameters, without guaranteeing that any of them will match the requested values. 

TMARGIN and LMARGIN specify the top and left margins of the page. This is where the first line of the page will begin. 

Three new mnemonics have been added to help software control the printed output: ‘TMARGIN'(val), ‘LMARGIN'(val) and ‘ENDSPOOL’. 

‘TMARGIN’ and ‘LMARGIN’ take a decimal value in inches which specify the starting position of the first line on the page. Do not use these mnemonics except at the start of a given page as they adjust the page position at the time they are encountered. 

‘ENDSPOOL’ takes no parameters and forces a Windows print job without software having to do a CLOSE(chan). The advantage is that the print job which does alignment first does not have to reset the printer after alignment parameters are adjusted correctly which a CLOSE(chan) forces software to do. 



BBxPROGRESSION/4 REV 2.4 was developed specifically to run with full support for Novell NetWare versions 4.1 and 3.12. All BBx products benefit from the improved NetWare support, but BBxPROGRESSION/4 for Windows in particular has the ability to access Novell’s new NetWare Directory Services (NDS) database. 

When Novell made the move from NetWare 3 to NetWare 4, they replaced the “bindery” database, which was local to each server, with a new “Directory Services” database, global in scope. This had a profound effect on BBx because BBx relied on the bindery for its license control information, data for the INFO() function, and the ability to locate remote print queues. Novell’s “Bindery Emulation” in NetWare 4 did not behave similarly enough, confusing BBx into erroneously reporting startup errors, attempting to contact servers that did not exist, etc. 

With REV 2.4 we have made several changes to accommodate Novell’s new approach to network computing. 

        1. We no longer maintain a user map (this is discussed later). 

        2. We refer to the bindery only for data required by the INFO() function and for accessing print queues. 

        3. Where practical, we use Directory Services in lieu of the bindery for the items listed in #2 above. 

This means that all versions of BBx for Novell NetWare will start faster, and run hassle-free in a NetWare 4 environment. In the case of the Windows version, we were able to build in support for Directory Services directly, meaning that if certain conditions are met, you may disable bindery emulation altogether if you prefer. 

In order for the new Directory Services support to work properly, a few things must be true of the operating environment. 

        1. You must use BBxPROGRESSION/4 REV 2.4 for Windows. 

        2. The BBx executable must be installed on a NetWare 4.1 server. 

        3. A set of NetWare drivers must be installed at the workstation which are able to access NDS. 

        Notes: Novell’s 16-bit VLM drivers will work with Windows 3.1, Windows For Workgroups, and Windows 95. The stock Windows 95 drivers do not have NDS capability. Both Novell and Microsoft have released 32-bit NDS-aware drivers for         Windows 95, but all of these have bugs which can be proven to cause file corruption. BASIS is cooperating with Novell and Microsoft to try to resolve these issues. In the meantime, we are forced to recommend that you use the VLM         drivers with Windows 95. 

        4. A drive must be mapped to SYS:PUBLIC. This is normally the case when a workstation is logged in. 

If these conditions are met, BBx4 for Windows will automatically start up with full support for NDS and zero reliance on the bindery. If bindery emulation is not required by other applications, it may be turned off by issuing this command at the NetWare 4.1 console. 


(The equal sign is the last character in the command line.) You may only turn off bindery emulation if you do not require any access to the bindery. Be sure to check all of your applications. Note: Microsoft’s stock Windows 95 NetWare drivers do not offer NDS support and therefore can only log in via the bindery. 

The BBxPROGRESSION/4 INFO(3,2) and INFO(3,3) functions retrieve information either from the bindery or from Directory services, depending on the server environment. The bindery traditionally converted all information to upper case before returning it, so with NDS support you may see lower case values in the aforementioned INFO functions. 

NSPOOL alias lines also use either the bindery or Directory Services to locate a print queue. With Directory Services, print queues are no longer associated with a particular server, but rather with a “Tree”. All print queues in the current “Preferred Tree” may be located directly by their name, and it is no longer necessary to specify the server that holds them, nor is it necessary to provide a login or password in order to attach. Directory Services takes care of all of 
that. Print queues outside the “Preferred Tree” may be accessed only by specifying the verbose Directory Services name for them, e.g. CN=HP_LASER.O=BASIS. (See New Features item #4 for more new features of NSPOOL.) 

Note for Windows 95 users 

The stock NetWare drivers that ship with Windows 95 do not offer NDS support. They have also been known to cause failures with print spooling. You may choose to use the stock drivers if you do not require access to remote print queues and you do not require Directory Services support. Our DOS executables will work with no further effort in this scenario. Our Windows executables will work provided that you obtain a copy of the NWCALLS.DLL file from a Windows workstation with Novell’s VLM drivers installed. Copy it into the WINDOWS\SYSTEM directory of each Windows 95 workstation which will use BBx. 

If you require full NDS support from Windows 95, you should use Novell’s “Client 32” drivers. We recommend that you do not use Microsoft’s NDS Client drivers as they do not work as reliably as Novell’s “Client 32” drivers. 

Note for Windows 3.1 and VLM users 

If you’re using Novell’s VLM drivers, you should be aware that your “Preferred Tree” is affected by how you log in. The “Preferred Tree” determines which print queues may be located by their names alone, without a verbose Directory Services path. 

If you log in from DOS and then start Windows, your Preferred Tree is normally set to the default for your server, which will almost always mean that you can locate your print queues by name. If you start Windows first, and then log in with Novell’s User Tools, your Preferred Tree is left at “[Root]” and you’ll only be able to access print queues by their verbose names. 

Where practical, the most foolproof approach is to use verbose names in the NSPOOL alias, but this is not safe unless all workstations requiring that printer use NDS. 



As of REV 2.4, BBxPROGRESSION/4 no longer uses a “user map” to track license usage in the NetWare bindery. This was necessary for full support of both the NetWare 3.12 and NetWare 4.1 environments. 

Generally, the only consequence to the user is that the INSTALL program no longer contains options for “CLEAR USER MAP” and “DEACTIVATE”, and that it is now possible to simply move the executables to a new server without deactivating. It is no longer possible to receive an !ERROR=70 on startup. 

BBx also no longer searches the network for other installations of the same serial number, so it should start up faster. In wide-area networks or installations with unresponsive servers, this will mean BBx starts up much faster. 

For the most part, these changes make REV 2.4 the most convenient Novell-aware BBx ever. There are some side effects of this change that you should be aware of, however. 

        1. Multiple licenses can clash. 

        If you have more than one license for the same BASIS product         installed on the same network, it may be necessary to consolidate all of your users into a single serial number, to avoid erroneous !ERROR=0 reports. With the loss of the user map in the bindery, we lost the ability to track multiple licenses flexibly. 

        2. INFO(2,x) functions return different values. 

        Since there is no more user map, there are no more user slots. That means the INFO(2,x) functions can no longer provide information about those user slots. In particular, INFO(2,4) no longer returns a unique number, associated with a given user slot. 

        3. The -u startup flag is now defunct. 

        With no user slots, there is no longer any need to assign a user slot with the -u flag. 



A new mode has been added to the NSPOOL alias. If MODE=DIRECT is specified on the open or “DIRECT” is listed in the modes field of the alias line, any LOCAL= mode is ignored, and no capture is performed. Instead, the open channel is associated *directly* with the print queue. The LPT ports remain unaffected. 

This not only allows more than three remote print queues to be opened simultaneously, it prevents BBx from remapping the LPT ports needlessly. Under Windows, this is especially helpful since other applications may require that the LPT ports remain as they were set in the Control Panel. 

The new behavior will not become active until the DIRECT mode is added to the alias lines. By default, NSPOOL still performs a capture. It is expected that most users will prefer to switch to the DIRECT mode. 

(See special note on this feature in the “MS-DOS 386” section under “Bug Fixes and Other Improvements”.) 



All REV 2.21 and newer releases of BBxPROGRESSION/4 for the Windows operating system employ an improved Fonts/Size dialog box, which permits the use of any fixed-pitch fonts installed on the machine. To use, simply choose Fonts/Size… from the Settings menu on the terminal window. The controls for selecting the font size will change depending on whether the font is scalable (TrueType) or merely available in specific sizes. 

The diskette labeled “BBX Fonts” contains fixed point fonts that can be used with all BBxPROGRESSION/4 for Windows products. These are screen fonts only, and cannot be used for printing. The fonts come in several sizes and also use the PC-8 character set. This is a benefit if your application uses the high-order characters from the PC-8 character set such as certain line drawing characters and international characters. 

To install the fonts, follow these instructions (If you are on a network, you will need to install the fonts at each workstation.): 

1. Start the Windows Control Panel and click on the Fonts icon. 

2. In the Fonts dialog, select Add. 

The Add Fonts dialog will appear. 

3. Insert the BBX Fonts diskette in drive A: (or drive B:) and select drive A: (or drive B:) from the Drives list box. 

The four font files below will display in the Fonts window: 

BBX350.FON EGA 640 x 350 Resolution 
BBX480.FON VGA 640 x 480 Resolution 
BBX600.FON SVGA 800 x 600 Resolution 
BBX768.FON SVGA 1024 x 768 Resolution 

4. Select the font file for the screen resolution you are using and click on OK. (If you are not sure which files to install, click on Select All.) 

The fonts will be copied into the Windows directory and samples of the sizes available will be displayed in the Sample box. The message, “This is a screen or plotter font.” will be displayed below the Sample box. 

5. When the fonts are installed, click on the Close button. 

You are now ready to use the new fonts in your application. 



In the multi-workstation version of BBxPROGRESSION/4 for Windows, multiple workstations running the same copy of BBx from a shared drive will all use the same BBX4.INI. This can lead to potential conflicts when multiple workstations execute BBx with similar environment settings. 

In order to preserve each user’s unique settings, we recommend adding the -aAPPLICATIONNAME and -nUSERNAME command-line parameters to each icon. This will ensure that the individual’s preferences, such as the current size and location of the terminal windows, font type and size, and the color map assignments will not be overwritten inadvertently. 



REV 2.3 has an enhanced SYSPRINT printer interface. The SYSPRINT device is an interface into the Windows printer system, rather than an interface to an actual device, such as /dev/lpt1, which most BBx users on DOS have used. The enhancement involves a new mode that allows two different behaviors to be selected. This new mode and the concepts underlying the SYSPRINT device are described in this section. 

The SYSPRINT device communicates to the physical device by means of a Windows device driver, supplied by the printer manufacturer. This driver is aware of the built-in fonts on the printer and any other printer-resident fonts, such as cartridge fonts or downloadable fonts that the user has set up in the Windows Print Manager. These fonts are referred to as “resident fonts.” The device driver is also aware of “non-resident” fonts, such as the TrueType fonts that come with Windows. 

The primary difference between resident fonts and non-resident fonts is how much work Windows does in generating the printed page. When non-resident fonts are used, Windows draws the image of the printed page and sends the image to the printer. When resident fonts are used, Windows sends a command to the printer to activate the font and transmits the stream of character codes that the printer uses to generate the image. Thus use of resident fonts will normally be considerably faster and result in a crisper appearance than use of non-resident fonts. 

In addition to the fonts themselves, the driver is also aware of other physical characteristics of the printer, including the page size and the area where printing can appear on a page. Some printers allow printing from one edge to the other, while others have minimum margins. The area where printing can appear on a page is called the “printable” area. When the user selects a SYSPRINT device, BBx attempts to match the number of printable columns and rows required with a fixed pitch font that best fits in the printable area. Since the printable area and the fonts differ from printer to printer, the same requirements on different printers may result in different fonts being selected. 

In previous releases of BBxPROGRESSION/4 for Windows, BBx picked non- resident fixed pitch fonts that met or exceeded the requirements of 80 columns by 66 lines within the printable area on the page. (For compressed print 132 columns by 66 lines were required.) The enhanced SYSPRINT interface allows the user to tell BBx to find a resident fixed pitch font, if possible, to fit the user’s requirements for printable rows and columns. This allows greater print speed and more user control over the font that is ultimately selected. 

See also the minor improvements listed under “Microsoft Windows”, later in this document. 





* REV 2.4 

Improved reporting of errors when BBx encounters a corrupted data file. 

The DAY variable has been fixed to prepare for the year 2000. 

* REV 2.3 

The INPUTN verb was fixed to handle transposition of commas and periods correctly in all cases. 


2. UNIX 

* REV 2.4 

Certain error conditions could cause the Data Server to consume socket resources. This has been fixed. 

If the Data Server is used to RENAME a file, and the second file already exists, BBx now reports the error correctly. To get the right error code, both the Data Server and the client BBx must be REV 2.4. 

* REV 2.3 

It used to be possible (though very rare) to kill a BBx process at just the wrong moment, and have other BBx processes lose access to user slots. This has now been rendered completely impossible on properly functioning systems. 

We fixed a problem with SELECT verb which could cause records to be erroneously discarded if: 
        – the WHERE clause corresponded to a key chain 
         (thus enabling REV 2.2 WHERE optimization), 
        – a delay was introduced between READ RECORD statements. 



The fixes and enhancements listed in this section apply equally to all versions of BBx which offer Novell NetWare support. 

* REV 2.4 

When MODE=BANNER is specified with an NSPOOL printing device, the documented behavior is that the banner displayed will read “LST:”. However, the banner was blank in this case. It now reads “LST:” to match the documentation. 

BBx will now retry (up to ten seconds) on a failed unlock attempt. This is to work around a problem wherein some NetWare drivers do not attempt to retry on a failed unlock. 

Three new INFO subfunctions have been added. 

        INFO(3,100)         name of server from which BBx was invoked, 
                          or the empty string if none. 

        INFO(3,101)         volume or drive from which BBx was invoked, 
                          without the final colon. 

        INFO(3,102)         full path of BBx executable, minus any 
                          server or volume information. 


4. MS-DOS 386 

* REV 2.4 

A condition causing TCB(10) to occasionally contain the wrong value (on Novell platforms only) has been corrected. 

Ctrl-Break issued while in a system call no longer causes a crash. 

If the full name of an executable is specified in a system call (“bbx4.exe”, not just “bbx4”), BBx will now execute it directly instead of invoking it through command.com. This prevents command.com from discarding the error status returned by the executable, so better information is available from the SCALL() function. 

A condition which could cause a GPF (on Novell platforms only) has been fixed. 

The new captureless NSPOOL feature relies on older NETX calls which don’t appear to be working in all NetWare drivers. So far as we have been able to determine, this feature works when the 386 DOS BBx is running in a “DOS Prompt” window under Windows and Windows 95, but not when it is running directly under MS-DOS. Of course, this depends on 
which drivers are in use. 

Due to a bug in Novell’s “Client 32” driver for Windows 95, advisory locking will not work with that driver. The problem has been reported to Novell. (Note that this applies to 386 DOS BBx only. The other BBx/Novell products use different means to perform locking.) 


5. Microsoft Windows 

* REV 2.42 

!ERROR=60 report for missing files was occurring on peer to peer networks with some machines. This was due to Window’s reporting failure without giving a reason for the failure. The problem was timing related. Release 2.42 now correctly generates an !ERROR=12 when it detects this situation. 

* REV 2.4 

A problem has been fixed wherein canceling a print dialog caused an !ERROR=60 to be reported. 

The SYSPRINT device now counts the lines displayed in ‘EP’ mode correctly, whether the characters are single-height or double-height. 

The SAVE verb now always creates a file of the correct size for saving the program. 

A problem causing occasional erroneous !ERROR=0 reports on Novell networks has been fixed. 

* REV 2.3 

The DOSWAIT printer mode now works as it has under MS-DOS. 

The Multi-Workstation Windows For Workgroups version of BBx now uses an improved license checking mechanism to prevent erroneous !ERROR=0 reports. Also, the WFW version now behaves as a single workstation version if started on a machine with no network installed. 

A new SYSPRINT mode has been added: FILE=outputfile. This hooks in with Windows’s print-to-file capability. The document prints normally, with the exception that all data that would normally go to the printer is redirected to the file of your choice. This is very handy for diagnostic purposes. 

The SYSPRINT device now responds to the print quality selection in the setup dialog. Draft mode now implies faster printing in most cases. 

The Copies prompt in the Print… dialog is now disabled unless the driver really has intrinsic support for printing multiple copies. 

                           (END OF README) 

Last Modified: 12/24/1997 Product: BBxPROGRESSION/4

BASIS structures five components of their technology into the BBx Generations.

Table of Contents
Scroll to Top