4 ms·

My favorite program in DOS was smartdrv.exe. I know it’s much more late addition, but it was a game-changer for these slow hard drives. Even a tiny cache size (

by wruza 2y ago

My favorite program in DOS was smartdrv.exe. I know it’s much more late addition, but it was a game-changer for these slow hard drives. Even a tiny cache size (I believe I tried kilobytes range) sped up things like 10-20x. Even windows 3.x and 95 (surpisingly) ran faster with smartdrv preloaded. 95’s default cache for some reason was worse than smartdrv and literally produced harder sounds on my hdds. The second favorite was a TSR NG viewer, can’t remember the name.

skissane 2y ago
> The second favorite was a TSR NG viewer, can’t remember the name. I know what a TSR is, but what's an "NG viewer"?
- wruza 2y ago
  Norton Guides, iirc. E.g. Ralf Brown Interrupt List was available in it. Reading the docs without leaving an editor made programming much easier.
  - anyfoo 2y ago
    I sometimes wistfully look back to the days where I had a bunch of books and printouts open on my desk for programming. Of course, that's more than likely romanticizing things quite a lot...
    - kelnos 2y ago
      I remember in middle school I had the giant Visual Basic 3 book, and it was... amazing, but looking back, super annoying to deal with, always having to lug it around, dig through the table of contents and index to find what I was looking for, etc. So much easier now to just type a query into a search engine.
anyfoo 2y ago
> and 95 (surpisingly) ran faster with smartdrv preloaded. 95’s default cache for some reason was worse than smartdrv My (weak) guess is that you "32 bit disk access" and "32 bit file access" wasn't active then, i.e. Windows 95 did not use its native 32 bit disk drivers, but 16 bit BIOS access. I have a hard time seeing how Smartdrv could have done anything otherwise, unless it really had some tight integration with 32 bit Windows (which would be very surprising, it's a 16 bit TSR first and foremost). But yeah, overall, I agree, it's surprising what even a tiny cache does. If you just manage to eliminate the seek times to the root directory for pretty much every single access to a new file, that can probably do a lot already. Especially in the days before "native command queuing", where the HD would try to reorder disk accesses to find a better (physical!) head seek path across the platter. Later HDs had some cache on board.
hulitu 2y ago
> My favorite program in DOS was smartdrv.exe. The downside was, that in case of a crash, you will use some data.
- wruza 2y ago
  I was aware of that, but somehow it never happened, maybe got lucky. Smartdrv itself never crashed, and neither program crashes nor electricity issues affected it. Ofc I always used ctrl-alt-del before turning the pc off. It’s interesting what others experienced, cause I remember nothing about that in fido echoes (someone should have lost some data eventually). Was smartdrv even that different from today’s caching algorithms on all OSes?
- Joe_Cool 2y ago
  If you had stuff that often crashed there was a write-through mode so it only did read caching. In one of the later versions it also trapped CTRL-ALT-DEL and did a sync before rebooting. It also did a sync each time command.com displayed a prompt. Really some neat coding for its time.

by wruza 2y ago

skissane 2y ago

> The second favorite was a TSR NG viewer, can’t remember the name. I know what a TSR is, but what's an "NG viewer"?

wruza 2y ago
Norton Guides, iirc. E.g. Ralf Brown Interrupt List was available in it. Reading the docs without leaving an editor made programming much easier.
- anyfoo 2y ago
  I sometimes wistfully look back to the days where I had a bunch of books and printouts open on my desk for programming. Of course, that's more than likely romanticizing things quite a lot...
  - kelnos 2y ago
    I remember in middle school I had the giant Visual Basic 3 book, and it was... amazing, but looking back, super annoying to deal with, always having to lug it around, dig through the table of contents and index to find what I was looking for, etc. So much easier now to just type a query into a search engine.

anyfoo 2y ago

> and 95 (surpisingly) ran faster with smartdrv preloaded. 95’s default cache for some reason was worse than smartdrv My (weak) guess is that you "32 bit disk access" and "32 bit file access" wasn't active then, i.e. Windows 95 did not use its native 32 bit disk drivers, but 16 bit BIOS access. I have a hard time seeing how Smartdrv could have done anything otherwise, unless it really had some tight integration with 32 bit Windows (which would be very surprising, it's a 16 bit TSR first and foremost). But yeah, overall, I agree, it's surprising what even a tiny cache does. If you just manage to eliminate the seek times to the root directory for pretty much every single access to a new file, that can probably do a lot already. Especially in the days before "native command queuing", where the HD would try to reorder disk accesses to find a better (physical!) head seek path across the platter. Later HDs had some cache on board.

hulitu 2y ago

> My favorite program in DOS was smartdrv.exe. The downside was, that in case of a crash, you will use some data.

wruza 2y ago
I was aware of that, but somehow it never happened, maybe got lucky. Smartdrv itself never crashed, and neither program crashes nor electricity issues affected it. Ofc I always used ctrl-alt-del before turning the pc off. It’s interesting what others experienced, cause I remember nothing about that in fido echoes (someone should have lost some data eventually). Was smartdrv even that different from today’s caching algorithms on all OSes?
Joe_Cool 2y ago
If you had stuff that often crashed there was a write-through mode so it only did read caching. In one of the later versions it also trapped CTRL-ALT-DEL and did a sync before rebooting. It also did a sync each time command.com displayed a prompt. Really some neat coding for its time.