DOS ain't dead

On Wikipedia I found a link to the "SST - Seek Stopper Hard Disk Optimizer", a very early defrag utility, which has been released to the public domain in 2005 (?).
It was written in Turbo Pascal 3.0, but, due to its age, only supports partitions <32 MiB. So be careful!

I didn't try running or building this tool. Maybe it's useful to someone.

Homepage w/ sources: http://www.spectrum-research.com/V2/projects_sst.asp
Shareware binary: sst201.zip

---
Forum admin

> On Wikipedia I found a link to the "SST - Seek Stopper Hard Disk
> Optimizer", a very early defrag utility,

Very interesting find. See also Alfred's informative page about DS Optimize which is what SST became - sadly currently without the source!

> It was written in Turbo Pascal 3.0,

which (for anyone who doesn't know) is now freely available from "Borland's museum" which is now here: http://edn.embarcadero.com/museum - a nice easy to remember URL.... or search "Borland Museum"

> I didn't try running or building this tool. Maybe it's useful to someone.

The same author of SST; Alfred J. Heyman has also kindly made the source available for at least one other program: BigShell for autocad (ASM/C source) See also other project tabs for interesting background on his other legacy programs (without source) and newer systems. Thanks Alfred!

> > On Wikipedia I found a link to the "SST - Seek Stopper Hard Disk
> > Optimizer", a very early defrag utility,
>
> Very interesting find.

Yet another (Turbo) Pascal gem: "defrag 10 MB HD in 8 minutes", no small feat considering the slow cpus of the day! Even though it's limited to 32 MB (FAT12), it's still interesting.

To be honest, (on a semi-related note) I wonder why more tools don't use the FAT directly for greater speed. I guess nobody wants to write their own FAT12/16/32-specific routines (reinvent the wheel), esp. when direct sector access won't work under Windows anyways. Charles Dye's LOCATE does, though, providing greater speed. (I also wonder if some DOS extenders would benefit from this, e.g. wouldn't be limited to 64k at a time when reading from files.)

> > I didn't try running or building this tool. Maybe it's useful to
> someone.

Well, we do have FreeDOS Defrag, which supports other FATs (-16, -32), albeit slowly, but this is a good alternative for reference.

> The same author of SST; Alfred J. Heyman has also kindly made the source
> available for at least one other program:
> BigShell
> for autocad

Now this is confusing. I guess the larger code size (32-bit) meant less conventional memory free, thus his need to work around it. I didn't really look too closely, but I'm blindly guessing his shell (when run first) saves the state then "restores" it by dumping out / overwriting AutoCAD in memory. (What DOS extender did AutoCAD use? Most good ones allow you to configure to use EMS or XMS, reducing conventional memory, if needed.)

> What DOS extender did AutoCAD use? Most good ones allow you to
> configure to use EMS or XMS, reducing conventional memory, if needed.)

It uses PharLap 386. There's CFIG386.EXE for some runtime settings of its EXE files.

---
DOS gives me freedom to unlimited HW access.

> On Wikipedia I found a link to the "SST - Seek Stopper Hard Disk
> Optimizer", a very early defrag utility, which has been released
> to the public domain in 2005 (?) ...

I have used the 1998 "Diskeeper" for Windows/NT for over 10 years,
which functions similarly to "SST".

Disk "defragmenter" programs can gain a bit faster hard-disk speed
by re-arranging data, so no "big" seeks are necessary when reading
existing files. All sectors of a file are on the disk in "linear
order", thus extra seeks are avoided.

Disk "defragmenters" do NOT help when writing files, as DOS cannot
guarantee new files' sectors are written linearly. DOS will give
files the next "free" group of FAT-table sectors, which themselves
may not be in linear order! So multiple output files are usually
written "fragmented", i.e. part of file "A", then part of file "B"
etc.

Also, "defragmenters" made sense in 1986, when hard-disks had seek
times of about 5-msec on 1-track seeks and 30- to 50-msec averages
for the entire hard-disk. These times are 1-msec and 4.5-msec on
"modern" hard-disk drives offered now!

So, a "defragmenter" gets you only so far in improving disk speed.

After a disk has been defragmented, one still needs a disk caching
program with DOS. DOS must still access the disk's directory and
FAT tables for any file, and DOS is written for only single-sector
directory I-O. Reading/writing disks one sector at a time is NOT
efficient, as it LOSES a disk revolution between each sector pair!
Hard disks CAN do multi-sector I-O, but DOS still has its original
1981 "El Cheapo" directory handling, which slows EVERYTHING down!!

Such accesses are mostly eliminated if UIDE (or LBAcache/CDRcache,
if appropriate) is used to CACHE directory and FAT data! Actual
file data will ALSO be cached, and thus a DOS system will run even
faster. FAT, directory, or file data that is "in cache" requires
only a fast move from XMS memory (the cache), NOT a slow "physical
access" of the hard-disk, diskette, or CD/DVD drive.

DOS users should have BOTH a "defragmenter" AND a caching program!

---
(Account disabled on user's request.)