Contents of the 4DTECH01.DOC file
4DOS Technical Support Bulletin
Issue 1 -- April 19, 1990
This publication is issued from time to time by J.P. Software to
provide information to 4DOS users. We produce it because we
think it will help you solve for yourself some of the more common
problems we run into in answering technical support calls and
This issue covers a number of items that have come up as users
have installed the new release of version 3.0. Bugs or problems
referred to here will be fixed in our next maintenance release of
4DOS, numbered 3.01 and scheduled for release in early May. As a
result, after version 3.01 is out the comments below may no
longer be relevant.
The items are not listed in any particular order; just look
through at the headings to see what's of interest to you. You
may find that some of the descriptions below are too technical
for you, or do not seem to apply to your system or your use of
4DOS. If so, feel free to skip them. We've included plenty of
information here, and not all of it will be of interest to every
Because this document is primarily distributed electronically and
is most likely to be viewed on-screen, we have published it
without the usual page formatting. You will need a word
processor or page formatting program if you want to print it.
This document may be redistributed electronically or by other
means provided that no fee is charged, that the following
copyright notice is included, and that no modifications are made.
Copyright 1990, J.P. Software. All Rights Reserved. Published
by J.P. Software, Arlington, MA, USA.
You can reach J.P. Software at any of the following addresses:
CompuServe 75300,210; J.P. Software section of the PC
Vendor B forum (GO PCVENB)
BBS Future Technology, Boston, 617-720-4095
InterLink via the 4DOS Conference
PCRelay via the 4DOS Conference
Voice (617) 646-3975, days Eastern US time
Fax (617) 646-0904
US Mail J.P. Software
P.O. Box 1470
E. Arlington, MA 02174, USA
We have identified two problems with COPY in 4DOS 3.0. First,
when using COPY with the MS-DOS / PC-DOS APPEND command a
variety of problems can occur, and it is possible to
inadvertently truncate files. The problems occur when the
target file does not exist, and the source file is in a
directory that is on the APPEND path. Under these
circumstances, APPEND reports to 4DOS that the target file
DOES exist, but it really has found the source file. This
causes COPY to overwrite the source with the first part of
itself, then stop, leaving the source file truncated while the
new target file is never created.
The solution to this problem is to start APPEND with no path.
Then construct an alias or batch file to set the APPEND path
for a particular application, run the application, and delete
the APPEND path. Note that to modify the APPEND path you must
use the method described in the COMPAT.DOC file which comes
with 4DOS 3.0. For example, the following alias allows the
APPEND path to be modified after APPEND has been loaded:
alias append command /c append
Once this alias is in effect, the following alias might be
used to set the append path, run an application called MYAPP,
and then reset the APPEND path (this should all be entered on
alias myapp `append c:\myfiles;d:\others^
We will modify 4DOS in version 3.01 to avoid this problem. We
also generally do NOT recommend the use of APPEND, because (as
this problem demonstrates) it is too aggressive in searching
for files on the APPEND path even when the calling program
specifies an explicit path to use, and can cause a variety of
troubles for that reason.
The other problem with COPY is a minor bug in the /B switch
when concatenating files with the "+". For example, the
copy /b file1+file2 file3
will copy FILE1 in ASCII mode despite the /B, and will
therefore terminate the copy at the first ASCII EOF character
(^Z) in FILE1. FILE2 will be copied correctly. This bug will
be fixed in version 3.01; in the meantime, you can convince
4DOS to work properly by using a /b switch on the target file
as well as the source, for example:
copy /b file1+file2 file3 /b
Older PC BIOS Bug Causes Problems with LIST, SELECT, and CLS
We have identified a problem with 4DOS 3.0 which occurs only
with older IBM PCs. The problem appears when using LIST and
SELECT. In most cases neither command will work, and after
they are run many other commands will fail as well, and the
system will have to be rebooted.
This problem is due to a bug in the old IBM PC video BIOS (for
the technical types, the problem is that INT 10 does not
always preserve the BP register). In version 2.21 this BIOS
bug does not affect 4DOS; in version 3.0, it does. It will be
corrected by working around the bug in version 3.01.
There is a simple way to fix this problem if you have an older
IBM PC. If you have any machine other than an older "true-
blue" PC manufactured by IBM you do NOT need to install this
fix! If do have an older IBM PC and you want to find out
whether to install it, just try LIST or SELECT once; if it
fails as described, you need the fix.
To fix the problem, use a program such as PC Tools which
allows you to do editing of binary files (PC Tools 5 calls
this "hex edit"; other similar programs will use similar
names). Make a copy of 4DOS88.EXE for safekeeping, then
change it as shown below. If you don't see the proper
original values, don't make the change --instead figure out
why you are seeing the wrong values! Note that all sector and
byte numbers are decimal; all byte values are hexadecimal
(this is the way most binary file editors work):
* In sector 98, bytes 485 and 486 contain the values 8B
and E5 respectively. Change both bytes to contain the
value 90 (remember the byte values are hexadecimal).
* In sector 99, bytes 18 and 19 also contain the values
8B and E5 respectively. Change both bytes to contain
the value 90 (remember the byte values are hexadecimal).
* If you have an old PC with an accelerator card and are
therefore running 4DOS286, you must make the same exact
change, but at different locations. The first two bytes
to change are in sector 94, bytes 161 and 162; the next
two are in sector 94, bytes 206 and 207. The old and
new contents are the same as described above for 4DOS88.
* If you are using Norton Utilities to make this patch,
or any other utility that uses byte offsets instead of
sector numbers, here is the information you need:
4DOS88: First patch is at bytes 50661 and 50662;
second patch is at bytes 50706 and 50707.
4DOS286: First patch is at bytes 48289 and 48290;
second patch is at bytes 48334 and 48335.
Once the changes are made, save the file and reboot. LIST and
SELECT should start to work properly. If they don't, be sure
the changes were actually made and that you are rebooting with
the changed copy, then contact us.
Please DO NOT patch 4DOS then upload it to a BBS! We
absolutely do not want patched copies of 4DOS floating around
-- they cause all sorts of headaches, virus scares, etc. This
information is for YOUR use in fixing YOUR copy only!
DOS 4.01 FORMAT Command
When using the FORMAT /S command in DOS 4.01 to create a
bootable floppy disk, FORMAT copies the DOS hidden files to
the disk correctly. It then takes the file pointed to by
COMSPEC, which will usually be 4DOS.COM, copies it to the
floppy disk, and calls it COMMAND.COM! This will make the
floppy disk non-bootable, since 4DOS.COM will be on the disk
(called COMMAND.COM) but the 4DOS EXE file will not be there.
To correct this and create a standard bootable DOS floppy
disk, you must copy COMMAND.COM to the disk yourself when
using DOS 4.01 FORMAT with the /S option. For example:
format /s a:
copy c:\dos\command.com a:
Redirecting Output to NUL
A number of problems have cropped up with redirecting output
to NUL, for example in the command:
del *.dat > nul
which might be used to delete a group of files without
displaying any messages (in 4DOS 3.0 the del /q switch could
be used and would have the same effect).
The most common problem is the message 'Access denied "NUL"'.
This occurs due to an apparent bug in the SHARE command in MS-
DOS 4.x or Compaq DOS 3.31. If SHARE is loaded via an INSTALL
command in CONFIG.SYS it apparently tells 4DOS that NUL is a
file, not a device, and this confuses 4DOS. In all cases we
know of where this has occurred the problem has been solved by
installing SHARE automatically, rather than via INSTALL.
SHARE can be installed automatically by removing the INSTALL
command from CONFIG.SYS, and moving the SHARE program into the
root directory of the boot disk, or into the directory
specified for 4DOS.COM in the SHELL= command.
On systems with hard disk partitions over 32 MB, if you change
the way SHARE is installed and then see the message "Warning:
SHARE should be loaded for large media" when booting your
system, it means that the DOS boot program was not able to
find SHARE to load it automatically. In this case you should
correct the problem as your system may not work properly
without SHARE installed.
Some users have also reported that on their systems the
"Access denied NUL" problem can be created by redirecting
output to NUL when loading a memory-resident program (TSR); if
no TSR ever redirects its output to NUL the problem does not
occur. We have not verified this behavior.
Similar problems have been reported by a few users on some
networks, but the reports are sporadic and the problems are
While 4DOS's access to redirected and other output files is
perfectly correct, apparently SHARE and some other programs do
not always handle it correctly. In version 3.01 we will
modify the way 4DOS accesses output files to help get around
We have received several reports of problems with BRANDing
shareware copies of 4DOS version 3.0 to convert them to
registered copies using the BRAND utility distributed with
4DOS version 2.2 or 2.21.
As far as we can tell there are three possible reasons for the
1) Your copy of BRAND is outdated, i.e. you did not
purchase 4DOS including a free upgrade to version 3.0. If
you purchased a $35 copy of any version of 4DOS, or a $50
copy of version 2.0 (and hence have already received your
free upgrade to version 2.1 or 2.2/2.21), you do NOT have
another free upgrade coming.
2) You entered the wrong serial number when prompted by
BRAND. You must enter the serial number on your original
4DOS 2.1 or later registered disk, NOT the serial number in
the shareware copy of version 3.0 that you are branding.
3) Your copy of BRAND is not correctly coded for the
upgrade to version 3.0, even though you purchased the
Note that if you originally purchased 4DOS version 2.0 for
$50, i.e. including the "disk, manual, and next update", that
you will have a registered disk with BRAND on it, marked
version 2.2 or 2.21. That disk was your free update, and this
new version is not also free! This is not clear from the
installation instructions in README.DOC, which do not
differentiate between those who received registered copies of
2.1 or 2.2 as an upgrade, and those who received them as an
If after reading the above you believe that you are entitled
to a free upgrade to 3.0 but that BRAND isn't permitting you
to obtain one, please contact us to resolve the problem.
Odd Boot Problems, Missing Aliases, Garbage in Environment, Etc.
If you experience problems similar to those described in the
heading, check the length of the SHELL= line in CONFIG.SYS.
You may have added new options such as /A:nnnn or /U which
made the line too long. The limit on the length of this line
is due to a bug in all versions of DOS from 2.0 to 4.0. You
cannot have more than about 33 characters (the exact number
varies with DOS version) AFTER the name of the shell. For
example, this line is too long:
SHELL=C:\4DOS.COM /S:DI:\SWAP /E:2048U /U /A:2048 /P
35 characters -- too long!
If you are experiencing this problem, take the options on your
SHELL= line and put them in a file, say 4DOS.OPT (you can use
any file name you choose). In the above example this file
would contain one or more lines, for example:
/S:DI:\SWAP /E:2048U /U /A:2048 /P
Once you have this file set up, change the SHELL= line in
CONFIG.SYS to use it with the new @filename option, for
See the manual and README.DOC for more information on using
Location of 4START.BAT (or .BTM)
The manual does not clearly explain how 4DOS looks for 4START.
For the primary shell, 4START must be in the root directory of
the boot drive. For secondary shells, 4START must be in the
root directory of the drive COMSPEC points to. One result is
that if you have decided to speed up the loading of secondary
shells by moving copies of 4DOS.COM and 4DOS286.EXE to a RAM
disk and making COMSPEC point there, you must move 4START to
the root directory of the RAM disk or it will not be executed.
Aliases in Secondary Shells
The documentation does not clearly explain that aliases are
passed automatically to secondary shells which load in
swapping mode, but are NOT passed automatically to secondary
shells which load memory-resident. If you find that your
aliases seem to disappear when you start a secondary shell,
you should take three steps.
First, verify that your secondary shell is loading in memory-
resident mode. You can check this with the command:
If the value echoed is 99, the current shell is memory-
resident. Any other value indicates that the shell is in
Second, if the shell is memory-resident, decide if you really
want it to be. Check your COMSPEC and 4DSHELL environment
variables to be sure they are set to load the secondary shell
the way you want it (see pages 14 - 26 of the manual for more
Finally, if you are running a secondary shell in memory-
resident mode and plan to continue with that approach, you can
place the following command in 4START.BAT (or .BTM) to reload
the aliases only when necessary:
if "%_shell"=="99" alias /r c:\alist
This example assumes your aliases are in a file called
C:\ALIST; modify it if necessary for your particular
Additional IF Tests
We added so many features to version 3.0 that we forgot to
document a couple of them! There are IF tests for both file
size and disk free space. The tests are:
DISKFREE [condition] n[K | M]
tests free space on the current drive
FILESIZE filename [condition] n[K | M]
tests the size of the specified file
if filesize myfile.dat gt 360K echo It won't fit!
Reduced Swap Size
When possible, 4DOS will reduce the size of the swap area used
for secondary shells by retrieving some information from the
primary shell's swap area. Typically this reduces the
secondary shell swap area from about 70K (80K in EMS) to about
20K (32K in EMS). In order to obtain this reduced swap size,
two conditions must be met:
(1) The combined total of the alias, history, and
environment sizes for the secondary shell must be no larger
than that for the primary shell. These sizes are
controlled by the 4DSHELL environment variable, or the
options, if any, on the command line used to start the
secondary shell. Note that if necessary 4DOS will
automatically increase the alias and environment sizes to
ensure at least 128 bytes of free space in each area, so if
your alias or environment blocks are almost full the size
may be increased in the secondary shell even if you didn't
explicitly request a larger block.
(2) DOS memory must be the same size as it was when the
primary shell was loaded (e.g., 640K). Some programs can
reserve space at the end of DOS memory, effectively
reducing its size and thus prohibiting 4DOS from using a
reduced swap area.
If you are having trouble getting a reduced swap size when you
start a secondary shell, the quickest way to find the problem
is to print the output of the MEMORY command in the primary
shell (use MEMORY > PRN to do this), and then do the same in
the secondary shell. Compare the two printouts, looking for
either a reduction in the total RAM size (first line of
output), or an increase in the total size of history, aliases,
or environment. Any reduction in the total RAM size will be
due to the application you are running, and probably cannot be
corrected. Increases in history, aliases, or environment
sizes can be corrected by either decreasing the secondary
shell values or increasing the primary shell values (on the
SHELL= line in CONFIG.SYS) to eliminate the difference.
The size of 4DOS's swap area often cannot be reduced when the
secondary shell is started in a DESQView window. This is due
to the fact that DESQView takes the top 1K of DOS memory for
its own purposes, violating condition (2) above. You may be
able to get around this by increasing the history size in the
primary shell to at least 1K more than that used for secondary
shells, but the effectiveness of this technique will depend on
how the window is configured and what program is running in
We will consider modifying 4DOS to remove some of the
restrictions which prevent use of a reduced size swap area,
but this modification is complex and will not be introduced
until the next significant release of 4DOS.
The following minor bugs have cropped up in 4DOS 3.0. They
will all be fixed in 4DOS 3.01:
* You can occasionally hang the system by hitting ^C or
^Break at just the wrong moment while 4DOS is swapping
itself in from disk after an application exits.
* Using ".." as the source file specification for COPY
will not work if the current directory is one level
down, i.e. if ".." refers to the root directory.
* DIR's /F and /H switches cancel each other, and hence
cannot be used simultaneously.
* A ^C or ^Break can hang the system when 4DOS is
requesting input (e.g. via INPUT or INKEY) and LOG is
on. This problem may also crop up when you enter an
Abort response to the "Retry, Ignore, Fail, or Abort"
prompt and LOG is on.
* Using an IFF inside a GLOBAL command will cause GLOBAL
to quit doing useful work after the 15th directory
scanned, because 4DOS incorrectly detects that IFFs are
nested too deep.
* FOR variables cannot be prefaced with a double percent
sign if they appear inside double quotes in the command
after the "DO". Prefacing the variable with a single
percent sign, or using delimiters other than double
quotes, will get around the problem.
* DRAWBOX styles 3 and 4 do not work. They behave like
styles 1 and 2.
* When redirecting the output of GLOBAL, the redirection
will not work unless there are NO spaces around the
redirection characters. For example:
will work properly, whereas:
GLOBAL > NUL
The following corrections should be made to the documentation:
* UPDATE30.DOC and the manual show the minimum history
size as 512 bytes. The correct value is 256 bytes.
* In COMPAT.DOC the section on FASTOPEN refers to the RD
command where it should refer to REN.
* On page 42 of the manual, the last two arguments to
%@substr should be "start,len" not "start,end".
* The "command" should be optional in the SELECT syntax
shown in the usage message, the manual, and the HELP