VOICE Home Page: http://www.os2voice.org
[Newsletter Index]
[Previous Page] [Next Page]
[Feature Index]
|
VOICE Home Page: http://www.os2voice.org |
August 2003
[Newsletter Index]
|
| By Frank Wochatz © August 2003, Translation: Philhard Ackermann |
Virtual drives are quite useful for many tasks. With them, for instance, you can 'fake' a virtual floppy drive for software packages that depend on floppy-based installation (like when you need to install some fixpak or need to use Thinkpad drivers which are often delivered as self-extracting archives that can only be unpacked to a floppy disk) without actually having such a drive physically installed. Another area of application might be a RAM drive. Such a disk may be used just like an ordinary hard disk drive, but all of it's contents are being stored in memory. Since RAM access is significantly faster than 'real' hard disk access, programs using a lot of files might be sped up considerably this way.
Consider putting your machines cache, temp path or frequently used libraries on such a RAM drive. You might even put entire applications on such a drive, thus significantly reducing application load time.
Beware: Data residing in RAM or on a RAM drive will be deleted at system shutdown, either on purpose or due to a system crash! Therefore critical data like documents do not belong on a RAM drive or must be copied to some other media (advisably on a regular basis, to avoid data losses or at least reduce them to a minimum).
There are several tools available for this task for OS/2 and eComstation, some of which I'd like to introduce in this article.
OS/2 already features a driver for a virtual drive out of the box. The file vdisk resides on your boot drive in the \OS2\BOOT directory.
The installation is carried out by manually adding a line to config.sys. The driver understands several parameters like disk size, sector count etc. It's syntax description can be found inside the OS/2 online manuals. [Editor's note: Type help vdisk at a command prompt]
The size of a VDISK drive may be up to 32MB, and there's no way to change this on the fly, you can only alter config.sys and reboot to activate the changes.
The OS/2 help files offer all information needed to deal with this driver.
Up to release 1.7 this driver has been developed and maintained by Brian Martin (IBM), if you use an editor to search the driver file for human readable strings you will find 'VFDISK 1.7 Virtual Floppy Disk (1.44Mb,1.2Mb,720K,2.88Mb,360K,1.84Mb) for OS/2 IBM Internal Use Only'.
The latest release of vfdisk is 3.0. Apparently, further development of this driver for virtual floppy drives has been taken over by Daniela Engert, who is also famous for her enhanced IDE and ATA drivers.
In addition, the archive contains a control program (release 2.0) by Michael Fraenkel and Brian Martin to adjust such a disk's capacity. Disk sizes from 360K up to 2,88MB are being supported. As a special feature, the virtual disk can be 'ejected'. In that case, VFDISK frees the memory it has been using to be reused by other applications. Since RAM disks are not often used in daily operations, this feature lets you initialize such a disk as 'ejected', thus only activating it, if needed, 'on the fly' (like when installing IBM device drivers delivered as disk images) with the proper size for the task that needs to be done, and then 'eject' it again after you're done with that particular installation.
To install this driver you still need to edit config.sys. The VFDISK control program's help file contains all information you might need for this. Quaintly enough, the corresponding pages of the VFDISK Control Program's help file cannot be accessed from within the control program - there's no index or table of contents entry for them. As a workaround you might open the help file separately using view or newview, or search the help file for 'config.sys'.
Adjusting the disk's capacity or ejecting the virtual floppy can conveniently be done by using the drive's context menu, and each of the possible capacities is being shown with a different icon inside the control application.
For command line interface warriors there's also a text-based tool enabling them to carry out any function from here. Alas it's syntax isn't documented anywhere. Other than in config.sys any parameter needs the drive letter as additional information.
For example: vfctrl.exe T: 1
builds a t: drive with a common size of a 1.44 MB diskette.
If the size parameter is omitted, the tool returns the actual size of the drive.
Alas the documentation doesn't mention the licensing scheme.
'Super Virtual Disk v1.2' by Albert J. Shan is the only commercial solution mentioned in this article. It features virtual drives of up to 128MB, it simulates virtual floppies from 16KB up to 2.88 MB (even supporting the XDF format), the disk's size can be adjusted on the fly and media can be virtually ejected and formatted. It's operation is controlled by the PM program SVDISK Control:
It gets installed through an efficient command line installation routine (selectable languages: English and German), it's documentation is shipped as an ASCII file and describes it's functions quite thoroughly.
Attention: during my testing the *.msg files were not created. They can be installed manually by renaming all *.ger (or *.eng) to *.msg.
The only drawback: After installation a shareware countdown is shown at boot time (which sometimes even produces ASCII garbage on my screen), even within the regular testing period.
Overall this is an excellent, straightforward tool, which, on the other hand, comes at a price - it's registration fee is 40 US$.
SVDISK can be purchased (for example) via http://www.bmtmicro.com.
The freeware RAMFS by Karl Olsen (enhanced by Jack Stein and Andrew Belov) uses a completely different scheme: it installs an installable file system (IFS) via an entry in config.sys. The RAM disk itself is activated only after running RAMDISK.EXE. Thus the disk is only created when you really need it, which is an advantage compared to some other programs dealing with virtual drives. The RAM disk created can span over as much as the physical RAM that's inside a given machine. There may even be several virtual disks defined at the same time. Their drive letters can be freely specified when RAMDISK.EXE is run. What's more, the RAM disk works quite dynamically by only reserving as much RAM as necessary to hold the amount of data stored on it. You shouldn't get confused by RAMFS reporting a size of 64 MB after standard installation - such a return value is needed by many programs and is by no means related to the actual amount of RAM used (and the exact value returned from the program can even be configured by the user). If a file gets erased from the RAM disk, it frees that amount of storage accordingly.
Another feature: the program is being shipped complete with it's source code.
Of course all aforementioned tools may be installed and used on Warp 4 side by side at the same time.
And this is how these programs show in the OS/2 drives folder:
H = SVDISK
I = VDISK
J = VFDISK
Z = RAMFS
I myself am using a combination of VFDisk and RAMFS. VFDisk gets loaded 'ejected' at boot time and activated only if I need it. For temporary work files I am using a dynamic RAMFS drive.
References:
|
[Feature Index]
editor@os2voice.org
[Previous Page] [Newsletter Index] [Next Page]
VOICE Home Page: http://www.os2voice.org