Phoenix CD 2.0/Phoenix_CD.cdr/15a/nav11.zip/HISTORY.NAV

Text File | 1989-06-04 | 20KB | 403 lines

History of Navstar:
Christopher R.S. Schanck
364 W. Lane Ave #635
Columbus OH 43201
614-421-7051

1986: name is currently "See"
-----

     Original concept, implemented in assembler. No colors, DOS
IO used throughout. Copy, Delete, Backup, Mark, Log and Change
Directory were the only functions implemented. Only 3k in length,
but no command execution, sorting or ANYTHING! Good way to learn
about assembly language though.

Spring 1988:
------------

     TurboC 1.0 acquired. TC used to implement serial port device
drivers; this served as a good intro to TC. I was just about to
write my own color console IO package when version 1.5 was
announced. I received my upgrade at the start of the summer, and
conversion from the assembly language version began in earnest.

     It took about two weeks to convert it into TC; several
enhancements were made out of turn at this time. While the
original assembler version could only handle 144 files, period, I
added the multi-page capability to it, giving it the effective
capability to handle an unlimted number of files. It was color
now, but not much more added over assembler version, and nearly
20k in length! I was disappointed. The only real tough part of
this was figuring out the cursor routines; the wraparounds were a
bitch!

    Now it was time to explore TC's manual and see what
functionality I could add. Sorting was simple; I used TC's
library quicksort routine to sort by name or extension. Sorting
by size, and in descending order were added later. Exploring the
manual further gave me access to TC's system() and spawn()
routines, which are tougher than they should be to utilize. A lot
of work went into verifying executable names, and having Navstar
find file extension's prior to executing. Passing "xxx.dat" to
spawn() as a file to execute makes TC go blooey!

    Now I added things with impunity; free space, time, file
information line, time and date, the make and delete directory
functions (long overdue!!!), and the view. This was over several
weeks, with some serious debugging going on as I added functions
at a furious rate. Adding the view function got me motivated to add
more definable keys, finally arriving at 20 as a good number.
This gave me the capability to use it intensively in its own
development; debugging progressed much faster as it got used more
intensively. During the intensive use at this stage that the Swap
Directories command demanded inclusion.

     At this point I was using the small memory model; this now
became a liability as the memory handling when executing other
programs is restrictive. I did some spleunking in the manual and
switched to the compact model. Navstar now consumed only ~48k
when executing other programs.

December 1989:
--------------

     Name changed to "Navstar"; it just felt right. After a 6
month hiatus of work on Navstar, I was again reunited with my
computer. Some purusal of local BBS's and magazine reviews led me
to the conclusion that most file managers were "cotton-ball"
programs; they protected the user from DOS. This was clearly not
the orientation of Navstar. Discussion with colleagues revealed
that Navstar was indeed different from most. Also, it became evident
that few other shells allowed the user to run other programs
*efficiently*. Usually such execution was an afterthought. In
purusing 8 shareware and commercial packages, I found each held
and average of ~130k when running another program. One such program,
selling for ~$50, consumed ~210k!!! Navstar was clearly going to
be different here also.

     With my purchase of TC 2.0, I began work on making Navstar
commercially viable. A rudimentary installation program had been
written; it was now totally revamped. Taking a super idea from
other shells, recognizable file extensions were implemented. The
flexibilty of the definable keys was expanded. Miscellaneous
functions were added, such as Refresh, Order direction, Delete
with Individual Verification, and such were added. Three major
functions, Text Search, Edit Attribute Mask, and Attribute, were
added.

    Finally, about three weeks were spent simply bumming code and
making Navstar more efficient. A lot of time was spent with map
files and such, but it was worth it. A good deal of tweaking
and bumming of code got the memory usage down to 42k when executing
programs. I judged it would be worthwhile to release it to the
world. Finally, out of the file extensions came the concept of
the Action key.

    The last thing done was to write documentation. This was a
dilemma, since I wanted to market it as shareware. I could not
afford large documentation since it would push the transmission
size up too high. So, minimal docs were written which covered all
major points but left a good deal of the little things to the
user. Eventualy, I hope to have a seperate set of docs available
for registered users which will be much more complete.

Version 1.0 Released
--------------------

     So, on Sunday 2/5/89, I released Navstar 1.0 as Shareware by
uploading it to several local BBS's; it subsequently found its
way onto Compuserve. I also mailed copies of it to friends of
mine over the Internet computer network, hoping for favorable
results. Currently, I am holding my breath.

Future Possibilities as of 2/5/89:
---------------------------------

     Several things loom on the horizon for Navstar. First is the
inclusion of a handful of useful file manipulation utilities such
as list, a grep, and whereis, etc. This is due to the fact that
while I have access to public domain type software, many people
cannot afford the time needed to go hunting for such software.

     Another is the inclusion of a "Goto" function. In this, by
pressing 'G', the user would give a directory name, such as
"utils", and Navstar would find "utils" in the directory tree
structure and go there. Multiple occurrences would be handled by
giving the user a list of choices. I suspect this will be more
efficient to implement than the already rejected visual tree. It
will only be added if I can keep Navstar's memory usage to within
5k of what it is now.

     EMS support is a hopeful, as is support for the 43 and 50
line modes of the EGA and VGA cards. But these will wait until I
have access to such toys!!!

Febuary 15 1989:
----------------

     The last two weeks were spent doing some interesting things. Fixed
some bugs:
   - in Navinst, making some values non-multiples of 256 caused some
   erroneous results.
   - in Navstar, hitting return on file with an unrecognized extension
   marked the file, but didn't bother to notify the user, rendering its
   use impossible until it was unmarked. Bothersome.

     Some tweaking got the memory consumption down to 39k; this gave
rise to thoughts of new features. So I started work on a standalone,
command-line utility caled "ccd" for Chris's Change Directory (modest,
huh?). The idea was to type "ccd xxx" where "xxx" was a subdirectory
entry. Note I said entry, not path. So for a path \turboc\c\ccd, typing
"ccd ccd" from any other entry would change the directory to
\turboc\c\ccd. If there were multiple occurances, you would be offered a
choice. The volume info would be saved in a file in the root directory.
From here I eventually evolved the current version of "ccd", and I
intend to release it with the next release of Navstar.

     When I had a satisfactory version of "ccd", I started work on
incorporating it into Navstar. Instead of "Goto", I settled on "Jump".
The memory management concerns were large, since I had to allocate the
directory information before the files info, else I would not get the
memory back for program execution. I also had to allow for additional
entries, the deletion of entries, and a few other bits of dynamic
allocation. This led to lots of other parameters for Navinst to handle.
But it is a helluva useful feature!

     Originally I had Navstar always scan the directory structure to
build its directory list, but it seemed like too much wear and tear
on the disk. But using the stream IO functions was costly in terms of
space, so to use the data file from CCD would mean buffering IO myself,
and supplying the logic necessary. At first I thought this would be
space inefficient, but it turned out to be simply tedious. When done,
all told it took merely 3k more than verison 1.0, with settings for 256
directory entries.

     The modifiers for commadn-line interpretation were changed a bit.
"overlay" became "ovl", "chdir" became "chto", "chback" stayed the same,
and "chcurr" was added; it changes the current directory to match the
logged directory. This allows the use of directory changing programs
(similar to CCD!).

     Finally, I am considering making all program execution being done
by a call to system() rather than spawnlp(). I think I can save enough
code by delteing the parsing routines to offset the mandatory 3k a call
to command.com entails. Next week, maybe. Note: I eventually judged
this to be a bad idea.

     Mouse support has been considered; several users have said Navstar
is a natural for such an interface. Me, I don't know. I don't own one of
the beasties, but if enough users want it, I'll explore it. 43 and 50
line mode are on my list.

Febuary 20, 1989
----------------

     Some inspiration led to some fun things. I wrote a small shell
program (<8k of ram) called Navshell which allows you to really
skimp on RAM. If you wish, you could, for instance, put the
actual Navstar program on a Ramdisk, say, tell Navshell where it is
with the NAVSTAR environment variable, and it will be reloaded in
between other programs. This is especially useful if you have a Ramdisk
which can make use of extended/expanded memory. You lose a few things.
Since EACH program is essentially in overlay form, the (ovl) and (nop)
switches have no effect; Navstar will appear to always pause after a
program executes. Also, you don't have the last execute line saved, like
normal. Finally, Navstar must read the directory structure from disk
upon each invokation. Still, on a '286 or '386 system with a quick hard
drive, it will probably be a screamer. It is reasonable on my 4.7Mhz
system, so it should really fly on a faster system.

     CCD has been changed a tad; the -r flag just updates the file; no
changing takes place. This allows it to be "hung" off of a key in
Navstar and be used to update the disk file.

     After a week of fairly heavy use, the "Jump" command has proved
itself super-nice. I can no longer use the old version; I am addicted to
that 'J' key!

Febuary 26, 1989
----------------

     Now that was fun; I wrote a complete new set of low-level screen
i/o routines fr use with Navstar. The routines provided by Borland are
failry nice, but a little too complete. They include code for window
support in every function. This code was a sizable waste of space
consider Navstar's architecture. So I wrote a set customized for
Navstar, and saved abut 3k. This nicely offset the space taken up by the
Jump addition, so memory consumption (at least for my personal version)
is at 44k. This will of course vary depending on the number of
directories Navstar is set up to handle.

     To aid in this configuration, I added yet another little (7k)
utility. CCDCOUNT gives the user a count of files, directories, and
average files per directory for a specific drive. Several users had
requested this. Granted, you can get the same info, or nearly so, from
chkdsk, but still.

     Support for the 43 and 50 line modes of the EGA and VGA are much
more feasible now, since the screen IO functions were written in-house.
I am also toying with expanding the Jump function to be trans-disk;
currently you can only Jump to a directory on the currently logged
drive. I may change this in the future.

     I still have yet to find a file-manager even approaching Navstar's
power which consume less than 90k when run in non-overlay mode. In
overlay mode, using Navshell, my 7k is about par for the course.

     Oh, I am considering including a version of Navstar which will run
as a TSR program. Since spawning a program from a TSR is a bitch, it
would not include this capability. This would seriously cut down on its
size, since all the code supporting extensions, command parsing, etc
would go bye-bye. Problem spots include managing memory for file
entries, and for the copy buffer. We shall see... Finally, a new screen
format is in the works, with 110 files per screen, instead of the
current 88 file maximum. I have found a way to do so with no loss of
information presented; I will add the attribute information on the file
info line. Should work. I just can't decide if I like it...

Febuary 27 1989
---------------

     I integrated CCDCOUNT into CCD; added the '-c' switch. Also, some
memory management changes were made to Navstar. None of these changes
should be noticable to the user, excepting that Navstar now reads
Jump information in much faster. Also, memory consumption was pruned
a little more.

     Several folks who have seen the latest version and played with the
Jump command are urging me to simply make it trans-disk, and have it
replace the New Directory command. This seems to make sense to me, and
it would probably cut out some more code; always a good thing. However,
there are still some concerns; namely, where will the directory info
files be kept? Since a single file should, ideally, have all the info
for all available volumes, this would also mean updating CCD quite a
bit. Food for thought.

    CtrlJ now updates the directory jump information by invoking CCD
with the '-r' flag; it then reads in the info from the updated file.
Currently, Navstar keeps track of all directory updates, even though
they are not reflected in the data file. For instance, if you use the
'M'ake Directory command, the internal data list is updated but not the
external. Since the overhead to update the list on disk seems a waste to
me (directory structures don't change all that often), I may cut out
this code just to save space. Time will tell...

     Finally, some people have asked me to implement the selection portion
of the Jump command into a visual directory tree; I will think on it...

March 1 1989
------------

     Lots of cosmetic changes. 'Edit Attribute', formerly mapped to the
'E' key, is now mapped to Control A. This allowed the 'E' key to be
mapped to an Edit command line, similar to the way View is handled. This
meant adding another command definition to Navstar and Navinst, but it
was relatively trivial. And welcome.
     The TAB key, which formerly marked and moved, now is mapped to the
search function along with Control S. I did this because I added a
Marking mode, toggled by the Insert key. When toggled, the current entry
and all others over which the cursor is moved have their marked
attribute flipped. If the entry was marked it is unmarked, and if it was
unmarked it is marked.

April 14, 1989
--------------

     Again, more than a few small changes. Some of the screen routines
were coded into assembler, and are consequently much faster. Also,
things were cleaned up so it should work on just about any display
adapter you might happen to have. And damn, they are quick!!! Another
command line expansion option, (..), was added. This has the effect of
adding the name (not the full pathname) of each of the marked files to
the command line in the designated place. This is especially useful for
editing, so that several filenames may be edited at once.
     As soon as I track down a bug in the directory scan routine, I will
be releasing a new version. For some reason, the machine locks up when
reading in directory info on some volumes. This has been a pain to
debug, since I haven't been able to replicate the situation here. Ah
well, It will come.

April 20, 1989
--------------

     Ok, the nasty bug has been eradicated. A poor choice of
termination conditions allowed the machine to really go bonkers
for certain tree structures. Also, before I release the next
version, a few things are going to be added. A state file,
containing pertinent info, will be saved prior to termination and
read in before execution; this will be of prime use when the
Navshell shell is being used. A few more details remain to be
cleaned up with the jump function, but they are minor.
     It is now the next day, and the state file has been added,
jump function prettied-upped, and a few other niggling
difficulties taken care of. Time to write the docs for version
1.1!!!!!!!
     Navshell and Navstar have been altered so that they work better
together. At this point, there is nothing Navstar alone can do
that Navshell cannot, albeit a bit slower. The reason for the
performance loss is that Navshell is a good deal more disk
intensive. If you have a speedy hard disk, Navshell is the way to
go.
     Several beta copies of 1.1 have been sent out; very little is
holding me back from releasing this version. But the creepy
feature creature is at it again, and I am currently wrestling
with the idea of implementing multiple directry views. This
seems to be very simple to do in light of the program's
structure, I just haven't yet found justification to do it. Yes,
it could be done, but would it be useful? Maybe in 1.2 ...
     Little, rare bug in copying fixed, makes it impossible to
copy a file onto itself. Minor, but scary that it went this far
unnoticed.

May 19, 1989
------------

     Added another little function to the file extension
recognizer code.  Navstar now allows the addition of an extension
'.***'.  This matches any extension not matched by a previous
extension in the list, as well as matching for files with no
extension.  I mapped it to my file lister program, since most
files without a recognized extension are worth looking at at
sometime or another.  Very handy.

May 24, 1989
------------

     Working on a 'Disklist' program.  This will allow you to
list every file on your disk, with what path it resides in.
Currently it works, but no sorting of files or directories yet.
This is harder than it sounds, because memory is dynamically
allocated to save space.  To sort them, I need to calculate the
space needed in each case, copy the data to static storage, then
deallocate the old copies.  Not trivial.
     Next day.  Disklist is very slick.  Sort by extension, size,
name, or date; coding date enabled me to add sorting by date to
Navstar. Disklist can display files per directory, just
directories, or all files on disk, using any sort criteria.
Nifty.  'Disklist ?' brings up a list of options.  One of these
days I have to stop coding and release the next version, don't
you think?
     Changed Navstar slightly so it can no longer generate
a jump table on its own; the user will have to run CCD -r or hit
Ctrl-J in order to construct it.  This made internal logic much
nicer, and made me happier, as this chunk of code never gets
used.
     Made some internal changes as to how Navstar handles batch
execution which resulted in a new execution modifier, (sys).
This can be used to force Navstar to call COMMAND.COM when it
executes a command line, giving easy access to DOS's internal
commands and IO redirection capabilities.
     Found a small bug that disallows the (sys) modifier from
executing an internal DOS command.  A few versions with this bug
have been released by mistake.

May 30, 1989
------------
Navstar 1.1 Frozen and Released