Dec 072017
Allows the use of 256 open files. From Spinright author (Gibson).
File FILE256.ZIP from The Programmer’s Corner in
Category Assembly Language
Allows the use of 256 open files. From Spinright author (Gibson).
File Name File Size Zip Size Zip Type
FILES33.ASM 16129 5187 deflated
FILES33.COM 347 314 deflated
FILES3X.ASM 18004 5616 deflated
FILES3X.COM 406 366 deflated
MAKE33.BAT 105 59 deflated
MAKE3X.BAT 105 59 deflated
MAKEOPEN.BAT 90 55 deflated
OFFER_#1.TXT 18559 6792 deflated
OPENER.ASM 10619 3812 deflated
OPENER.COM 331 308 deflated
RAM.COM 89 89 stored
READ_ME 1864 713 deflated
TPCREAD.ME 199 165 deflated
TSR.TXT 18971 7469 deflated

Download File FILE256.ZIP Here

Contents of the OFFER_#1.TXT file

July 87

TSR Programs, Source Code, Tutorial, Commentary and More...
Steve Gibson

-*- -*- -*-

This file is divided into the following sections:

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.

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.

-*- -*- -*-

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.

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)

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.

-*- -*- -*-


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.

-*- -*- -*-

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

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.

When the 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.


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:
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.


Steve Gibson, President

<<< END OF FILE >>>

 December 7, 2017  Add comments

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>