WEBVTT 00:00:00.000 --> 00:00:02.000 So welcome to the deep dive. We're going to try 00:00:02.000 --> 00:00:05.240 a little thought experiment to start us off today. 00:00:05.679 --> 00:00:08.900 I want you to imagine it's the early 1990s. A 00:00:08.900 --> 00:00:11.000 very different computing landscape back then. 00:00:11.099 --> 00:00:13.080 Oh, completely. You've got your computer, and 00:00:13.080 --> 00:00:15.699 the hard drive is, I mean, it's a mere 20 to 00:00:15.699 --> 00:00:19.980 80 megabytes, which is nothing today. And expanding 00:00:19.980 --> 00:00:24.239 it costs a staggering $10 per megabyte. Yeah, 00:00:24.239 --> 00:00:27.079 which was a huge barrier for, well, Pretty much 00:00:27.079 --> 00:00:29.739 everyone. Exactly. So what do you do? Do you 00:00:29.739 --> 00:00:32.920 empty your wallet for a new drive or do you turn 00:00:32.920 --> 00:00:36.359 to this almost magical software wizardry from 00:00:36.359 --> 00:00:39.060 the 90s known as disk compression? Because that's 00:00:39.060 --> 00:00:41.299 our mission today. We are exploring this technology 00:00:41.299 --> 00:00:44.320 that seemingly just double a computer's physical 00:00:44.320 --> 00:00:46.460 storage out of thin air. It really did feel like 00:00:46.460 --> 00:00:48.500 magic to users back then. I mean, you have to 00:00:48.500 --> 00:00:50.280 remember software was rapidly getting bigger 00:00:50.280 --> 00:00:52.920 and physical storage was incredibly expensive. 00:00:53.119 --> 00:00:55.880 Right. OK, let's unpack this. Because the idea 00:00:55.880 --> 00:00:58.000 of just downloading space sounds impossible. 00:00:58.100 --> 00:01:01.399 I always picture it like a magical suitcase. 00:01:01.539 --> 00:01:04.579 You have the suitcase, and the exact second you 00:01:04.579 --> 00:01:07.400 pack your clothes into it, it automatically shrinks 00:01:07.400 --> 00:01:09.219 them down to half their size. That's a great 00:01:09.219 --> 00:01:11.560 way to visualize it. Right. And then the second 00:01:11.560 --> 00:01:13.739 you pull a shirt out, it instantly expands back 00:01:13.739 --> 00:01:16.519 to its normal size. And the wild part is you 00:01:16.519 --> 00:01:18.659 never even have to press a compress button. It 00:01:18.659 --> 00:01:21.500 just happens. And that automatic nature is what 00:01:21.500 --> 00:01:23.790 grounds your analogy. in the actual technical 00:01:23.790 --> 00:01:26.549 reality of our sources, because we really need 00:01:26.549 --> 00:01:29.569 to establish the difference between standard 00:01:29.569 --> 00:01:32.950 file compression and true disk compression. Which 00:01:32.950 --> 00:01:35.230 are two very different beasts. Right, completely. 00:01:35.489 --> 00:01:37.849 With file compression, like zipping a file, it's 00:01:37.849 --> 00:01:39.890 interactive. You manually tell the system to 00:01:39.890 --> 00:01:42.189 pack it up, and you manually tell to extract. 00:01:42.810 --> 00:01:45.230 But disk compression was totally non -interactive. 00:01:45.290 --> 00:01:47.549 It operated entirely in the background. It was 00:01:47.549 --> 00:01:50.040 on the fly, completely transparent. and happened 00:01:50.040 --> 00:01:52.760 in real time. So the user, and I guess the software 00:01:52.760 --> 00:01:55.239 they were running, had no idea this was even 00:01:55.239 --> 00:01:57.739 happening. Exactly. Your word processor, your 00:01:57.739 --> 00:02:00.099 games, they didn't know they were asking for 00:02:00.099 --> 00:02:02.480 compressed data. They just asked the system for 00:02:02.480 --> 00:02:04.640 a file. And the disk compression utility would 00:02:04.640 --> 00:02:07.299 grab it, decompress it instantly, and hand it 00:02:07.299 --> 00:02:10.930 over. OK, so how did it actually pull off? this 00:02:10.930 --> 00:02:13.550 illusion because you're basically creating physical 00:02:13.550 --> 00:02:16.810 space using only software. Well, it did this 00:02:16.810 --> 00:02:19.610 by essentially hijacking the file access layer 00:02:19.610 --> 00:02:22.229 of the operating system. When you installed one 00:02:22.229 --> 00:02:25.110 of these utilities, instead of saving thousands 00:02:25.110 --> 00:02:28.009 of individual files scattered all over the physical 00:02:28.009 --> 00:02:30.069 magnetic platters of your hard drive. Which is 00:02:30.069 --> 00:02:32.509 how it normally works. Right. Instead of that, 00:02:32.830 --> 00:02:35.610 the software created a single massive hidden 00:02:35.610 --> 00:02:38.180 file on the host drive. They usually called it 00:02:38.180 --> 00:02:40.919 a virtual drive. So every single thing you saved 00:02:40.919 --> 00:02:43.479 was secretly being compressed and stuffed directly 00:02:43.479 --> 00:02:46.580 into this one giant monolithic file by a special 00:02:46.580 --> 00:02:48.819 device driver. Wait, if everything is living 00:02:48.819 --> 00:02:51.719 inside one giant hidden file, doesn't that mean 00:02:51.719 --> 00:02:54.080 the computer is basically lying to the user about 00:02:54.080 --> 00:02:56.620 what a drive even is? What's fascinating here 00:02:56.620 --> 00:02:59.219 is that yes, the computer was entirely abstracting 00:02:59.219 --> 00:03:01.810 reality. It was a complete deception. Yeah, the 00:03:01.810 --> 00:03:04.729 setup process was wild. The utility would first 00:03:04.729 --> 00:03:08.389 create this empty virtual drive, which again, 00:03:08.569 --> 00:03:11.949 is just one massive hidden file. And then it 00:03:11.949 --> 00:03:14.330 would systematically transfer almost all of your 00:03:14.330 --> 00:03:16.789 files from the physical host drive into that 00:03:16.789 --> 00:03:18.629 compressed file. Wait, you said almost all. Did 00:03:18.629 --> 00:03:21.370 it leave some stuff behind? It had to. You couldn't 00:03:21.370 --> 00:03:24.199 compress vital system files. specifically the 00:03:24.199 --> 00:03:28.120 swap file. Because if you compress the swap file, 00:03:28.360 --> 00:03:30.759 which manages virtual memory, the computer would 00:03:30.759 --> 00:03:33.159 basically lock up trying to decompress its own 00:03:33.159 --> 00:03:35.580 working memory to function. So it leaves that 00:03:35.580 --> 00:03:37.120 alone, moves everything else into the hidden 00:03:37.120 --> 00:03:39.479 file, and then it simply inflates the reported 00:03:39.479 --> 00:03:41.300 size of that virtual drive. So it just tells 00:03:41.300 --> 00:03:43.020 the computer, hey, look at all this free space 00:03:43.020 --> 00:03:45.460 I suddenly have. Exactly. It reports the expanded 00:03:45.460 --> 00:03:48.199 theoretical size, leaving the operating system 00:03:49.060 --> 00:03:51.379 totally oblivious to the real physical limits. 00:03:51.580 --> 00:03:54.439 But, I mean, if the entire C drive is secretly 00:03:54.439 --> 00:03:57.060 just a hidden file on the physical drive, how 00:03:57.060 --> 00:03:59.419 does the computer even wake up? Like, when you 00:03:59.419 --> 00:04:01.979 turn a PC on, it needs to read the C drive to 00:04:01.979 --> 00:04:04.379 boot, but if the drive is fake and the driver 00:04:04.379 --> 00:04:06.860 needed to read it is locked inside the fake drive, 00:04:06.879 --> 00:04:09.020 that's... Well, it's a total chicken and egg 00:04:09.020 --> 00:04:11.840 problem. It is a massive paradox. And solving 00:04:11.840 --> 00:04:14.000 it required some incredible sleight of hand during 00:04:14.000 --> 00:04:16.420 the boot sequence. Let's look at the historical 00:04:16.420 --> 00:04:19.120 DOS boot process from the sources to see how 00:04:19.120 --> 00:04:21.759 they trick the system. OK, lay it on me. So you 00:04:21.759 --> 00:04:24.259 press the power button. The system BIOS wakes 00:04:24.259 --> 00:04:26.360 up and it looks at the very first sector of the 00:04:26.360 --> 00:04:29.319 hard drive, the master boot record, or MBR. Right, 00:04:29.480 --> 00:04:31.920 the absolute baseline hardware level. The MBR 00:04:31.920 --> 00:04:34.910 then loads the volume boot record. which in turn 00:04:34.910 --> 00:04:38.209 loads the DOS BIOS. These are hidden system files, 00:04:38.529 --> 00:04:43.069 usually iOSYS or IBMBIO .com. At this stage, 00:04:43.269 --> 00:04:45.769 DOS is loading into basic memory, but, and this 00:04:45.769 --> 00:04:48.009 is the crucial part, it hasn't loaded the config 00:04:48.009 --> 00:04:50.730 -dos -sys file yet. Meaning no third -party drivers 00:04:50.730 --> 00:04:52.790 are loaded. The computer still thinks the physical 00:04:52.790 --> 00:04:55.370 hardware is the real C -DRAF. Exactly. And if 00:04:55.370 --> 00:04:56.970 it kept booting normally, it would just crash, 00:04:57.230 --> 00:04:59.310 because all the user files and the rest of the 00:04:59.310 --> 00:05:02.470 OS are trapped inside that unreadable compressed 00:05:02.470 --> 00:05:05.629 monolith. So how did they bypass the crash? In 00:05:05.629 --> 00:05:09.230 MS -DOS 6 .0, Microsoft introduced an undocumented 00:05:09.230 --> 00:05:12.009 challenge response interface known as the Preload 00:05:12.009 --> 00:05:14.790 API. Here's where it gets really interesting, 00:05:14.949 --> 00:05:17.970 because I picture this like intercepting the 00:05:17.970 --> 00:05:20.089 computer's morning coffee. The machine is just 00:05:20.089 --> 00:05:22.170 waking up going through its groggy morning routine, 00:05:22.449 --> 00:05:25.009 and this Preload API just steps in front of it. 00:05:25.129 --> 00:05:26.970 That's a perfect way to put it. Right after the 00:05:26.970 --> 00:05:30.089 DOS BIOS loads, but literally milliseconds before 00:05:30.089 --> 00:05:32.790 it reads the user's config files, the system 00:05:32.790 --> 00:05:36.370 pauses. It scans the root directory for specific 00:05:36.370 --> 00:05:39.490 preload drivers, files like dblspace .bin or 00:05:39.490 --> 00:05:41.730 stacker .bin. So compression drivers? Right. 00:05:41.790 --> 00:05:44.170 And if it finds one, it initiates this secret 00:05:44.170 --> 00:05:47.069 handshake. If the driver gives the correct mathematical 00:05:47.069 --> 00:05:50.370 response, the system loads it into memory immediately, 00:05:50.870 --> 00:05:53.110 completely bypassing normal configuration. And 00:05:53.110 --> 00:05:55.870 what does the driver do once it's in? It immediately 00:05:55.870 --> 00:05:58.620 executes a radical maneuver. It literally swaps 00:05:58.620 --> 00:06:01.639 the drive letters in the system's RAM. It swaps 00:06:01.639 --> 00:06:03.939 them. So it puts on a mask and says, hey, look 00:06:03.939 --> 00:06:07.079 at me. I am the C drive now. Yes. The physical 00:06:07.079 --> 00:06:09.620 drive is shoved aside, usually reassigned to 00:06:09.620 --> 00:06:12.399 a random letter like H, and the fake compressed 00:06:12.399 --> 00:06:15.269 file is mounted and declared the C drive. And 00:06:15.269 --> 00:06:17.750 from that millisecond on, the computer finishes 00:06:17.750 --> 00:06:20.410 its morning coffee, completely oblivious that 00:06:20.410 --> 00:06:22.889 its entire reality was just remapped. That is 00:06:22.889 --> 00:06:25.930 just wild. But I mean, tricking the computer's 00:06:25.930 --> 00:06:28.009 brain and stuffing literally all your data into 00:06:28.009 --> 00:06:31.490 a single hidden file sounds incredibly risky. 00:06:31.589 --> 00:06:33.790 Like, what were the unintended consequences of 00:06:33.790 --> 00:06:35.430 doing this? Because this has to have a catch. 00:06:35.550 --> 00:06:37.509 Oh, there were several massive catches. But before 00:06:37.509 --> 00:06:39.689 we even get to the data disasters, we have to 00:06:39.689 --> 00:06:42.329 talk about the performance paradox. OK. You'd 00:06:42.329 --> 00:06:44.509 naturally assume that forcing a computer to do 00:06:44.509 --> 00:06:47.589 complex math to compress and decompress every 00:06:47.589 --> 00:06:50.009 single file in real time would make the whole 00:06:50.009 --> 00:06:51.509 system sluggish. Right, yeah. I mean, you're 00:06:51.509 --> 00:06:54.930 giving the CPU a massive extra chore for every 00:06:54.930 --> 00:06:58.319 single task. The sources show it actually depended 00:06:58.319 --> 00:07:00.899 on where your bottleneck was. If your system 00:07:00.899 --> 00:07:03.620 was CPU -bound, meaning the processor was already 00:07:03.620 --> 00:07:06.420 struggling to keep up with basic tasks, then 00:07:06.420 --> 00:07:08.680 yes, disk compression slowed everything to a 00:07:08.680 --> 00:07:10.980 crawl. The math was just too heavy. So it was 00:07:10.980 --> 00:07:13.560 just choking the processor? Right. But if your 00:07:13.560 --> 00:07:15.339 system was IO -bound, meaning you had a fast 00:07:15.339 --> 00:07:18.439 processor, but a really slow physical hard drive. 00:07:18.480 --> 00:07:20.439 Which was pretty common back then, waiting for 00:07:20.439 --> 00:07:23.000 the physical platters to spin. Exactly. For those 00:07:23.000 --> 00:07:25.800 IO -bound machines, disk compression actually 00:07:25.800 --> 00:07:28.279 increased overall performance. Wait, really? 00:07:28.500 --> 00:07:31.180 It made the computer faster? How? Because there 00:07:31.180 --> 00:07:33.420 was physically less data to read and write from 00:07:33.420 --> 00:07:36.279 the slow mechanical drive, the fast processor 00:07:36.279 --> 00:07:39.040 could read a tiny compressed file from the disk 00:07:39.040 --> 00:07:42.079 and decompress it in RAM significantly faster 00:07:42.079 --> 00:07:43.939 than the slow hard drive needle could read a 00:07:43.939 --> 00:07:46.560 massive uncompressed file. Oh, wow. So the math 00:07:46.560 --> 00:07:48.560 was actually faster than the physics of the spinning 00:07:48.560 --> 00:07:51.100 disk. That's brilliant. But obviously, performance 00:07:51.100 --> 00:07:54.579 aside, the risks to your actual data had to be 00:07:54.579 --> 00:07:57.579 astronomical. They were. The nightmare scenarios 00:07:57.579 --> 00:08:00.240 usually began with a very simple user action, 00:08:00.939 --> 00:08:03.220 trying to uninstall the software. Because it's 00:08:03.220 --> 00:08:06.930 a trap. A total trap. If your expanded uncompressed 00:08:06.930 --> 00:08:09.769 data exceeded the physical size of the actual 00:08:09.769 --> 00:08:12.529 hard drive, uninstallation was mathematically 00:08:12.529 --> 00:08:15.370 impossible unless you deleted enough files to 00:08:15.370 --> 00:08:17.629 fit back into reality. You literally couldn't 00:08:17.629 --> 00:08:19.990 escape the virtual space you built. Exactly. 00:08:20.649 --> 00:08:23.689 And it gets worse. A massive danger lurk during 00:08:23.689 --> 00:08:26.620 the initial setup phase. The compression utility 00:08:26.620 --> 00:08:29.439 relied completely on the integrity of your drive's 00:08:29.439 --> 00:08:32.059 FAT file system to move your data safely. The 00:08:32.059 --> 00:08:34.519 file allocation table, basically the index card 00:08:34.519 --> 00:08:36.740 catalog for where data lives on the disk. Right. 00:08:36.960 --> 00:08:39.659 So if your drive had pre -existing errors, particularly 00:08:39.659 --> 00:08:42.019 something called cross -link files, where two 00:08:42.019 --> 00:08:44.399 files accidentally claim the same physical cluster 00:08:44.399 --> 00:08:46.860 on the disk, the results were catastrophic. Uh 00:08:46.860 --> 00:08:48.860 -oh. Because the setup program is sweeping through, 00:08:49.019 --> 00:08:51.259 grabbing clusters, compressing them, and then 00:08:51.259 --> 00:08:53.960 what? Deleting the originals to save space? Yes. 00:08:54.190 --> 00:08:56.629 It would compress the cluster for the first file, 00:08:56.870 --> 00:08:59.649 delete the original, and move on. So when it 00:08:59.649 --> 00:09:01.129 eventually got to the second file that claimed 00:09:01.129 --> 00:09:04.970 that exact same physical space, the data was 00:09:04.970 --> 00:09:08.309 already gone. Oh, man. Massive data loss during 00:09:08.309 --> 00:09:10.149 the initial transaction. Massive. It would corrupt 00:09:10.149 --> 00:09:12.149 files and could even destroy the virtual translation 00:09:12.149 --> 00:09:14.750 table itself, ruining the entire drive before 00:09:14.750 --> 00:09:17.009 the installation even finished. Which leads to 00:09:17.009 --> 00:09:20.169 my biggest question. What happened if a user 00:09:20.169 --> 00:09:22.399 was just, you know, poking around their hard 00:09:22.399 --> 00:09:24.700 drive, making hidden files visible, and they 00:09:24.700 --> 00:09:27.720 saw the suspiciously massive file eating up basically 00:09:27.720 --> 00:09:30.639 100 % of their space, what if they just deleted 00:09:30.639 --> 00:09:32.980 it? I mean, that is the most human error of all. 00:09:32.980 --> 00:09:35.480 Yeah. Because the file was hidden, but curious 00:09:35.480 --> 00:09:38.100 users often found it. And because they didn't 00:09:38.100 --> 00:09:40.440 grasp the abstraction, they didn't realize that 00:09:40.440 --> 00:09:42.740 one file was their entire operating system, and 00:09:42.740 --> 00:09:44.940 all their personal data, they'd hit Delete to 00:09:44.940 --> 00:09:47.600 free up space. Oh. Total annihilation. Deleting 00:09:47.600 --> 00:09:49.840 that one file meant losing every single thing 00:09:49.840 --> 00:09:52.299 stored on the compressed drive instantly. Just 00:09:52.299 --> 00:09:55.580 boom, your whole digital life is gone. But despite 00:09:55.580 --> 00:09:59.299 that risk, people still used it because, well, 00:09:59.480 --> 00:10:01.899 it was either this or shell out hundreds of dollars 00:10:01.899 --> 00:10:04.879 for a new drive. Exactly. The high cost of hard 00:10:04.879 --> 00:10:07.299 drives made this software an absolute necessity, 00:10:07.299 --> 00:10:10.019 which sparked a massive multi -million dollar 00:10:10.019 --> 00:10:12.379 industry arms race. So let's talk about that 00:10:12.379 --> 00:10:15.259 arms race because the tech really had to evolve 00:10:15.259 --> 00:10:17.710 to keep up, right? It did. In the early days, 00:10:17.970 --> 00:10:20.490 CPUs were just too weak to handle the math. So 00:10:20.490 --> 00:10:22.470 the first solutions were actually hardware -assisted. 00:10:22.590 --> 00:10:24.789 Oh, like physical add -on boards? Yeah. Companies 00:10:24.789 --> 00:10:27.230 like Stack Electronics with their stacker product, 00:10:27.610 --> 00:10:31.029 or InfoChip Systems with Expanse, they sold physical 00:10:31.029 --> 00:10:33.330 coprocessor boards that plugged into the motherboard. 00:10:33.970 --> 00:10:36.490 These had custom chips designed specifically 00:10:36.490 --> 00:10:38.690 to do the compression math, taking the load off 00:10:38.690 --> 00:10:41.850 the main CPU. But eventually processors got faster, 00:10:41.889 --> 00:10:44.509 like the 486 and the Pentium? Right. And once 00:10:44.509 --> 00:10:47.080 the CPUs gained enough power, the hardware boards 00:10:47.080 --> 00:10:50.240 became obsolete. Software -only solutions completely 00:10:50.240 --> 00:10:53.399 took over the market. We saw programs like Squish, 00:10:53.779 --> 00:10:56.879 Superstore, and DoubleDisk dominating. And computer 00:10:56.879 --> 00:10:58.820 resellers loved this, right? I mean, they were 00:10:58.820 --> 00:11:01.200 bundling this software onto PCs just to claim 00:11:01.200 --> 00:11:03.059 their computers had more storage without actually 00:11:03.059 --> 00:11:04.919 buying bigger hard drives. Oh, it was a massive 00:11:04.919 --> 00:11:07.340 marketing gimmick. And the operating system developers 00:11:07.340 --> 00:11:10.700 caught on quickly. Digital research bundled Superstore 00:11:10.700 --> 00:11:14.240 into DockerDOS 6 .0, and Microsoft bundled DoubleSpace, 00:11:14.679 --> 00:11:17.500 which licensed DoubleDisk Tech into MS -DOS 6 00:11:17.500 --> 00:11:19.580 .0. Okay, I wanted to ask you about this because 00:11:19.580 --> 00:11:21.740 there's a very curious detail in the sources. 00:11:22.120 --> 00:11:25.559 I see that MS -DOS 6 .22 bundled a program called 00:11:25.559 --> 00:11:28.039 DriveSpace, but the version right before it, 00:11:28.100 --> 00:11:31.179 MS -DOS 6 .21, shipped it with no compression 00:11:31.179 --> 00:11:34.120 software at all. And the sources mention legal 00:11:34.120 --> 00:11:36.580 reasons. What does that tell us about the climate 00:11:36.580 --> 00:11:39.330 back then? Impartially speaking, without getting 00:11:39.330 --> 00:11:41.649 into the weeds of the specific patent lawsuits, 00:11:42.330 --> 00:11:44.769 that gap in MS -DOS versions really highlights 00:11:44.769 --> 00:11:47.330 how intensely competitive and legally fraught 00:11:47.330 --> 00:11:49.350 this industry had become. I mean, it was virtual 00:11:49.350 --> 00:11:52.159 real estate. Exactly. Companies were aggressively 00:11:52.159 --> 00:11:54.639 patenting their algorithms and their integration 00:11:54.639 --> 00:11:57.299 techniques. It was a highly lucrative market. 00:11:57.679 --> 00:12:00.700 And the fact that a flagship OS like MS -DOS 00:12:00.700 --> 00:12:03.240 had to temporarily strip out its biggest feature 00:12:03.240 --> 00:12:06.500 shows you just how fierce the legal battles over 00:12:06.500 --> 00:12:08.399 this intellectual property were. Right. Everybody 00:12:08.399 --> 00:12:10.769 wanted to own the rights to thin air. And the 00:12:10.769 --> 00:12:13.389 technology was getting incredibly advanced before 00:12:13.389 --> 00:12:15.950 the whole industry eventually collapsed. For 00:12:15.950 --> 00:12:19.009 instance, the sources detail how Novell DOS 7 00:12:19.009 --> 00:12:22.389 bundled a DPMS -enabled version of Stacker. What 00:12:22.389 --> 00:12:24.909 does that mean for the user? It meant that if 00:12:24.909 --> 00:12:27.610 you had Stacker on your local machine and Stacker 00:12:27.610 --> 00:12:30.370 on a remote network server, they could exchange 00:12:30.370 --> 00:12:32.830 data packets across the network while keeping 00:12:32.830 --> 00:12:35.200 them compressed. Wait, so they didn't have to 00:12:35.200 --> 00:12:37.879 uncompress the file, send it, and recompress 00:12:37.879 --> 00:12:40.460 it? They just sent the shrunken version. Exactly. 00:12:40.779 --> 00:12:42.700 Which effectively doubled the network bandwidth. 00:12:42.879 --> 00:12:45.019 It was a brilliant use of the technology to speed 00:12:45.019 --> 00:12:47.700 up entire local area networks. That's actually 00:12:47.700 --> 00:12:50.740 amazing. So what does this all mean for the listener 00:12:50.740 --> 00:12:54.080 today? I mean, where did all this fiercely contested 00:12:54.080 --> 00:12:57.980 tech actually go? Because we don't buy box software 00:12:57.980 --> 00:13:00.639 to double our drives anymore. It essentially 00:13:00.639 --> 00:13:03.970 faded into disuse by the late 1990s. Hard drive 00:13:03.970 --> 00:13:07.230 manufacturing advanced so rapidly and the cost 00:13:07.230 --> 00:13:10.350 per megabyte dropped so low that physical storage 00:13:10.350 --> 00:13:12.990 became incredibly cheap. So it just didn't make 00:13:12.990 --> 00:13:15.429 sense to risk your data with a virtual drive 00:13:15.429 --> 00:13:18.450 anymore. Right. But the DNA of the technology 00:13:18.450 --> 00:13:22.149 absolutely survives today. Windows still supports 00:13:22.149 --> 00:13:25.350 NTFS compression, which blends traditional file 00:13:25.350 --> 00:13:27.950 compression with those transparent on the fly 00:13:27.950 --> 00:13:29.649 concepts we just talked about. So it's still 00:13:29.649 --> 00:13:31.820 running in the background. Yeah. And the open 00:13:31.820 --> 00:13:34.279 source community kept the legacy alive too. LENX 00:13:34.279 --> 00:13:37.460 developers created drivers like DMSDS specifically 00:13:37.460 --> 00:13:40.080 to read those old 90s stacker and double space 00:13:40.080 --> 00:13:42.659 volumes preserving that history. Which is pretty 00:13:42.659 --> 00:13:45.360 cool. It just quietly became part of the background 00:13:45.360 --> 00:13:47.879 architecture of how we compute. Which actually 00:13:47.879 --> 00:13:49.919 leaves us with a really fascinating final thought 00:13:49.919 --> 00:13:52.279 to mull over today. Yeah, because for an entire 00:13:52.279 --> 00:13:54.580 generation of computer users, disk compression 00:13:54.580 --> 00:13:57.080 was their very first introduction to the concept 00:13:57.080 --> 00:13:59.960 of virtualization. It was the first time we learned 00:13:59.960 --> 00:14:01.879 that the hardware you think you're interacting 00:14:01.879 --> 00:14:04.399 with, the space, the folders, the drive, can 00:14:04.399 --> 00:14:07.240 actually just be a software illusion. That's 00:14:07.240 --> 00:14:08.960 a really good point. It completely decoupled 00:14:08.960 --> 00:14:11.460 the physical reality from the digital experience. 00:14:11.879 --> 00:14:15.840 Exactly. So, as you go about your day today, 00:14:16.360 --> 00:14:18.759 you look at your cloud storage or use virtual 00:14:18.759 --> 00:14:22.279 machines or log into simulated environments, 00:14:22.759 --> 00:14:25.480 ask yourself, how much of your current digital 00:14:25.480 --> 00:14:28.559 world is actually real physical hardware? And 00:14:28.559 --> 00:14:30.940 how much is just a modern version of a giant 00:14:30.940 --> 00:14:33.440 hidden file pretending to be a hard drive? Something 00:14:33.440 --> 00:14:35.659 to think about. Definitely. We'll leave you with 00:14:35.659 --> 00:14:37.539 that. Thanks for joining us on this deep dive.