«

HERE IS FOUND FANTASTIC IMPROVEMENTS IN PERFORMANCE!

The major discovery here is that there is a file found in the
Windows\System32 folder which when multiplied and stacked in a nest of
folders can hugely increase the computer's capacity to do many things
at once.

The believable part is that the files are already a big part of
Windows. The hard-to-understand part is that Microsoft has not
discovered the multiplication of these very-busy files, and increased
their value and function thereby.

The file called DISPLAY.SYS (16.7 KB) has a function described to me
as: "Here, hold this, and see if it needs to add or something, or
anything." This seems simple enough to be as valuable as it seems in
my estimation. I was shown that as many as three hundred and fifty of
these busy little rascals can be used to great advantage if we respect
their need to be not placed in the same folder containing another one
of the same function, even when they are renamed.

An ancillary file, which does help here, is called KEYBRD.SYS (33.7
KB) and has a description bearing the moniker of: "Oh that's just like
the scraps of cardboard we use just to tear up and scribble on, and
use for things." This appears mightily useful, if you ask me. He is
placed in his own folder, and is the only file visible on the "floor"
of the nested files as we open the chain to view the inner groups of
folders.

EGA.CPI (57.4 KB) has an added detail: she says, "I am the boss." She
is where they get their assignment and things, and as you may have
guessed: is only happy to work in her own folder insulated inside
still another folder, which she is leif to share. This configuration
was presented as being best after much use of different styles of
presenting these stacks of folders. The first folder visible in each
level, and named lowest (a) is the outer of the two which hold EGA.CPI
(renamed), with the visible KEYBRD.SYS file renamed to be the lowest
visible name (1), the folder holding a single KEYBRD.SYS (renamed)
should be the second (b). The third folder (c,) shows four folders
inside. Each may contain a DISPLAY.SYS (renamed again) alone, or also
have another folder, each with its own DISPLAY.SYS (16.7 KB). The
fourth folder (d) contains the next level, or nested set. The next two
folders (e&f) each contain a single DISPLAY.SYS.

As these folders may be stacked very deeply, it is wise to discover
here, that a depth of five folders gives optimum performance, and
finding that there is a limit to functionality according to the limits
provided in these parameters, that the innermost set of four
DISPLAY.SYS folders should not each contain another folder with
another file as the outer ones should. That these stacks should be
outside other folders is a given, the ones on the "floor" of each
drive would all contain a full set including each type of folder and
the KEYBRD.SYS renamed again, the lowest of all, and visible (as,
C:\ABABRD.SYS) The exception to the depth limit is when the files are
utilized in a Zipped format, and are left to run in the lower register
where files found in this directory will apparently overlap in a
conducive way more deeply. The number ten is given for the depth of
nested folders for files operated in this format, and as this was one
of the first styles in many attempts at producing a useful
configuration, the Zipped stack should remain in its .zip format. The
renaming of the inner files is less crucial here too, as the lower
directory renames them anyway for use, and only the name of the Zipped
folder itself need be made different for speed and stability in the
operating environment.

Here the various attribute settings of these files and folders should
be considered. They are all set to Archive, with the indexing service
toggled off. The only folder set to Read Only is the outer of the two
which isolate EGA.CPI under her new name(s). An inner one may be
selected to be redesignated Read Only AFTER the completion of the
placing of the files and folders has provided a working context in the
molar scenario for the correct inner file and-or folder to be
discovered.

I have had some experience with these changes staying resident pretty
much steadily on my Athlon 4 based Pavilion for over two years now,
and the only bad thing I can report is that handshaking apparently
everything with an internal clock on the worldwide web has made my
machine run at full gallop for an hour or two a couple of times when I
first set up my DSL line, and seemed to lessen when I installed a
better firewall (ZoneAlarm Pro).