DVdevload (c) Copyright 1991, 1992 Ralf Brown
What is it?
DVdevload and its support program DVeop allow you to load device
drivers in a DESQview window. Unlike Quarterdeck's DEVICE.COM through
version 2.34, DVdevload actually links the driver into the device
driver chain, thus permitting the use of drivers which do not hook any
interrupts. With those versions of DEVICE.COM, if the driver does not
hook any interrupts, it is completely inactive because DEVICE.COM does
not hook it into the driver chain. DEVICE.COM from DESQview v2.40 and
higher does hook the driver into the device chain, but uses much more
memory than DVdevload; it also does NOT correctly unlink the driver
when the window is closed if the shell is 4DOS or NDOS, leading to
system instability. Further, DVdevload updates the special pointers
DOS maintains to the CON and CLOCK$ devices, while DEVICE.COM does
Changes since version 1.00:
Fixed bug which caused unpredictable behavior if the driver
modified DS on installation.
Changes since version 1.10:
No longer requires DVeop TSR if neither 4DOS nor NDOS is present.
Reduced resident size from 192 to 176 bytes
This product is distributed AS IS, with no warranties, express or implied.
The author disclaims all liability for any damages (incidental or
consequential) caused by the use or misuse of this product. Sole
responsibility for determining its fitness for use rests with the user.
DVdevload is quite simple to use. If you are using 4DOS or NDOS as your
command interpreter, you must install the DVeop driver before starting
DESQview. This may be accomplished by adding a line to either
AUTOEXEC.BAT or your DESQview startup batch file invoking DVeop without
If you like, you may install DVeop even if you are not using 4DOS or NDOS.
You should install DVeop if you are using another COMMAND.COM replacement
and find that your system locks up or begins acting strangely after using
the replacement's EXIT command in a window using DVdevload. DVeop
provides a service which ensures that DVdevload can correctly clean up
when the window is closed even if some program loaded before DVdevload
restores INT 2Fh to the original value it saw at startup.
DVeop will automatically load itself into high memory using either XMS
or DOS 5 upper memory blocks; LOADHIGH or its equivalent is completely
superfluous and would in fact *increase* DVeop's memory requirements.
DVEOP.COM and DVEOP-S.COM are the same except that DVEOP-S.COM only
supports 3 simultaneous windows using DVDEVLOD, while DVEOP.COM
supports 16. This results in an 80-byte savings in the resident
portion (272 bytes versus 352 bytes when loaded high).
Once DVEOP has been run (if necessary), you can now start DESQview.
Within each window that requires a particular driver, you need to run
DVDEVLOD.COM. Thus, you would have a line like
in that window's startup batch file. If the driver requires any parameters,
you simply place them after the driver's name, as in
DVDEVLOD C:\DOS\ANSI.SYS /L
DVDEVLOD C:\DOS\DISPLAY.SYS con=(ega,437,4)
You may run DVDEVLOD multiple times within a single window to load multiple
DVdevlod requires DOS 2.0 or higher and DESQview 2.26 or higher. Once
installed, it uses 176 bytes in addition to the memory used by the driver
This version of DVdevload is not able to load block devices inside a DESQview
window. If the driver provides one or more drive letters, it must be loaded
in CONFIG.SYS.While technically possible, loading block devices is far more
complex than character devices, because several DOS-internal data structures
must be modified on each task switch. A future version will remove this
Further, DVdevload can not be used in windows for which the protection level
(second "Change a Program" screen) has been set to either 2 or 3, as DESQview
will complain about a protection violation each time DVdevload tries to
patch the device chain. There are no problems with protection levels 0 or 1.
I do not believe that a workaround for this problem exists, because DVdevload
must inherently mess with DOS's internals, which is considered outside the
program's address space at higher protection levels.
The newest version is available in the following places:
On the Internet, for anonymous FTP from CS.CMU.EDU [220.127.116.11] in
directory /afs/cs.cmu.edu/user/ralf/pub/DESQview. You must change
directory there with a single command before attempting to retrieve
any files, due to the way the security mechanism works. If your site
is connected to AFS, you can simply change directory to the above
directory and perform a normal Unix/VMS/whatever file copy.
On FIDOnet, for download and File Request from SoundingBoard, 1:129/26,
1-412-621-4604, 14400 HST. The file is kept in file area 8.
Ralf Brown[valid until November 1, 1993]
813 Copeland Way, Suite 26
Pittsburgh, PA 15232
Internet: [email protected]
CIS: >INTERNET:[email protected]
FIDO: Ralf Brown 1:129/26.1