                        Graphic Vision File Manager
                        ===========================

Version 2.65 22nd December 2007

CodePage CP850 (MS-DOS Western Europe)

Graphic Vision File Manager is a graphical DOS file manager and program 
launcher with long file name and full drag and drop capabilities. It has 
the look, feel and functionality similar to that of MS Windows File Manager. 
GVFM can use any high resolution 8, 15, 16 or 32bpp SVGA video mode up to 
1600x1200, or any 16-colour (4bpp) mode up to 800x600. GVFM also supports 
long file names when run in a Win9x/ME DOS box or other DOS LFN-capable 
environment.


CONTENTS
========

  Copyright................................ 33
  Warranty................................. 51
  Minimum System Requirements.............. 63
  Installation............................. 78
  Networks.................................288
  Uninstalling GVFM........................336
  Running GVFM from a CD-ROM drive.........349
  Running GVFM in a virtual machine........366
  Using GVFM...............................405
  The VESAMTRR utility.....................646
  Upgrading to a newer version of GVFM.....688
  Contacting the author....................701


COPYRIGHT
=========

Copyright (c) 1995 - 2007 Jason Burgon
All rights reserved
All rights not expressly licensed to the user are reserved to the developer.

You may use and distribute this software freely as long as no charge is made 
and you do not add, remove or alter any files in it.

The JPEG code was originally translated to Tubo Pascal by NOMSSI NZALI Jacques 
H. C. His code is based on the Independent JPEG Group's JPEG software release 
6b. The Graphic Vision version of this code can be downloaded from my website:

  http://homepage.ntlworld.com/gvision/download#JPEG


WARRANTY
========

This software is provided "as is", with no warranty expressly stated or 
implied. The user of this software assumes all risk of use. Jason G Burgon 
will not be held liable for any loss of profit or damages due to claims based 
on consequential, incidental, or other similar damage claims. Please note that 
this is freeware, and while I know of no bugs, there might be some, though the 
actual file/folder copy, move and delete functions have proven themselves to be 
very reliable for several years.


MINIMUM SYSTEM REQUIREMENTS
===========================

 DOS 3.3 or compatible
 386 processor (Pentium or better recommended)
 8MB RAM
 XMS memory manager (#1)
 VGA Graphics system (SVGA highly recommended)
 Mouse or other pointing device (a PS/2 port or serial port one recommended)
 Microsoft 7.05+ compatible mouse driver (CtMouse 2.x highly recommended)

#1: An XMS memory manager such as HIMEM.SYS is usually only required with the 
DPMI16BI.OVL/RTM.EXE version of GVFM - see "DPMI Server" below.


INSTALLATION
============

Simply exctract all the files in the zip into the same folder. Win9x/ME users 
can move "GVFM.PIF" to their "Windows\Desktop" folder and edit the .pif to set 
the path to GVFM.EXE accordingly.

DPMI server
-----------

GVFM is supplied with two DPMI servers and and two Win3.1 kernel emulators - 
DPMI16BI.OVL/RTM.EXE and the free HDPMI16.EXE/RTM.DLL. The supplied GVFM.EXE 
will use Borlands DPMI16BI.OVL and RTM.EXE, but you can use MAKE-FM.BAT to 
make a patched copy of GVFM.EXE called FM.EXE that will use HDPMI16.EXE, 
RTM.DLL and DPMI16LDR.EXE instead.

The HDPMI16.EXE/RTM.DLL/DPMI16LDR.EXE version would be preferable in all cases 
except that either RTM.DLL or the Windows 9x DPMI extender contains a memory 
allocation bug. For this reason I recommend using GVFM.EXE when running in a 
Win9x DOS box, and FM.EXE when running under a real DOS or in a virtual x86 
DOS machine.

GVFM.EXE requirements
---------------------

DPMI16BI.OVL and RTM.EXE must either be in the same folder as GVFM.EXE, or be 
in your PATH. DPMI16BI.OVL requires XMS services to be available to it, so  
you need to load HIMEM.SYS or other XMS driver when running GVFM.EXE under 
pure DOS. I've found that the best HIMEM.SYS is the one supplied with 
Win98/ME. EMM386.EXE is NOT required by GVFM and I do not recommend you load 
it unless you need it for some other DOS application[s] you use. My 
recommendation then would be to use JEMMEX.EXE (written by Japheth) to replace 
both HIMEM.SYS and EMM386.EXE.

Note that Win9x/ME DOS boxes automatically provide XMS and DPMI services to 
DOS programs, so you don't have to load HIMEM.SYS or have DPMI16BI.OVL in your 
PATH to run GVFM in a Windows 9x/ME DOS box. The distribution contains a 
suitable Windows 9x/ME .PIF file for GVFM.EXE.

DPMI16BI.OVL and RTM.EXE limit GVFM.EXE's memory to 64MB and 32-bit DPMI 
programs cannot be launched when DPMI16BI.OVL is the DPMI server.

GVFM.EXE can also use HDPMI16.EXE as the DPMI server by loading HDPMI16.EXE 
first:

C:\>HDPMI16
C:\>GVFM.EXE

Or you can load HDPMI16.EXE resident:

C:\>HDPMI16 -r
C:\>GVFM.EXE

The "HDPMI16 -r" statement could be added to your AUTOEXEC.BAT file instead.

FM.EXE requirements
-------------------

HDPMI16.EXE, DPMILD16.EXE and RTM.DLL must either be in the same folder as 
FM.EXE, or be in your PATH.

HDPMI16.EXE might need XMS services available to it in some rare cases. If it 
does then you need to load HIMEM.SYS or other XMS driver when running FM.EXE 
under pure DOS.

A bonus of using the HDPMI16.EXE DPMI server is that if you load HDPMI16.EXE 
resident first and then load HDPMI32.EXE afterwards, you will be able to 
launch most 16-bit and 32-bit DPMI applications from GVFM:

C:\> HDPMI16 -r
C:\> HDPMI32 -r
C:\> GVFM

HDPMI and DPMILDR seems the most compatible when it loads each application 
into its own address space. This can be done by setting two DOS environment 
variables:

SET DPMILDR=8
SET HDPMI=16384

Those of you that must use [E]DR-DOS EMM386.EXE should switch its DPMI server 
off and and set PIC=ON because:

   EMM386.EXE's DPMI server is a buggy piece of rubbish.
   HDPMI16.EXE and HDPMI32.EXE can't handle EMM386's PIC remapping.

Switch its DPMI server off when EMM386.EXE is loaded by CONFIG.SYS:

C:\DRDOS\EMM386.EXE DPMI=OFF ...etc

Switch the PIC option on either in AUTOEXEC.BAT or at the command line:

C:\>EMM386 PIC=ON

In my opinion though, DR-DOS EMM386.EXE is flakey and should be avoided. A 
better alternative is JEMMEX.EXE which along with HDPMI and VESAMTRR are open 
source and available for free from http://www.japheth.de/

Video
-----

GVFM should run on just about every VGA/SVGA video card on the planet. Sadly 
though there are many cards with very buggy VESA Video BIOS Extensions (VBE). 
The bugs are pariculaly numerous when in comes to video modes that use more 
than 8bpp (256 colours) and the more recent VBE extensions. If you are having 
trouble running GVFM and other DOS programs in high-res modes, then you might 
want to see if UniVBE will fix the problem. UniVBE is now free again and 
available from via this Wikipedia page:

 http://en.wikipedia.org/wiki/univbe

Mouse
-----

If your mouse pointer "jumps" several pixels at a time instead of moving 
smoothly accross the screen in SVGA modes, then your mouse driver is buggy. 
Some mouse drivers simply do not report the virtual position of the mouse 
pointer correctly. CuteMouse is a free mouse driver that works with any 
standard serial or PS/2 mouse and can be obtained from the CuteMouse website:

 http://cutemouse.sourceforge.net

If you use the CuteMouse 2.xx mouse driver then GVFM will support the wheel of 
wheeled mice under 'pure DOS' (but not in a Windows DOS Box). This is a very 
good driver with a very small memory footprint. I have been actively involved 
in this open source project to provide a DOS mouse driver that supports the 
wheel found on modern mice. CuteMouse also has a very small memory footprint 
and is realtime application-friendly.

Note that the CuteMouse 2.0x driver acesses the PS/2 ports directly, so it 
won't work if you're using a USB mouse with your BIOS emulating it as a PS/2 
device. In this case I recommend you use the CuteMouse 2.1 driver instead:

 http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/mouse/eric/

Long file names
---------------

GVFM is very good for really getting rid of, or repairing a Win9x partition, 
since it is capable of displaying and manipulating hidden files and folders.

Long file names are only available when the operating environment provides 
them: This means only when runing in a Win9x Dos Box or under an LFN-capable 
MS-DOS or clone.

I have also tried the latest version of the DOSLFN driver (0.40e) and it now 
seems to work ok, at least under MS-DOS 7.x (Win9x MS-DOS), but there are 
still problems with DR-DOS 7.03 (though it seems only with LFN-unaware 
programs). So if you need LFN support under pure MS-DOS 7.x (very useful for 
emergency Win9x fixing), then you'll need to install the DOSLFN driver before 
launching GVFM. LFNDOS is availiable from:

  http://geosites.com/jadoxa/doslfn/index.html

ROMDOS is an LFN-capable MS-DOS clone from Datalight. A free single user copy
of ROMDOS is available for free from Datalight at:

 http://www.datalight.com

Only the 7.x version of ROMDOS supports long file names, and make sure to use 
their SMARTDRV.EXE disk cache to improve GVFM's performance under this O/S.

Localisation
------------

GVFM's string resources are only in English (but only because the only other 
languages I speak are Pascal and assembler :-), but it does fully support the 
following DOS code pages:

437 - USA
737 - Greek
775 - Baltic Rim
850 - Western Europe
852 - Central Europe
855 - Eastern Europe
857 - Turkish
858 - Western Europe with Euro symbol
860 - Portuguese
861 - Icelandic
862 - Hebrew (limited font support)
863 - French Canadian
865 - Nordic
866 - Russian Cyrillic
869 - Greek 2

Any other single-byte Latin, Greek or Cyrillic based character set (SBCS) code 
page could also be supported if I had the cpXXXX to Unicode translation table 
available to me, so if you need support for a certain SBCS code page then send 
me a plain-text file in the following (Unicode Consortium standard) format:

#    Format: Three tab-separated columns
#        Column #1 is the cpXXXX code (in hex)
#        Column #2 is the Unicode (in hex as 0xXXXX)
#        Column #3 is the Unicode name (follows a comment sign, '#')
#
# Example line:
0xb0	0x2591	#LIGHT SHADE

I don't need the third column but it would be very useful for completeness.

GVFM does not directly support DBCS code pages (yet) - it will default to 
using cp858 (Western Europe with Euro currency symbol) if it's run on a DBCS, 
or any other unsupported code page.

If anyone who knows both English and another language (very well) and wants to 
volunteer to translate both GV's and GVFM's strings to another language, then 
I can can send you the English version of the strings for translation. Be 
warned though that there are a quite a lot of strings to translate.


NETWORKS
========

I have tested this software on both Win9x and DR-DOS pier-to-pier networks 
and all works very well for me, so it should be quite happy on any network. 

GVFM loads a configuration file when it loads and stores it when it exits. 
This file is used to restore the desktop and the users configuration each 
time GVFM loads. 

By default, GVFM looks for a file called GVFM.CFG in the same folder as 
GVFM.EXE. However, if you want to put GVFM.EXE onto a file server then it 
is far better to have a unique GVFM configuration file for each network 
user. This can be acheived because GVFM looks for a DOS enviroment 
variable called "GVFM". If this variable contains a valid [path and] 
filename then GVFM will use this as its configuration file instead.

So all you (the network administrator) have to do is make sure that each 
machine has a GVFM environment variable set so that each network user sees 
his or her correct GVFM configuration file. There are a million ways to 
acheive this - here is just one suggestion:

Place FM.EXE, HDPMI16.EXE, DPMILD16.EXE and RTM.DLL in a folder on the 
server that all users can see, eg:
 
  \\SERVER1\SHARE\BIN

This folder will be mapped to a user drive (let's say S:), so all users see 
"\\SERVER1\SHARE\BIN" as "S:\" and "S:\" will be in each users PATH. This 
folder can be set for read-only access.

Each user has a "private" data folder (with read/write privilages) on 
SERVER1 that only [s]he can see. Something like:

  \\SERVER1\USER\JOHN
  \\SERVER1\USER\PAUL
  \\SERVER1\USER\GEORGE
  \\SERVER1\USER\RINGO

etc, and the NET login script for "John" maps \\SERVER1\USER\JOHN to (lets 
say) his  H:\ drive. The NET login script for "Paul" maps \\SERVER1\USER\PAUL 
to his H:\ and so on.

Now put a "SET GVFM=H:\GVFM.CFG" in each machines autoexec.bat (or better, in 
each users login script file) and each user will get their own unique GVFM.CFG 
file regardless of which machine they log in on.


UNINSTALLATION
==============

GVFM makes no changes to any of your system files (CONFIG.SYS, AUTOEXEC.BAT 
etc), so unistalling simply means deleting GVFM.EXE and the GVFM.CFG file it 
creates in the same folder as itself (by default).

If a previously working GVFM crashes when it initializes then you should try 
deleting the GVFM.CFG file (found in the same dir as GVFM.EXE by default), 
then re-running GVFM. This will reset the default settings and video mode 
(mode 12h - 640x480x16).


RUNNING GVFM FROM A CD-ROM DRIVE
================================

GVFM normally needs write access to the drive/folder it is run from so that 
it can update its "GVFM.CFG" file. So if you run GVFM from a CD-ROM drive 
then you either have to put up with an "Unable to write configuration file" 
error message every time you terminate the program, or you can define an 
environment variable called "GVFM" and set it to a path and file name with 
read/write permission. You might for example put this in your AUTOEXEC.BAT 
file:

SET GVFM=C:\GVFM.CFG

Now all GVFM.EXE and FM.EXE instances will use "C:\GVFM.CFG" as their 
configuration file.


RUNNING GVFM IN A VIRTUAL MACHINE
=================================

GVFM will run in a virtual machine such as provided by VMWare, VirtualPC, etc, 
but neither of the above or any other I've tried properly emulate (or 
provide hardware access to) the programable interrupt timer #0 that GVFM uses 
to provide its timing functions. This means that things such as automatic 
scrolling when a scrollbar button is pressed and held, as well as most other 
time-based GVFM functionality will not work correctly. GVFM's clock will work 
however as this does not require direct access to the PIT#0 hardware registers.

GVFM does provides a means that might improve its timing in a virtual machine, 
and that is to allow it to set the system timer tick rate to a higher value 
than its default 55ms period (18.2Hz). You can do this by opening the 
OptionsDisplay_Preferences dialog box, then selecting the [System] tab. Now 
click the tick box labeled 'Enable Virtual Machine Settings' and change the 
'System Timer Tick Rate' from its normal value of 55ms to something lower. A 
setting of 10 or 20ms are two values you might want to try.

Note that there is no need to do this in a Windows 9x DOS box because the 
Graphic Vision run-time code already detects that it's running under Windows 
and automatically reprograms the timer to run at exactly twice its normal 
speed. This action kickstarts Windows 9x into allowing GVFM direct access to 
the PIT#0 registers. The result of this is that GVFM's very high precision 
timing functions work remarkably well in a Win9x DOS box.

You can also set a different tick rate in pure DOS as well if you want, but 
there is a very small chance that doing so will make something such as a 
network device driver malfunction (though I have to say I've never seen it 
cause any problems). This is why GVFM does not just set a faster tick rate 
automatically. If GVFM shows that the tick rate is 55ms before you change it, 
then there is a very high probability that changing its value will cause no 
problems at all. However, I strongly recommend that you leave it well alone if 
GVFM shows it to be at any other value. 

GVFM will reprogram the timer chip back to its original tick rate when it 
terminates.


USING GVFM
==========

There is no on-line help for GVFM at the moment, but everything should be 
very intuitive to use. Its operation and look is very similar to MS Windows 
File Manager. Note that only one browser window is created when GVFM is first 
run - use the [F3] key to create more.

Command Line Options
--------------------

GVFM might hang during initialization (or when you open a drives list drop-
down list) on some machines that have no floppy disk controller chip in them - 
this means laptops mostly. The problem is a DOS/BIOS limitation that simply 
cannot cope with this situation: When any program (including MS-DOS and Win9x) 
tries to access drive A:, the machine simply hangs inside the DOS/BIOS call. I 
have yet to find a reliable way of detecting this situation, so GVFM instead 
accepts a list of drive letters that it will NOT scan while it generates its 
list of valid drives. The syntax is:

GVFM -d=[drivelist]

where [drivelist] contains the drive letters you DO NOT want GVFM to see. The
list can include any drive or logical volume - it's not limited to just floppy 
drives. For example, to exclude drives A:, B: and E:

C:\>GVFM -d=ABE

Note that you only have to invoke GVFM.EXE with the "-d=" command line option 
once, since GVFM will then store the specified drive exclusion list in its 
configuration file - GVFM.CFG. This list can be edited within GVFM via the 
[System] tab of the OptionsDisplay_Preferences dialog box. Starting GVFM with 
the "-d=" option will override any exclusion list stored in GVFM.CFG.

If GVFM crashes or takes a very long time to initialise then you might want to 
use the '-L' command line option to make GVFM create a log file called 
'GVFM.LOG'. 

C:\>GVFM -L

This text file will be created and stored in the same folder as GVFM.EXE and 
will contain milli-second timings of how long various parts of the 
initialisation process took to perform. GVFM should take no more than about 
4 or 5 seconds on any machine built this century. Things that will greatly 
increase GVFM's load time are:

  Reloading a browser window of a floppy drive with no disk in it, or a 
   disconected mapped network drive.

  Reloading browser window[s] that are displaying the contents of slow drives 
   (floppies, CD-drives, slow USB sticks etc).

  Having no disk cache driver (SmartDrv or equivalent) running.

  Low memory (less than about 6-8MB).

  Using large JPEG image[s] for your desktop background and/or picture.

If GVFM crashed while loading, then the last logged entry in GVFM.LOG will show 
me where during initialisation it did so. If GVFM did crash then please send me 
an email containing GVFM.LOG and a description of what happened.

Running GVFM for the First Time
-------------------------------

When first run, GVFM will display a message box to say that it cannot find its 
'GVFM.CFG' file and that it will use its default settings. This is its normal 
behavior because no GVFM.CFG file is supplied in the GVFM distribution. The 
default video mode used will be standard VGA mode 12h (640x480x4bpp). While 
GVFM will work in this mode perfectly well, it should only really be regarded 
as a get-me-going. So the first thing you're likely to want to do is set a 
decent video mode - select the "OptionsVideo_Mode..." menu item. I strongly 
advise using a linear frame buffer mode if your computer supports it because 
they are generally much faster - often as much as 10 times faster. You can do 
this by ticking the check box at the bottom of the "Change Video Mode" dialog.

In the unlikely event that your graphics card or monitor does not support VGA 
mode 12h, then define an environment variable called GVMODE and give it the 
value of a mode that your graphics card does support. If you know for example 
that your card supports VESA mode 257 (640x480x8bpp), then type the following 
from the command line before running GVFM for the first time:

SET GVMODE=257

Make the video mode number negative to set a linear frame buffer (LFB) 
equivalent mode. So to force GVFM to use VESA LFB mode 257 (640x480x8bpp):

SET GVMODE=-257

File/Folder Move/Copy
---------------------

The [SHIFT] or [CTRL] key is effective when selecting and dragging and 
dropping files and directories with the mouse: If the drag-drop cursor is 
showing a "+" symbol in its sheet of paper then the operation will be to copy 
the file(s) or folder. If no "+" is showing then the operation is a move. All 
operations will ask you for confirmation by default. Selecting 
OptionsConfirmations from the main menu will allow you to switch off the 
confirmations you don't want. I recommend you at least leave all the folder 
confirmations enabled.

For safeties sake, files being moved are always written to their destination 
before being deleted from their original location - I've never lost a file 
using GVFM.

File/Folder Properties
----------------------

When changing the properties of a selection of files you can be selective as 
to which file attributes, date and time are actually changed and which are 
left unaltered: The given file attribute of the selected files will be left 
unchanged if that checkbox is greyed-out. The date and time properites are 
controlled by the checkbox immediately to their left; if the checkbox is 
unchecked then the date [time] of the file[s] will remain unchanged.

File Pane Field Widths
----------------------

All the file pane fields (type Icon, Name, Size, Date, Time, Attribs) auto-
size themselves by default, but you can override this and fix the width of 
any column by moving the mouse cursor to the end of that columns label button 
(the mouse cursor will change shape to a double-arrow with vertical bar) and 
drag the column label button to the left or right. You can revert the column 
back to auto-sizing by right-clicking its label button. Reverse sorting on any 
field is accomplished by left-clicking on its label button (twice if it's not 
the primary sort field, as indicated by the triangle). Clicking it again will 
restore the normal sort direction.

Integrated Text Editor
----------------------

If you don't set a custom editor (OptionsInstall custom editor) then GVFM's
integrated text editor will be used when you press [F4]. The internal editor 
is a plain text editor that can handle files of up to 64k bytes in size. If 
you do set your own (external) editor then this will be used instead. You can 
revert to using the integrated editor by using "OptionsInstall custom editor" 
again and setting an empty path.

GVFM's editor can read, write and convert plain text from most 8-bit (SBCS) 
MS-DOS code pages as well as many MS-Windows and all the ISO-8859-X encodings. 
The codepage used by default is the DOS copepage being used by your machine 
(or cp850 if you have an unsupported page active). This can be changed by 
right-clicking inside an editor window and selecting the "Set Encoding..." 
item, or by going to the main menu and opening a text file via the 
"EditorOpen..." dialog box.

The "Set Encoding" dialog box has two action buttons:
  [Ok]:	Remaps the editor text from its current code page to the new encoding.
  [No]:	Ignores the texts current code page and just sets the new encoding.

The [No] button marks the text with the new encoding. In effect, it just
changes the font which is used to display it. The [Ok] button performs a full 
remapping of the text from its current encoding to the new one. A warning will 
be given if the text contains characters that cannot be re-mapped to the new 
code page.

Chosing "EditorSaveAs" allows you to save the file using a different 
character set.

Note that the codepage designated "cp850 (MS-DOS Western Europe)" in GVFM is 
actually mapped as IBM's "modified cp850", a.k.a CP858. CP858 is the same as 
CP850 except that code "0xD5 Dotless i" () is replaced with the Euro currency 
symbol. If you're reading this from inside a GVFM editor window that is using 
CP850, then you should see a Euro currency symbol inside the above brackets.

Both the integrated editor and the text viewer recognize and preserve CR+LF 
(Win/DOS), LF (Unix/Linux) and CR (Apple Macintosh) end-of-line protocols.

Using the Start Menu
--------------------

GVFM's [Start] menu system allows you to define a set of external programs,
image files and text documents that are just a few mouse-clicks away. To add 
an item to the Start Menu:

   Use a browser window to navigate to the folder containing the .EXE, .BAT, 
    .TXT or other file.

   Right-click on the file you want to add and select "Add to Start Menu..."
    from the pop-up menu. This will bring up the "Edit Start Menu Item" dialog 
    box.

   Edit the fields as appropriate, then click the [OK] button. This will add
    your new Start menu item to the top of the top-level [Start] menu. A hot
    key can be selected by surounding a letter in the "Name" field with a pair
    of tilde (~) characters. e.g: "~P~rograms" will make "P" (any case) the
    hot-key for that item and the "P" of "Programs" will be shown underlined 
    in the menu.

Start menu items can be edited, deleted and divider lines and sub-menus 
inserted by right-clicking over the appropriate Start Menu item and selecting 
the appropriate action from the pop-up menu that appears.

A Start Menu item can be moved around the menu tree by opening the Start Menu, 
then holding down the [Ctrl] key, pressing the left mouse button and dragging 
the selected item to its new location.

Setting a desktop picture and wallpaper
---------------------------------------

GVFM can display a picture, centred on its destop, over the top of the blue-
grey "GV File Manager" tiled wallpaper. You can also set the wallpaper to a 
bitmapped image of your own chosing.

The destop picture can be treated as a normal "opaque" image, or as a semi-
transparent "icon" where the last palette entry of a Windows 2,4 or 8bpp 
image is regarded as transparent (and its actual RGB value is therefore 
irrelevant). If you set the [transparent] radio button, then all pixels that 
map to this last palette entry will be undrawn and the desktop wallpaper will 
show through. DOLPHIN3.BMP is an example desktop overlay picture designed to 
be displyed as "transparent".

Both the "Opaqueness" and the path to the destop picture are set in the 
"Display Preferences" dialog - [Global] tab. If you set a relative path for 
the picture, then this will be taken as relative to the folder containing 
GVFM.EXE.

You can save memory by not specifying a destop picture - set a null path in 
the dialog. In this case no overlayed desktop picture will be displayed.

The tiled desktop wallpaper image can also be changed to a bitmap of your own 
choice in a similar way to the above. The desktop wallpaper image is always 
treated as 100% opaque. The BWSTRIPE.BMP, 256.BMP, 64.BMP, BLUEFADE.BMP, 
OS2FADE.BMP, and PINKFADE.BMP images are provided as alternative desktop 
wallpapers. All the XXXXFADE.BMP's are 32bpp images and will only display 
properly if you set a 15, 16 or 32bpp video mode. GRAVIS.BMP can be used both 
as an opaque wallpaper or as a transparent picture.

If you just want to have one large image to cover your entire desktop, then 
the optimal way to do this is to make this the wallpaper and not have any 
picture set (i.e leave the Picture path blank).

Colour schemes:
---------------

The *.GVP files are alternative colour schemes for GVFM which can be loaded 
via the OptionsPalette -> [Load] button. You can also create and save your 
own colour schemes with the OptionsPalette and OptionsPalette|System_Palette 
dialog boxes.


USING VESAMTRR TO IMPROVE GRAPHCIS PERFORMANCE
==============================================

This GVFM distribution also contains a very useful utility called VESAMTRR.EXE 
(written by Japheth) that enables write combining to the video display memory. 
VESAMTRR can improve graphics throughput by as much as 50 times on many 
machines, so I strongly recommend its use on any Pentium Pro or higher machine 
running any standalone DOS except for MS-DOS 7.x (MS-DOS 7.x already does what 
VESAMTRR does, so it is not usually needed, but see the note about standard 
VGA and SVGA banked modes below).

MACHINES WITH PENTIUM 1 OR OLDER PROCESSORS DO NOT NEED AND SHOULD NOT USE IT.

Since VESAMTRR will improve the performance of all graphics applications that 
use a linear frame buffer to access the video RAM, I recommend you run it from 
your AUTOEXEC.BAT file with something similar to the following:

\DOS\DRIVERS\VIDEO\VESAMTRR

Note that VESAMTRR needs a DPMI host such as HDPMI32.EXE that runs in ring 0 
to work. VESAMTRR is not a TSR and so will not take up any memory once it has 
done its thing.

VESAMTRR can also improve the speed of banked graphics video modes as well, 
albeit at the possible expense of making a mess of 4bpp graphics mode displays 
such as the standard VGA mode 18 (640x480x4bpp). There is also a small 
possibility that text modes won't display properly either. If that does not 
happen and 4bpp pixel modes are not important to you, then it is well worth 
doing if you have a machine that does not provide an LFB-capable VESA BIOS 
and/or you play old LFB-unaware DOS games. Simply call VESAMTRR as follows to 
enable write combining to the VGA display memory area:

\DOS\DRIVERS\VIDEO\VESAMTRR -c=A000-BFFF

That will enable write combining for both the graphics cards VGA and linear 
frame buffer memory regions. The above is also useful under MS-DOS 7.x since 
that O/S does not enable write combing for the VESA banked and standard VGA 
memory access window either.

use "VESAMTRR -?" for more information on what it does.


UPGRADING TO A NEWER VERSION OF GVFM
====================================

Simply overwriting your old copy of GVFM.EXE with the newer version will 
perform the upgrade. Many new versions will however use an incompatible 
GVFM.CFG format and will not therefore allow you to use your old one, thus you 
will lose your GVFM settings. Not all need be lost though if you export your 
"File Associations" and "Start Menu" before you upgrade (ToolsExport menu), 
then import them (ToolsImport menu) after you have upgraded GVFM.EXE. A 
similar method can also be used to first save and then restore any custom 
colour scheme you have set up.


CONTACTING THE AUTHOR
=====================

Please tell me what you think of GVFM, good or bad, especially if it won't 
run on your DOS/Win9x/ME machine. GVFM was originally written purely as an 
example application of my Graphic Vision(tm) Pascal programmers API, and this 
is still its primary function, but it is now turning into a good product in 
itself. This version was built with a development Graphic Vision 3.xx. By the 
way, the code for GVFM.EXE is only about 650K (including the JPEG code). The 
rest of GVFM.EXE is comprised of resources (bitmaps, fonts, strings and 
codepage mapping tables mainly). Please don't hesitate to email me to let me 
know what problems you're having and what you like and don't like about it, 
and what features you would like to see it have (but be realistic!).

My aim is to eventually turn it into a powerful "DOS command centre", but 
the first goal is to make it at as powerful as the MS Windows "File Manager" 
program, which it now nearly is. My next job is to then add archive support 
with archives shown as directories, with their own sub-directories if the 
archive contains sub-folders.

Jason G Burgon

Email address:
  gvision@ntlworld.com

World Wide Web:
  http://homepage.ntlworld.com/gvision/

The above URL will always contain the most recent evaluation versions of 
Graphic Vision, GVFM and Bruce Ruona's Mahjongg! game. Mahjongg is an 
excellent example of what can be done with Graphic Vision - Like most GV 
applications, you'll find it hard to believe Mahjongg is a DOS program.

I also regularly hang out in the "DOS for(ever)um" discussion forum under the 
name of "Jaybur".

http://www.bttr-software.de/forum

Please feel free to join our happy little band to talk about GVFM or any other 
DOS related topic.

-- End of File
