RAM Doubler 2 (1996)
tidbits.com
tidbits.com
By contrast, I remember people putting swap files (most prominently the Win386 one) into straight RAMDISKs, which should really just give you a net negative effect all across the board.
Many low footprint Linux installations now include swapping to zram, which is compressed. The net effect is positive since you usually have an abundance of spare CPU cycles.
Contemporary world of various DOS extenders is completely different ball game to the extent that typical DOS extender was more complete operating system implementation than what classic MacOS ever hoped for.
I played doom II with 4MB on a 386DX40. We had a DOS 6 boot menu to not load smartdrv. It ran good enough, except on the last level, where all the different enemy types caused all their graphics to be loaded at the same time. That was too much, and caused severe disk trashing (not swapping, DOOM managed the disk on its own).
doom used less memory, so it should have been good enough.
https://www.cnet.com/news/memory-compression-brings-ram-doub...
> https://en.wikipedia.org/wiki/Virtual_memory_compression#His...
When I worked at MS I heard some chatter about people doing it with NT circa 2010 (I guess per this wikipedia article it didn't ship until five years later). Then after I left I heard there were Linux patches from before that (wikipedia cites 2008, with it being in the mainline tree in 2013). And then later, that Apple had also done it.
It's interesting that a bunch of major operating systems decided to do this roughly the same time.
I'm guessing it's due to the popularity of 64-bit address space. There are lots of pointers in RAM, and while they use a lot of bits, they don't have much entropy. So they probably compress extremely well, and with compression, give one less reason to stick to 32-bit architecture. (I don't fully understand why, but I hear that people run 32-bit OSes on 64-bit machines to save memory. As long as one process uses less than 4G of RAM, maybe it's the right optimization. But memory compression certainly changes that calculus and gives the OS vendors one less use case to have to support a 32-bit OS for.)
It seems at least plausible to save time by compressing pages in memory rather than going to disk. Certainly for low end or consumer systems not blessed with gobs of RAM.
Such a thing exists:
https://en.wikipedia.org/wiki/X32_ABI
It's been available in the mainline Linux kernel and in glibc for ages. It also breaks any code which assumes #ifdef __x86_64__ means 64-bit pointers, and the concept doesn't seem to attract a lot of excitement:
I wonder how much of an effect SSDs have on that balance.
(Intel's selling their new NVDIMMs as providing much better latency figures than SSDs, especially if you read a cache line out at a time instead of a whole page. Be nice to see the things and their pricing.)
Instead of a general LZ compressor Apple's stuff uses a word-at-a-time algorithm called WKdm, and there are others (there's one on GitHub called centaurean/density for example). Hardware can help--Samsung had a memory compressor in some chips and Qualcomm's server ARM chips used compression to avoid bottlenecks in memory bandwidth (but not increase capacity). Fun stuff, seems like somewhere more progress could be made.
WAIS rocked, too bad gopher beat it.
Of course, the real horror is that NCSA added the img tag to their gopher browser, and now it's the end of the Internet (news at 11).
https://en.wikipedia.org/wiki/Hotline_Communications
Which was another strange Mac app from that era.
I was surprised to find there are still a couple of Hotline servers running out there! Someone also took control of the hltracker.com domain so just launching the original app still gets you a server list.
I also tried installing RAM Doubler, but it refuses to initialize when you have 256 MB of RAM installed ("you don't need RAM Doubler" it said)
Back in the day I was a bigger fan of Speed Doubler though. It had neat stuff like a multi-threaded Finder copy.
It is an interesting story, see https://en.wikipedia.org/wiki/SoftRAM
It really brought back to me just how many shareware and freeware utilities there were that changed how some very fundamental parts of the system worked. I've replaced the behaviors of window rendering (Kaleidoscope, Power Windows), text rendering (SmoothText), scrolling (Smart Scroll), drag and drop (Gravite), menus (Menutasking enabler), etc etc. Also how unstable everything becomes once you do that!
It really was the wild west and it's still fun to play with.
But I'm glad to have forgotten about handles and Carbon and having to buy your compiler -- remember Metrowerks CodeWarrior? Well, I was excited at the time.
I still remember the pure JOY I felt when I found an utility that could format floppies to store 1722 KB!
Shoutout to Stacker, which did transparent disk compression in DOS, copied by MSFT as DiskDoubler. https://en.wikipedia.org/wiki/Stac_Electronics
Back then we did it because RAM was expensive, and there was rarely enough. Today we use it because RAM is plentiful, and swapping to RAM is much faster than swapping to disk.
Because of the way that classic MacOS (mis)managed memory, you (as in the user) had to specify how much memory was allocated to each program before you ran it and the memory had to be contiguous. It was easy to end up in a situation where you had plenty of free RAM but it was fragmented and you had to quit programs to free up enough RAM.
RAM Doubler for the Mac helped alleviate that by “doubling” the amount of RAM the system saw and then managing the memory by a combination of allocating memory dynamically in the “System” partition and compressing memory.
Another benefit of RAM Doubler for the PPC was that it could enable virtual memory (ie the modern nomenclature not just “disk swapping”) without allocating as much space on the disk.
Kind of surprising in 1995. I didn't think that many people had internet access. Then again, power users probably did, who would be customers of RAM Doubler.
I remember Windows 95 or 98 have some original tool to free up the memory as well.