3 ms·

I'd love to see the source code to the Win95 and Win98 file managers, maybe we can copy some of the performance tricks.

by zxzax 5y ago

jstimpfle 5y ago
The "trick" is to just run a loop over a list stored in RAM.
- zxzax 5y ago
  That seems to be over simplifying, every database is "just running a loop over a list stored in RAM." The challenge is in how you build that list, and then with a GUI the challenge becomes how to display it. Win95 had to run in very memory constrained environments compared to today so I'd imagine there is some special considerations there.
  - jstimpfle 5y ago
    I don't find there is a lot that could make sense to do. I believe computers running Win95 had like 16-128MB of RAM, it wouldn't be too wasteful for a file manager to store, say, 32-64K worth of cached file entries uncompressed in RAM. That could allow for maybe 1024 file entries (depending on the attributes that should be cached for each entry - more if we're really just storing a list of zero-terminated strings and maybe directory bits), which would already cover almost all realistic use cases at the time. So it's literally a loop over that in-RAM cache in most cases. It seems like e.g. FAT32 allowed for theoretically 64K entries per directory, but I find it unlikely that most programs would bother to optimize for that. One could just punt and allocate more memory dynamically in those cases until there is a Out-of-memory situation. Or one could page in the directory entries chunk by chunk (so, maybe 64 chunks max) on each update which would considerably slow down some operations of the program (such as scrolling, sorting, type-ahead, when any of those cross a chunk boundary), but still be acceptable as a rare occurrence. Or, if one specifically wanted to optimize for something like scrolling or type ahead, which are simple "linear movements", one could just keep this linear list (sorted according to user preferences / filters) in a cache file on disk. Streaming that in chunk-by-chunk is very fast as well, since you only need one disk access to get at the next chunk. I figure that would be way overkill for most practical requirements, but it still wouldn't be a lot of work to implement.

I'd love to see the source code to the Win95 and Win98 file managers, maybe we can copy some of the performance tricks.

by zxzax 5y ago

I'd love to see the source code to the Win95 and Win98 file managers, maybe we can copy some of the performance tricks.

jstimpfle 5y ago

The "trick" is to just run a loop over a list stored in RAM.

zxzax 5y ago
That seems to be over simplifying, every database is "just running a loop over a list stored in RAM." The challenge is in how you build that list, and then with a GUI the challenge becomes how to display it. Win95 had to run in very memory constrained environments compared to today so I'd imagine there is some special considerations there.
- jstimpfle 5y ago
  I don't find there is a lot that could make sense to do. I believe computers running Win95 had like 16-128MB of RAM, it wouldn't be too wasteful for a file manager to store, say, 32-64K worth of cached file entries uncompressed in RAM. That could allow for maybe 1024 file entries (depending on the attributes that should be cached for each entry - more if we're really just storing a list of zero-terminated strings and maybe directory bits), which would already cover almost all realistic use cases at the time. So it's literally a loop over that in-RAM cache in most cases. It seems like e.g. FAT32 allowed for theoretically 64K entries per directory, but I find it unlikely that most programs would bother to optimize for that. One could just punt and allocate more memory dynamically in those cases until there is a Out-of-memory situation. Or one could page in the directory entries chunk by chunk (so, maybe 64 chunks max) on each update which would considerably slow down some operations of the program (such as scrolling, sorting, type-ahead, when any of those cross a chunk boundary), but still be acceptable as a rare occurrence. Or, if one specifically wanted to optimize for something like scrolling or type ahead, which are simple "linear movements", one could just keep this linear list (sorted according to user preferences / filters) in a cache file on disk. Streaming that in chunk-by-chunk is very fast as well, since you only need one disk access to get at the next chunk. I figure that would be way overkill for most practical requirements, but it still wouldn't be a lot of work to implement.