>>>>>I am getting a "Too Many Files Open" error when running an application written in VFP 5.0. The FILES statement in the CONFIG.SYS file is set to 40. I thought Windows 95 and Windows 95 applications ignored the FILES statement. Have I been mislead? Should I increase the FILES statement?
>>>>Completely remove the line or set higher.
>>>>Cetin
>>>
>>>Try: FILES = 100
>>> BUFFERS = 40
>>
>>Setting the buffers this way is a -BIG- mistake; an incorrect value can radically change the conventional memory footprint of the underlying DOS for Win95/Win98, resulting in some interesting and annoying problems when running some 16 bit applications. The reasons for this are simple - Win95 by default attempts to load a segment of DOS into the HMA (the first 64K beyond the 1MB address mark. It will allocate buffers for real mode I/O (the BUFFERS= statement) in the HMA as well as long as there is enough room to allocate all the buffers there. Depending on the underlying DOS version, the number of buffers that can be loaded there will run somewhere between 32-38.
>>
>>If there isn't adequate space to allocate buffers in the HMA, the buffers are moved to the top of the conventional memory address space. This is an all or nothing move - either all buffers are allocated in the HMA, or they all reside in the conventional memory address space. At 528 bytes/buffer, you end up eating over 20K of conventional RAM out of each VDM using a value of BUFFERS=40! Since 16 bit WinApps share a single VDM, this means that the base memory allocation for all 16 bit WinApps gets affected; you get silly 'Out of memory' errors more frequently with multiple 16 bit WinApps because of the way 16 bit apps attempt to allocate certain types of memory.
>>
>>This also affects the ability to load the infinitely more important applications like DOOM in a VDM, since it affects their memory allocations, too... :-)
>>
>>And now, the really bad news - unless you are forced to run in compatibility mode, where disk I/O goes through the BIOS and DOS interface rather than through a protected driver, the allocations of buffers has no effect on the Win95 file system's performance. Buffering and caching are managed by the 32 bit disk I/O system, and never touch the DOS buffer space in the HMA or conventional RAM with protected mode disk drivers loaded. The only times where the allocation of buffers to DOS is significant are (1) when disk I/O is forced to use a BIOS service because of incompatibility (some older disk compression and drive overlay software can prevent Win95 from using protected mode, but in almost all cases newer versions of the software is available, or the functionality isn't needed under Win95), (2) running in Safe Mode (no protected mode disk I/O subsystem is loaded, so all disk access is via the INT 13 interface) or (3) when running in Win95's single DOS session mode, which unloads all
>>the Win95 functionality.
>>
>
>And so, can you give some alternatives. You hang-up us here...

Sure. The simple starting position, assuming that you already know that you're not running in compatibility mode, is to either remove the BUFFERS= statement entirely, or at least reduce it to a number that doesn't eat conventional memory - either dink around a bit and find the value for the operating system version you're running (it varies for DOS 7.0 and 7.1 versions between 32 and 38, as I mentioned) or simply use a value of 32 or less. Using a value of 32 has minimal impact, even running in compatibility mode, has minimal effect compared to a BUFFERS=40 value.

Second, do what needs to be done to run in protected mode. Update older drive compression software to newer, fully supported versions, or better, eliminate them entirely; drive compression hurts disk performance in any case. If you must use compression under Win95, use DriveSpace 3 from the Plus Pack or included in later OSR 2.x versions, since it is fully supported and handled by the Win95 protected mode drivers.

Update or remove drive overlay software. Drive overlay software is an unfortunate consequence of trying to use older systems whose BIOSes aren't capable of supporting the full size of hard drives available today. If you have an older system without LBA support and a drive >528MB, or a more recent system without large drive support and a drive larger than 2GB, you need either a BIOS update or drive overlay software. IMO, a BIOS upgrade is preferable to drive overlay software, since it handles more operating system environments than drive overlay software, and normally adds or extends the functionality of the motherboard. There -is- drive overlay software that will not force you into compatibility mode; at a mninimum, the current commerical products like Disk Manager and Drive Rocket are fully Win95/Win98 compatible, and they cost no more than BIOS upgrades would.

Check your system to see if the drive overlay software is really needed before spending money on a new BIOS or new drive overlay software; several manufacturers, notably Seagate and Western Digital, ship their drives with the overlay software installed, even though you might not need it with a relatively current system. With systems having LBA support, you can use up to a 2GB drive without resorting to overlay software in all cases; more recent systems (systems with BIOSes dated from about the middle of last year at least, and just about all systems based on Intel's 430TX, 440LX and 440BX chipsets, as well as offers based on the Via VP2, VP3 and mVP3 chipset that use the PIIX4 or PIIX6 IDE chips) have support for drives up to 8GB without the need to resort to overlay software. You can (and should) check with your motherboard vendor to see if a Flash BIOS upgrade is available for your system to add extended drive support as well.

SCSI-based systems should simply use a Win95-based protected mode driver rather than older real-mode ASPI layers; AFAIK, all of the major HAs are well-supported without the need for drivers in CONFIG.SYS if you follow the HA vendor's installation instructions. This is definitely the case with Adaptec, BusLogic and Diamond's HAs, although many system integrators don't follow the vendor's procedures for eliminating the real-mode drivers. In the case of Adaptec, BusLogic and Diamond, there is no functionality available via the real-mode driver set that isn't duplicated by the HA's .mpd and WNASPI.DLL, and the BIOSes of all three are capable of supporting booting from drives up to at least 8GB without overlay software, which will get you to the point that the .mpd can load.

If you're worried about SIngle DOS Session MS-DOS mode, realize that you can (and should) have a separate CONFIG.SYS and AUTOEXEC.BAT for that environment. Win95 gives you the ability to specify such via the property sheet of shortcuts starting SDS MS-DOS, and some utilities like WinHacker and TweakUI will let you maintain these settings as well.

HTH,

Ed