VD: Driver This version of the VD: driver for VMS fixes some major design flaws in the 1986 version and now appears to work reliably, at least where I've tried it (a VMS V4.7 system with directly attached massbus disks). It uses the same method as MSCP so should also be reliable on other systems. I added V5 code (conditioned by defining VMS$V5) but can't test it. Tests here have been for one unit. Note that the one thing that could cause trouble would be if your interrupt stack isn't big enough; during I/O postprocessing the driver uses some interrupt stack. If you want to be extra safe, try bumping an extra page into interrupt stack. VD: has been reported to work just fine in VMS V5 as a local disk, though I can't be sure about MSCP serving it. NOTE: Be sure to use VDDRIVER V4 there! It has the most protection against random stuff causing problems. It also has some fixes designed to make it work better over MSCP servers. Glitches: It seems with the current version that uses rp06 device type that the ANALYZE/DISK program reports lots of spurious and non-existent errors in the file structure on VD:. If this causes grief, replace the DT$_RP06 by DT$_FD1 in the driver so it'll be seen as a foreign disk type. The RP06 geometry is very different from that of VD: and confuses things. Also, 64 sectors per track is more than any DEC disk and may be overflowing a limit in Analyze/disk somehow. FD: Driver FD: works in VMS 4 and 5. Assemble with VMS$V5 defined for VMS V5. FDDRV is a virtual disk that uses a PROCESS running a host image (FDHOST is such a one) to do all its' I/O. Thus it is very flexible and useful for things like compressing disks, cryptodisks, remote virtual disks, and memory disks in paged, user-mode memory. Among other things, that is... FDDRV draws somewhat on John Osudar's memory disk driver and got an assist from Chris Ho, who gave me some VMS V5 fixes for the V4.7 VMS version to get it running right in V5. I have no idea if FDDRV works as MSCP served or not. I doubt it will cause a crash, but it might not work either. Try it and see. To make a new flavor of FDDRV, modify FDHOST, which is a normal but privileged VMS image (needs CMKRNL to read/set driver database up) to do what you want. FDHOST tells FDDRV that it's there and carries on a dialogue with FDDRV to move the data. (By the way, an assembly conditional in FDDRV will allow FDDRV to pass the address of the driver's buffer to the host process in case it's thought faster to manipulate that data via change mode to kernel and copy rather than special QIO.) +------------------+ +-------------+ +------------------+ ! Host process ! ! FDDRV ! ! Client Process ! ! does actual ! ! disk driver ! ! Uses FDDRV as a ! ! bit moving !<--->! looks like !<--->! disk. ! ! ! ! disk to ! ! ! ! ! ! client ! ! ! +------------------+ +-------------+ +------------------+ FDDRV can be used for a variety of virtual disk types. These include: 1. Memory disk with memory in a process, therefore pageable. The process' working set determines how much physical memory is actually used. This is supplied in FDHOSTMEM.MAR and works. 2. Remote mountable virtual disk over DECnet. This allows a DECnet object on a remote system to cooperate with a host process on another system to allow a disk on a remote system to be mounted remotely (useful for remote backups and the like). This is supplied in FDREMSRV and FDHOSTREMOT and works. 3. Remote mountable virtual disk over asynchronous lines. This works like remote mount over DECnet but with asynchronous (terminal) line hookup instead of DECnet. This is supplied in FDREMASY and FDASYREMO and is not fully tested yet. 4. Local virtual disk on a file. The file is treated as a string of 512 byte blocks, and need not be contiguous. This is supplied in FDHOSTFILE and is not yet fully tested. 5. Crypto disk. This works like local virtual disk on a file, but the file is encrypted before being recorded and decrypted when read. This is supplied in FDHOSTCRY or with a stronger encryption algorithm in FDHOSTCRY2. It works. The FDHOSTCRY2 version in particular has a VERY long encryption cycle and should resist attempts at cracking the code by all but people experienced in this sort of thing. The fdhostcry version uses a 64 bit XOR which is fairly easy to break but is OK against casual browsing. The fdhostcry2 host program supports a /WEAK keyword which will cause it to use the weaker algorithm of fdhostcry. 6. Compression disk. This would use memory or a disk file to hold data, but compress it before recording it and decompress on retrieval. This is not yet written. Others may occur to the reader. Enjoy! Glenn Everhart Everhart%Arisia.decnet@crd.ge.com 25 Sleigh Ride Rd Glen Mills, PA 19342