Scott's Disk

What You'll Find Here:

This site is the home for some Windows tools, most or all of which are run from a command prompt. If you don't even know what a command prompt is, you can still use the tools (but might find them ugly). What makes these tools unique is that they are programmed by an individual, known for his programming prowess. That tends to make the programs smaller and faster, and less likely that the tools will have issues like, say, using up all your memory (unless the program is supposed to!). Scott started programming in the 1980s, with constraints like less than 50,000 bytes of RAM, disks holding just 143,360 bytes, and computers 1/1000th of their current speed. Yet today, he goes where few venture -- 64-bit programming, programs that gather 400GB of data in a day or two, databases 18TB (500 billion records) in size, making 10,000s of Internet connections a second, dealing with millions of files on a hard drive, and sorting a billion pieces of information.

QuickSHA:

A simple tool that displays the SHA1 hash for a file. It will also accept multiple files, in which case it will show the SHA1 hash and let you know if they match.

Apple ][ DOS 3.3 Disk To HTML:

This online tool will let you upload an Apple ][ disc (5.25" disk in DOS 3.3 format), and will generate an HTML page showing you all sorts of information about the disc. It will show you the directory listing ('catalog'), a map of the disc tracks/sectors, what file each sector belongs to, the contents of each sector, and so much more. Better, it can in some cases even read in discs that Apple DOS 3.3 cannot read (by ignoring the CRC check), so that if a single byte is garbled, you'll be able to see the rest of the information in that sector.

ffind:

Ffind ('Fast Find') works just like the Windows/DOS 'find.exe' program from a command prompt, with two exceptions. First, it is much, much faster. Second, it allows recursion (looking within subdirectories), making it much more powerful.

Scott used to rely on the find program, which finds strings within files. But as file sizes grew to 10MB and larger, find got to be very, very slow. Upon investigating, there seemed to be no reason for this! Find was reading files much, much slower than it took to get them off the hard drive.

It appears that Find reads files a string at a time, using an expensive OS call each time. With Ffind, large blocks are read into memory at a time, reducing the OS calls that eat up so much CPU time. As a result, Ffind is lightning fast, searching files about as fast as they can be read from the hard drive -- and even faster if you re-search the same file(s) if they are cached by Windows.