
                                                                  July 87

            GETTING DOS TO OPEN 256 FILES SIMULTANEOUSLY!!
      TSR Programs, Source Code, Tutorial, Commentary and More...
                                  by
                             Steve Gibson

                              -*- -*- -*-

                version 2.0 (now works in BATCH files!)

           This file is divided into the following sections:
          ---------------------------------------------------
                 o  WHAT'S ON THE DISK
                 o  USING THE NEW "FILES" COMMAND
                 o  A BRIEF HISTORY OF THIS OFFER DISK
                 o  HOW THE PROGRAMS WORK
                 o  THE WRAP UP
          ---------------------------------------------------



                          WHAT'S ON THE DISK
----------------------------------------------------------------------
o  FILES.TXT - This file (the one you're reading now) describes the 
   contents of this "Steve's TSR Offer #1" diskette, and outlines the 
   use and operation of the included files and programs. 


o  TSR.TXT - This file is a complete tutorial introduction to the 
   technology and operation of Terminate and Stay Resident (TSR) 
   programs under MS/PC-DOS.  It was rewritten from Steve's original 
   four-part InfoWorld TECHTALK column series on TSR Technology.


o  Three SUB-DIRECTORIES:  FILES33, FILES3X, and OPENER.
   Each sub-directory contains the collection of files pertaining to 
   the COM file bearing the sub-directory's name.  See the details 
   which follow below:

   o  FILES33 is for use with DOS 3.3.  It was the first of these 
      programs to be written.  It "plays by the rules" by using only 
      fully documented techniques (well almost).  It also uses and 
      demonstrates the new handle requesting mechanism in DOS 3.3. 

   o  FILES3X is for use with all DOS 3.x versions EXCEPT the latest 
      3.3.  It uses a collection of undocumented (but well known) 
      techniques to achieve the same effect as the DOS 3.3 handle 
      count request mechanism.  As such it allows users of DOS 
      versions 3.00 thru 3.20 to have the same 256 file limit as 
      FILES33.COM gives to DOS 3.30 users. 

   o  OPENER is a test program which easily and quickly demonstrates 
      the working of the other programs.  It rapidly creates and opens 
      files whose names take the form !AAAA, !AAAB, !AAAC, !AAAD, etc.  
      It continues in this fashion, alphabetically advancing the file 
      names until the file creation request fails.  While doing this, 
      it counts the number of open files and displays their names and 
      handle IDs. 


o  RAM.COM - A "quickie" DOS command which displays the amount of RAM 
   currently available to a DOS application program.  It is useful if 
   given before and after loading any resident TSR program (like the 
   FILES command) to see how much memory that program consumes.
   It can ALSO be used IMMEDIATELY after booting DOS with various 
   settings of the "FILES=xxx" line in CONFIG.SYS to show how much RAM 
   is always being consumed by DOS's static file management buffers. 


To assist assembly language programmers who haven't yet conquered the 
mysteries of resident software programming, for those who wonder what 
assembly language programs look like, and to completely document the 
programs, this disk also includes heavily commented source code which 
takes a mild tutorial approach.  Additionally, BATCH files are 
included which can be used to drive the creation of COM files from the 
included assembly language sources. 

As mentioned above, the three subdirectories on the diskette (FILES33, 
FILES3X, and OPENER) contain the files relating to each COM program. 

---------------------------- PLEASE NOTE: ----------------------------
You should ONLY use ONE of the two FILES programs (FILES3X or FILES33) 
depending upon the version of DOS you're currently running.
----------------------------------------------------------------------


                           -*- -*- -*-



                     USING THE NEW "FILES" COMMAND
----------------------------------------------------------------------
The following are step-by-step instructions are for those who want to 
"get on with it" and perhaps read the rest of this OFFER_#1 file 
later.  The balance of this document contains a brief history of the 
programs and a complete functional and operational description of this 
package.  If you follow the instructions below you need NOT bother 
reading further.


                          FILES INSTRUCTIONS
----------------------------------------------------------------------
0. If you are NOT using a version 3 of MS-DOS or PC-DOS (DOS 3.00 thru 
   DOS 3.30) you MUST FIRST upgrade yourself.  NONE of the programs on 
   this disk (except OPENER which won't be of much use to you in any 
   case) will run under pre-3.00 DOS versions. 


1. COPY either FILES3X.COM or FILES33.COM from the appropriate 
   diskette sub-directory to your main working DOS command directory 
   RENAMING it to FILES.COM in the process.  If you ARE NOT USING DOS 
   version 3.3, copy the FILES3X.COM program.  ONLY IF you ARE USING 
   DOS 3.3, copy the FILES33.COM program.

   NOTE: The two programs could have easily been integrated into one, 
   but they were deliberately individualized to allow their individual 
   functionality to be seen more clearly.  This also minimized the 
   programs' resident portions (which is always a good thing). 


2. COPY OPENER.COM from the diskette's OPENER sub-directory to your 
   working DOS command directory. 


3. EDIT your current CONFIG.SYS file changing the "FILES=xxx" line of 
   that file (or adding one if you don't already have one) to reflect 
   the new total number of files you'd like to be able to have open 
   simultaneously.  Values of up to "FILES=255" are acceptable. 


4. REBOOT your computer to activate the new CONFIG.SYS file spec. 


5. CREATE a new sub-directory on a diskette or hard disk and make it 
   the current directory.  This will be a place for experimenting with 
   these commands which create and open MANY files.

   NOTE: The root directories of most floppy disks is not large enough 
   to hold as many files as you'll now be able to create and open, and 
   you wouldn't want the root directory of your hard disk junked up 
   with temporary files.  So do *EVERYTHING* in this sub-directory!


6. NOW, without first running FILES.COM, simply give the command 
   OPENER.  "Opener" will create files whose alphabetically sequential 
   names take the form: !AAAA, !AAAB, !AAAC, etc.  The screen will 
   display the number, name, and DOS handle (which you can ignore if 
   you're not into programming) as each file is created and opened.  
   It will STOP as soon as DOS refuses to Create or Open a file for 
   any reason.

   IMPORTANT NOTE: OPENER leaves these zero-length files in your sub-
   directory after it finishes!  This allows you to easily compare the 
   time required for many files to be Created versus Opened.  Users of 
   DOS 3.30 can also measure the benefits of DOS's new FASTOPEN 
   resident utility in this fashion. 

   TO DELETE THESE FILES: Give the command "DEL !AA*" which removes 
   all files of the form:  !AAxx  which OPENER creates. 


7. NOW, give the command "FILES".  A short message will print to the 
   screen and the DOS prompt will be returned.  BEFORE DOING ANYTHING 
   ELSE, give the OPENER command again.  If everything goes as 
   planned, the number of files you have requested in the FILES= line 
   of CONFIG.SYS will be Created and/or Opened. 

   NOTE: A few files FEWER than the number you requested with 
   CONFIG.SYS will probably actually be opened by OPENER owing to the 
   several file handles (for standard console Input and Output) which 
   DOS "pre-opens" for application software. 

   ALSO: The statement generated when FILES is installed may be 
   silenced by putting any argument AFTER the FILES command.  So 
   saying something like "FILES Shhhh" will keep FILES quiet.  This 
   may be useful in various BATCH file applications.




8. The included 89-byte "RAM" command displays the amount of main RAM 
   memory available to any application program (such as itself at the 
   time).  This is the same number returned by the DOS CHKDSK command 
   but is much faster.  It can be issued at various times to see 
   what's where.  For example issue the RAM command BEFORE the FILES 
   command and then IMMEDIATELY afterward.  Then subtract the results 
   to see exactly how much memory FILES uses.  Also, giving the RAM 
   command again AFTER running OPENER will show that the original 
   amount of memory available is again available, demonstrating that 
   FILES has successfully removed itself from memory after helping 
   OPENER to open many files.  (I like that spontaneous self removal)


                         TIPS USING FILES.COM
----------------------------------------------------------------------
As explained in further detail below, FILES.COM "goes resident" when 
run.  It can then be thought of as "TRIGGERING" the instant ANY 
program either CREATES or OPENS a file.  At the time of this 
triggering, it does things on behalf of whatever program caused the 
trigger, augmenting the maximum file handle count.  It then removes 
itself from RAM and allows the triggering application to proceed. 

This behavior implies several things which need to be made clear:

1. The FILES command MUST be given EVERY TIME BEFORE an application 
   program is run which may need simultaneous access to more than 20 
   files.  The effect of "FILES-izing" a program ONLY LASTS until that 
   program terminates. 

2. It is important not to trigger FILES before you want its effect.  
   Many programs which may not appear to be opening a file ... might 
   be ... so it's a good idea not to do ANYTHING between running FILES 
   and running the subject application.

                              -*- -*- -*-


                 A BRIEF HISTORY OF THIS OFFER DISK...
----------------------------------------------------------------------

I didn't know what I was getting into when it all began.....

A cover story in the May 18th issue of InfoWorld titled "DOS 3.3 Users 
Report Hard Drive Problems" caught my eye.  At the time, I was just 
finishing up the development of a new, extremely complex and exciting 
hard disk utility (written in 100% assembly code, the source code 
files for it total 340K Bytes!)  so I was attuned to issues relating 
to hard disk problems, and decided to find out what was going on. 

I spoke to the various people who were referenced in the story, 
explaining my connection to them as InfoWorld's TECHTALK columnist.  
Aside from satisfying my innate curiosity about this, I thought that 
there might be a "column" in all this as well.  The main issue raised 
in InfoWorld's story was that programs running under DOS 3.3 were 
*NOT* able to have more than 20 files open simultaneously, just as in 
all prior versions of DOS.  This seemed strange because one of the 
often mentioned enhancements to the new DOS 3.3 was supposed to be 
the raising of that limit to "256 files per process". 

IBM became involved in the dialogue when the story appeared, and upon 
questioning, indicated that programs needed to be REWRITTEN 
SPECIFICALLY to take advantage of this new feature.  Such programs 
must deliberately request access to more file "handles" using a new 
internal programming function available for the first time in DOS 3.3.  
IBM indicated that all existing DOS programs still aren't able to open 
more than 20 files because they don't know to ask for more handles 
using this new provision.  The new DOS 3.3 Technical Reference Manual 
makes this all very clear as well, indicating that programs requesting 
additional file handles must first free-up some of their own RAM space 
for DOS' use while fulfilling the program's request.  Clearly, real 
preparation and reprogramming is necessary even under this new DOS 3.3 

As always, the "FILES=" statement in the CONFIG.SYS file is the UPPER 
LIMIT on the number of files which may be simultaneously open.  If IBM 
had set FILES= to be the default, or had created another CONFIG.SYS 
parameter to set a "per program default" other than 20, then 
everything would have been just fine.

But that's not the way it happened.  So I started thinking about 
various ways to solve this problem using TSR resident software 
techniques.  This collection of files is the result of that thinking. 


                              -*- -*- -*-


                         HOW THE PROGRAMS WORK
----------------------------------------------------------------------
Whether we're using "FILES" under DOS 3.3 or an earlier version of DOS 
3.x, several things are necessary... 

Requests must be sent to DOS (requesting more handles) *DURING* the 
time that the application program is running.  This is necessary so 
that DOS will believe that it is the APPLICATION PROGRAM (not us) 
which is issuing those requests.  Also, a block of free RAM has to be 
available to the operating system when these requests are received by 
DOS.  The technologies of resident software easily fulfills these 
requirements. 

Application programs always receive ALL of the main memory the system 
has available.  This memory region extends from their loading location 
(the program's load point) up to the end of memory.  (Please see the 
file TSR.TXT included on this diskette for TSR operation details)  We 
grab a block of memory BEFORE the application program begins running, 
then release it just before making the "more handles please" request 
to DOS.  This way we're assured of having at least that amount of 
memory available to DOS when needed. 

The whole scheme comes together when we link into DOS' standard 
Interrupt 21h calling sequence.  This allows our program to monitor 
the running application  programs's use of DOS *AFTER* it has begun 
operating.  This monitoring connection allows us to gain control and 
intercede whenever our program decides it's necessary. 

                              --- --- ---


So now let's follow the entire sequence step-by-step... 


We begin by issuing the FILES command.

     ------------------------------------------------------------
      NOTE: Depending upon your current version of DOS, either 
      FILES33.COM or FILES3X.COM should be renamed to FILES.COM.
     ------------------------------------------------------------


FILES.COM runs, grabbing a small, 256-byte block of RAM memory and 
linking itself into the interrupt 21h chain.  "Linking into the chain" 
means that whenever a subsequent program makes a request of DOS via 
Interrupt 21h, OUR PROGRAM will receive control BEFORE DOS.  Once 
we're linked in and setup, we ask DOS to terminate us with a "TSR" 
call to DOS, which asks DOS to allow us to remain resident in memory. 

At this point we're lying dormant in RAM.  We're watching all DOS 
activity via our Interrupt 21h (Int 21) monitoring, but otherwise 
we're asleep.  We're waiting for any program to either CREATE or OPEN 
a file, at which point we spring into action.

Since DOS' own BATCH FILE processing performs OPEN calls to itself 
this would cause a "false pre-triggering" of FILES.  With the second 
version of this program (contained on this disk) FILES first awaits 
the DOS EXEC function call which "arms" the program for triggering on 
any subsequent OPEN or CREATE call. 

After we've been "armed" and a CREATE or OPEN occurs, we temporarily 
suspend that action.  Then we release the block of memory which was 
allocated by the transient portion of the TSR program when we were 
going resident.  DOS will find it and use it for maintaining the 
extended file handles table.  Then *WE*, in the guise of the 
application program, ask DOS to extend the file handle count limit.  
DOS does not knowing that this request is not originating from the 
application program, so it complies.  DOS searches through memory 
looking for a chunk of free RAM, finds our recently freed up block, 
and uses this memory to hold the additional handles we've just 
requested. 

Since we have now finished doing everything we were here for, we free 
up our own allocation of TSR memory, remove ourselves from the 
Interrupt 21h monitoring chain, and exit by passing the application's 
original request through to DOS. 


----------------------------------------------------------------------
  For assembly language programmers, the included and highly (overly) 
    commented source code contains the next level of detail on the 
                     operation of these programs.
----------------------------------------------------------------------




                              THE WRAP UP
----------------------------------------------------------------------

o  Well, I can't imagine anything I didn't say.
   (You probably can't either!) 

o  I hope you have found this package to be interesting, informative, 
   useful, and perhaps a bit educational. 

o  If you're interested in a more general discussion of the operation 
   of resident software, the file TSR.TXT is included here to provide 
   additional TSR background information.  It was rewritten from a 
   four-column series produced for my InfoWorld TECHTALK column.

o  If you didn't receive this diskette (or the files) directly from my 
   company, Gibson Research Corp., and you'd like to keep track of our 
   progress, developments, and future offers of this kind please feel 
   free to call with your name and address, or drop us a note or card 
   with it.  We'll be pleased to add you to our general mailing list 
   for all future offers and info.


Please phone or send your name and address to:
----------------------------------------------------------------------
                       GIBSON RESEARCH CORPORATION
                                 BOX 6024
                             IRVINE, CA 92716
                              (714) 854-1520
----------------------------------------------------------------------

Finally, thanks for your interest in this package!  Remember, it's in 
the PUBLIC DOMAIN and may be freely distributed, copied, uploaded, 
downloaded, etc. 

    PLEASE KEEP THE FILES TOGETHER AND IN THEIR ORIGINAL CONDITION. 



Steve Gibson, President
GIBSON RESEARCH CORP.


                          <<< END OF FILE >>>

