Novell's DOS 7 offers multitasking, memory management, and peer-to-peer networking. Is it a better DOS than Microsoft's?
Terje Mathisen
Novell and Microsoft have been sharing our desktop machines for almost a decade. Microsoft supplied the operating system (MS-DOS), while Novell delivered the file and print servers for the same PCs. Then Microsoft went after a bigger share of the networking business, while Novell bought Digital Research and its DOS-compatible operating system.
Novell DOS 7 (ND7) is targeted at existing MS-DOS installations and is intended as a direct replacement for MS-DOS 6.2. ND7 bills itself as a better DOS than MS-DOS, mainly on the strength of a multitasking kernel, better memory management, improved utilities, and a built-in copy of Personal NetWare, Novell's peer-to-peer network operating system
. (Of course, however, if Novell really wanted to challenge Microsoft, it could bundle ND7 with NetWare, giving large corporations a single vendor for both PC and server operating systems.) The universal NetWare client software included in the package supports all NetWare servers from version 2.x to 4.0, on almost every network card anyone could want.
The Parts
ND7 consists of three main parts--DOS, Universal NetWare Client, and Personal NetWare--plus a volley of bundled third-party utilities. Its multitasking kernel makes low-overhead DOS multitasking available; the only thing that's needed is TASKMGR.EXE, which uses a scant 3 to 4 KB.
On both 286 and 386 machines, ND7 can use DPMS (DOS Protected Mode Services) to run compliant drivers fully or partly in protected mode. ND7 comes with DPMS versions of disk cache, disk compression, and CD-ROM drivers. The disk cache (NWCACHE) is licensed from Golden Bow systems, while the disk compression is a version of Stac Electronics' Stacker. When you in
stall ND7, Stacker can convert AddStor's SuperStor and Microsoft's DoubleSpace drives on the fly. Stacker's Restack option gives you improved file-compression ratios.
ND7 is bundled with Fastback Express, from Fifth Generation Systems. Both DOS and Windows versions are included. Fifth Generation also supplies the bundled Search & Destroy antivirus package for DOS and Windows.
Installation
I installed ND7 on my main test PC (a Compaq EISA Pentium with 1.5 GB of disk space, 40 MB of RAM, a 21-inch Salora/Nokia low-emission monitor, and an NEC 3X CD-ROM drive). As part of the installation process, ND7 saves away all the necessary information, to make it possible to uninstall later. That's a good idea, but it's where the first problem surfaced.
I use the Norton Utilities NDOS COMMAND.COM replacement. All the current system files are renamed and made read-only and hidden as part of the DOS 7 installation. ND7's installation will also parse the existing CONFIG.SYS file for a SHELL= line and
do the same rename operation on whatever file happens to be named there. This would have worked, except that the installation script got too fancy. If SHELL= in CONFIG.SYS points at a replacement for COMMAND.COM, the line is not modified, even though the file itself has been renamed and hidden. When the installation program finished and I was told to reboot to start ND7, I ended up with the error message: Bad or missing command interpreter; Please enter a valid filename. I was able to start the system by entering C:\COMMAND.COM, but this is an embarrassing bug for Novell.
Later, to test ND7's Personal NetWare functionality, I used an IBM Model P75 portable. This PC had MS-DOS 5.0 and QEMM 6 installed. When I tried to run A:INSTALL, it started by copying a couple of setup files to drive C and then promptly hung, without any error messages. After rebooting, I simplified my CONFIG.SYS and AUTOEXEC.BAT files as much as possible, loading only HIMEM.SYS and the Norwegian keyboard driver. I still got the sam
e error.
So I then tried to boot directly off the ND7 installation disk. When I did, however, I got a very interesting error message: BETA DEBUG: TCXL Error. This looked very much like beta-test code that was left inside the shipping product. It must have been triggered by a bug never expected by the developers and not caught during the beta cycle.
I finally did what I should have done before starting: I read the readme file on the installation disk. The file had a special section about how some portable machines were incompatible with the default enhanced-text mode used by SETUP (and several of the bundled programs). To fix my problem, I could use SETUP /N to run in regular text mode, or, to solve it permanently, I could insert NewUI=OFF in SETUP.INI--which is what I did.
Disk Compression
I have an old 20-MHz 386 Toshiba 5200 portable machine, which has its 100-MB hard drive split into two partitions. This machine used DoubleSpace to compress drive D and claimed 10 MB of free disk s
pace. When I installed ND7, DoubleSpace was still autoloaded by the ND7 kernel to support the compressed drive D. I then restarted SETUP, and it offered to convert my DoubleSpace drives to Stacker drives. After about 30 seconds, the system informed me that I didn't "have enough room on drive F to convert all the volumes on it" and that I had to free at least 514,048 bytes by removing files or resizing the DoubleSpace drive.
After restarting the PC, I tried to resize the DoubleSpace drives by running the MS-DOS 6.2 command DBLSPACE /SIZE /RESERVE=514048, whereupon I was told that both the minimum and maximum size of the drive was 67 MB. I then ran DBLSPACE /DEFRAGMENT to pack all the data into the first part of the compressed drive, which would make it possible to resize it. DoubleSpace finished defragmenting the disk after nearly 2 hours, and I then ran DBLSPACE /SIZE again (which took another 15 to 30 minutes).
Finally, I restarted ND7's DoubleSpace-to-Stacker conversion process. Almost immedi
ately, another serious bug surfaced: Stacker refused to perform the conversion process because it could not locate the DOS system files IBMBIO.COM and IBMDOS.COM. MS-DOS 6.2 uses the generic Microsoft names for these files, IO.SYS and MSDOS.SYS, so the IBM version of the filenames could not be found.
To solve this problem, I copied the MS-DOS system files, changing the names to the IBM standard to satisfy Stacker. By using the /H (hidden) option to ND7's XCOPY, I could copy these files without having to remove the ReadOnly, Hidden, and System attributes from them first. Finally, on the fourth attempt, Stacker accepted the drive for conversion. The actual conversion process took all of 11 seconds, after hours of preparation.
Compatibility
By far the most important criterion for an alternative DOS is compatibility. Novell's Desktop Operating System group has done a very good job of polishing up DOS, but there are still a few dings and dents. The first thing I noticed missing was the built-in T
RUENAME operation in COMMAND.COM, which has been a documented part of MS-DOS since version 5.0. This command will take any filename or path name and return a canonical version of it. For example, if \BC4\BIN is the current directory on drive D, TRUENAME D: will return D:\BC4\BIN\.
I wrote a test program to see if the supporting DOS API call was available, and it worked, both on local and networked drives. This program, TRUENAME.COM, is just 96 bytes and is available for other ND7 users to download. When I tried TRUENAME.COM on my CD-ROM, TRUENAME E: returned Cdex.E:\. This is a serious bug, since many popular programs use this API to parse path names. Most of them will likely choke on the nonstandard return value.
I found another small problem with the CD-ROM: My test machine uses an Adaptec 1740 EISA adapter to support the second hard drive (a 1-GB Hewlett-Packard SCSI-2 drive) and the CD-ROM drive. The Adaptec CD-ROM support software was installed under MS-DOS 6.2 and has worked very well wit
h that version. With ND7, the second of the two drivers gives an error message, "Cannot locate SCSI Manager," but it still loads, and the CD-ROM seems to work just like before.
ND7 apparently emulates the (partly) undocumented internal DOS structures very well, masquerading as MS-DOS 6.x. The emulation is good enough that Microsoft Diagnostic (MSD.EXE) is fooled, but some of the information shown in MSD, particularly the UMB (Upper Memory Block) display, is obviously wrong. This suggests that ND7 uses a different scheme to manage these blocks, but the UMB APIs work well enough that a program I wrote a couple of years ago that relocates itself into a UMB worked perfectly without any modifications.
Windows Compatibility
When I first installed ND7, I had Windows for Workgroups 3.11 installed on my PC--not because of the peer-to-peer networking functions (which I don't use), but because WFW has better performance than Windows 3.1, particularly due to 32-bit file and disk access. ND7 did not comp
lain about running WFW, and everything seemed to work OK as long as I was using Windows programs or working on a local drive.
After a couple of hours, I needed to update an old Pascal program, so I started Borland's Turbo Pascal (BP7) inside a DOS box. The source code was in my default directory on a NetWare 4.01 server. It loaded fine, and it found all the files I had been working on last. I made a few changes and pressed the F9 key to rebuild the program. At this point, BP7 complained about not finding any files.
After snooping around, I found that the problem is located in the Get and Set Current Directory functions (INT 21, functions 47h and 3Bh). With WFW loaded, I consistently ended up at the root of the network drive (I:\) instead of at my source directory (I:\BP\SRC). When I reinstalled Windows 3.1 instead of WFW, the problems disappeared.
To test Win32s compatibility, I installed the Win32s support code, which consists mostly of VxDs (virtual device drivers). This code ran wit
hout a glitch, and all the demonstration programs from the Windows NT SDK (Software Development Kit) CD-ROM that I tried ran without any problems.
The only consistent problem I found in the Windows 3.1 support was with a few utility programs written in Borland Pascal and quickly converted to run inside Windows by using Borland's WinCRT unit. These programs run well under Windows 3.1, WFW, and NT, but after ND7 is installed, the system complains about a General Protection Fault and aborts the program. I have a suspicion that this might be related to the DPMI (DOS Protected Mode Interface) support in ND7, since I get exactly the same error messages when I try to run these programs under OS/2 2.1.
Personal NetWare
The last component of the ND7 package is a bundled copy of Novell's peer-to-peer network product, Personal NetWare. To use it, at least one PC must be designated as a server and make some of its resources available for sharing on the network. PCs that act only as clients can use the
Universal Client to access both NetWare servers and Personal NetWare servers.
I first installed Personal NetWare on the 20-MHz 386 Toshiba portable. This almost worked, except that the SETUP program modified my existing (working) NET.CFG configuration file and substituted the default parameters for my network card. When I next rebooted, the adapter driver declined to load. I had to locate the problem manually, edit the NET.CFG entries back to the proper values, and reboot. It is a good idea to make a copy of your NET.CFG before you let ND7 mess around with it.
Personal NetWare comes with Novell's new Universal Client software, based on the VLM (virtual loadable module) technology developed for Novell's high-end NetWare 4.01. With a single installation, the new VLM driver set lets a PC access both Personal NetWare servers and all the versions of dedicated NetWare servers (from 2.2 to 4.01), and it uses less low memory than the old-style NETX driver.
I have measured extremely high performan
ce on both Ethernet and 16-Mb Token Ring using these drivers to access a NetWare 4.01 server--1.03-MBps sustained throughput for a single connection doing large reads on Ethernet and 1.76-MBps on Token Ring--so I was curious about the performance offered by Personal NetWare. The network software's performance was adequate, but it was a large step below what you can get from a dedicated NetWare 3.11 or 4.01 server. The "File-Read Performance" table on page 242 gives you some idea of what I found.
For a small workgroup like the one in my home, the most critical criterion is how much the foreground task on a peer server is affected by background activity. When my son Fredrik wanted to play Lemmings 2 on the 25-MHz 486, I started the game for him and then started to copy big files to and from the 486. The little animated lemmings in the game just kept moving, without any delays or stutters.
Multitasking
Task-switching support is built in, starting with a multitasking kernel that supports programs
written for the old Multiuser DR DOS. The memory manager, EMM386.EXE, also supports multitasking, with a MULTI option on the command line. According to the manual, this even makes it possible to multitask protected-mode DOS programs.
To test this capability, I loaded the Borland Pascal environment in one session and then used the protected-mode version of Turbo Assembler, TASMX, to assemble a program in another session. This immediately blew up, giving me a full-screen version of the infamous General Protection Fault message. I shouldn't have expected anything else, really, since the same thing happens in a Windows DOS machine and under OS/2 2.1. I was able to successfully run Borland C++ 3.1, which uses another non-DPMI-compliant DOS extender. This program does not run under OS/2, but it worked OK with TASKMGR.
TASKMGR works like Windows Enhanced Mode or OS/2 by creating V86 (virtual 8086) machines, giving each session the illusion that it has its own CPU. This means that TASK-MGR, in coopera
tion with EMM386, must act as the V86 monitor, intercepting all hardware interrupts in protected mode and redirecting them to the current DOS program, which then handles them as if in real mode.
In theory, this should all work well, but since the redirection uses quite a few cycles, it can mess up time-critical operations. In OS/2 and Windows, this particular problem is fixed by writing protected-mode handlers for things like keyboard, mouse, and serial communications. These drivers then virtualize the hardware on behalf of the DOS programs, fooling them into believing that they have direct hardware access.
On my hardware, the mouse worked perfectly well in multiple loaded programs. Communication was another matter, however: I had to step down to 19.2 Kbps to keep a file transfer running in the background, and the effective baud rate dropped to about 1.4 Kbps.
I use my machines mainly for software development, working in a DOS environment. I liked ND7's approach to multitasking since it
made it easy for me to start a new session at any time to test out a new program or look up an on-line reference.
The DOS Dilemma
ND7 is an impressive package that could have used a more thorough beta testing before release. Most of the problems I found were minor, but they could have been eliminated completely. If nothing else, Novell's continued development of Novell DOS should keep Microsoft on its toes.
ND7 makes the most sense for companies that are already using Digital Research's old Concurrent DOS, as well as for companies that need many of the bundled features. For Windows-only users, Personal NetWare has to compete with Windows for Workgroups, which gives roughly the same feature mix but keeps all the networking software in protected mode, out of the DOS arena. I'm planning to keep Novell DOS 7 installed on my home machines, but for the office PC, I'll wait for a bug-fix release that solves the CD-ROM problems.
Editor's note: TRUENAME.COM is available electronically. See pag
e 5 for details.
The Facts
Novell DOS 7 $99
Competitive upgrade $69
Novell, Inc.
122 East 1700 South
South Provo, UT 84606
(800) 453-1267
(801) 429-7000
fax: (801) 429-3098
File-Read Performance
Results of timing tests on Personal NetWare. I timed a copy operation of seven files, totaling about 1.5 MB. I copied in both directions between the 25-MHz 486 and the 20-MHz 386, from regular FAT (file allocation table) and compressed Stacker volumes. The speed varies by a factor of 3 from the slowest (386/20 to 486/33) to the fastest (486/33 to 486/25). The most interesting result was that the Cheetah 486/25 gave consistently better results than the IBM 486/33. This must have been due to differences in the network cards and drivers (the Cheetah has a Novell NE2000, and the IBM uses the IBM 16-bit Micro Channel Ethernet Adapter). Results are in KBps.
Client
Server 486/33
486/25 386/20
486/33 -- 233 91
486/25 163 -- 96
386/20 84 120 ---
Illustration: Most of Novell DOS 7's utilities run under both DOS and Windows. The ND7 Windows group contains icons for backup, virus detection, and network management.
Terje Mathisen is a software developer for Norsk Hydro in Oslo, Norway. He has been developing high-performance IBM-compatible software since 1981. He can be reached on the Internet at
terjem@hda.hydro.com
or on BIX as "terjem."
Novell's Newest DOS
