WEBVTT 00:00:00.000 --> 00:00:01.800 I want you to close your eyes for a second. Go 00:00:01.800 --> 00:00:04.639 with me here. Transport yourself back to, say, 00:00:04.799 --> 00:00:08.919 1993. You're sitting in front of a big beige 00:00:08.919 --> 00:00:12.339 tower PC. It's heavy. It's loud. And you've just 00:00:12.339 --> 00:00:14.039 hit that power button. Oh, I know that feeling. 00:00:14.179 --> 00:00:16.739 The whir of the fans. That almost jet engine 00:00:16.739 --> 00:00:20.059 sound. Exactly. And then you get that really 00:00:20.059 --> 00:00:23.339 satisfying mechanical clunk grind clunk. Same. 00:00:23.359 --> 00:00:26.219 Like checking for a disc. Yep. That sound is 00:00:26.219 --> 00:00:28.120 just burned into my brain. It's the sound of 00:00:28.120 --> 00:00:31.879 anticipation. It is. And then the screen glows. 00:00:31.879 --> 00:00:34.020 You get that blinking underscore and suddenly 00:00:34.020 --> 00:00:37.460 text starts scrolling really fast. Lines and 00:00:37.460 --> 00:00:39.740 lines of it. Yeah. Stuff about drivers, memory 00:00:39.740 --> 00:00:42.280 managers, buffers, all these weird acronyms. 00:00:42.280 --> 00:00:43.979 It's like watching the machine's heartbeat as 00:00:43.979 --> 00:00:46.990 it wakes up. And today, we're going to talk about 00:00:46.990 --> 00:00:49.009 the thing that actually controlled that heartbeat. 00:00:49.270 --> 00:00:51.570 We are talking about the gatekeeper, the absolute 00:00:51.570 --> 00:00:54.950 master of the PC experience for decades, the 00:00:54.950 --> 00:00:58.890 one and only ConfigSYS. ConfigSYS. You know, 00:00:58.909 --> 00:01:01.210 just saying the name brings back this mix of 00:01:01.210 --> 00:01:03.729 nostalgia and, well, a little bit of anxiety. 00:01:04.010 --> 00:01:06.290 Anxiety is the right word. I mean, for a long 00:01:06.290 --> 00:01:08.349 time, that one little text file was the only 00:01:08.349 --> 00:01:10.230 thing standing between you and a computer that 00:01:10.230 --> 00:01:13.810 was, well, a useless brick. So, okay, here's 00:01:13.810 --> 00:01:16.030 our mission for today's deep dive. We are going 00:01:16.030 --> 00:01:18.790 to unpack this ASCII text file. We're going to 00:01:18.790 --> 00:01:21.030 look at how it worked, why it was so critical, 00:01:21.069 --> 00:01:24.549 and honestly, the surprising amount of drama 00:01:24.549 --> 00:01:28.609 and technical warfare that was hidden inside 00:01:28.609 --> 00:01:31.310 those simple lines of text. It's a really fascinating 00:01:31.310 --> 00:01:33.390 story. You're moving from a world where you had 00:01:33.390 --> 00:01:36.370 to manually tell the computer how to think to 00:01:36.370 --> 00:01:39.510 the kind of black box systems we have today where... 00:01:39.980 --> 00:01:41.760 You know, everything is hidden away from us. 00:01:41.900 --> 00:01:44.099 Let's start with the absolute basics. What is 00:01:44.099 --> 00:01:47.799 config .sys? Because for my teenage self, it 00:01:47.799 --> 00:01:49.719 was just this magic scroll I was told never, 00:01:49.799 --> 00:01:52.019 ever to touch. Well, at its simplest, it's a 00:01:52.019 --> 00:01:55.859 configuration file for DOS and for OS2, and it's 00:01:55.859 --> 00:01:58.140 a user -maintained ASCII text file. Which means 00:01:58.140 --> 00:01:59.719 it's human -readable. You could just open it 00:01:59.719 --> 00:02:01.519 up. Exactly. You could open it in Notepad or 00:02:01.519 --> 00:02:03.719 the old DOS editor. It wasn't some weird binary 00:02:03.719 --> 00:02:05.379 file. And it had to be in the root directory, 00:02:05.519 --> 00:02:09.620 right? See config .sys. It had to be right there 00:02:09.620 --> 00:02:11.340 in the root of whatever drive you're booting 00:02:11.340 --> 00:02:14.539 from. And its job was to specify startup options 00:02:14.539 --> 00:02:16.840 that you cannot change after the system boots. 00:02:17.020 --> 00:02:19.580 That's the key. Oh, OK. Once the operating system 00:02:19.580 --> 00:02:22.219 is fully up and running, config .js has done 00:02:22.219 --> 00:02:25.419 its job. It's finished. So it's like the setup 00:02:25.419 --> 00:02:27.699 crew for a concert. That's a great way to put 00:02:27.699 --> 00:02:31.000 it. It controls memory management. It loads all 00:02:31.000 --> 00:02:33.099 the low -level drivers for your peripherals. 00:02:33.159 --> 00:02:36.060 Like your CD -ROM or your sound card? Precisely. 00:02:36.060 --> 00:02:38.099 And it sets up the whole environment for the 00:02:38.099 --> 00:02:40.319 applications that are about to run. Now, I found 00:02:40.319 --> 00:02:42.199 this little nugget in the source material totally 00:02:42.199 --> 00:02:45.919 wild. I always just assumed Config YSS was born 00:02:45.919 --> 00:02:49.500 with MS -DOS. You know, that Bill Gates sketched 00:02:49.500 --> 00:02:51.699 it out on a napkin or something. But that's not 00:02:51.699 --> 00:02:53.879 true, is it? Not even close. The source points 00:02:53.879 --> 00:02:55.879 out that the name and the whole concept, really, 00:02:55.960 --> 00:03:00.080 came from an operating system called DX85M. DX85M? 00:03:00.120 --> 00:03:02.719 I have never, ever heard of that. Most people 00:03:02.719 --> 00:03:05.099 haven't. It was for the Durango F85 computer, 00:03:05.319 --> 00:03:09.099 and it came out in 1978. 1978. So the DNA of 00:03:09.099 --> 00:03:11.280 this file is, what, five years older than DOS 00:03:11.280 --> 00:03:14.360 2 .0? It is. The whole idea of having a simple 00:03:14.360 --> 00:03:16.340 text file to configure your hardware, I mean... 00:03:16.569 --> 00:03:18.770 That was revolutionary. Before that, you might 00:03:18.770 --> 00:03:21.310 have to recompile a kernel or, you know, literally 00:03:21.310 --> 00:03:23.229 flip physical DIP switches on the motherboard. 00:03:23.469 --> 00:03:25.030 OK, so let's walk through the boot sequence. 00:03:25.210 --> 00:03:26.710 I think this is where people get confused about 00:03:26.710 --> 00:03:28.830 the order of operations. I hit the power button. 00:03:28.969 --> 00:03:32.770 The BIOS does its thing. Then what? So the BIOS 00:03:32.770 --> 00:03:35.610 hands off control to the DOS system files, usually 00:03:35.610 --> 00:03:38.009 IOSYS. And the very first thing that file does 00:03:38.009 --> 00:03:41.810 is look for config .SYS. Before anything else. 00:03:42.319 --> 00:03:44.360 Before you see a command prompt. Way before. 00:03:44.439 --> 00:03:47.879 It reads config .sys to figure out the rules 00:03:47.879 --> 00:03:50.300 of the road. You know, how much memory do I have 00:03:50.300 --> 00:03:52.060 access to? How am I supposed to talk to this 00:03:52.060 --> 00:03:54.460 hard drive? Is there a mouse connected? It processes 00:03:54.460 --> 00:03:57.439 directives, which are settings, and load commands, 00:03:57.860 --> 00:04:00.080 which are the drivers. And only after it's finished 00:04:00.080 --> 00:04:02.319 with all of that. Only then does it finally load 00:04:02.319 --> 00:04:04.819 the command shell, which is usually command .com. 00:04:05.159 --> 00:04:07.520 And then at the very end of that process, the 00:04:07.520 --> 00:04:10.960 shell runs autoexes .bat. Okay, let's pause right 00:04:10.960 --> 00:04:14.729 there. Because config .sys and autoexe .vat, 00:04:14.930 --> 00:04:17.889 they're like the dynamic duo, Batman and Robin. 00:04:18.990 --> 00:04:21.050 But they do totally different things. They do. 00:04:21.230 --> 00:04:23.430 And it's a critical distinction. So how do you 00:04:23.430 --> 00:04:25.149 explain the difference? Think of it like this. 00:04:26.050 --> 00:04:28.370 ConfigSYS is building a house. It's the construction 00:04:28.370 --> 00:04:31.290 crew. It decides the structural laws. This room 00:04:31.290 --> 00:04:33.649 is for memory. This pipe connects to the sound 00:04:33.649 --> 00:04:37.149 card. We have this many shelves for files. It's 00:04:37.149 --> 00:04:39.709 setting up the physical environment, the infrastructure. 00:04:39.949 --> 00:04:41.870 The blueprint and the build. Okay. Precisely. 00:04:42.350 --> 00:04:45.250 AutoXEC .bat is you walking into that finished 00:04:45.250 --> 00:04:47.769 house, turning on the lights, starting the coffee 00:04:47.769 --> 00:04:50.410 maker. and running your morning routine. It runs 00:04:50.410 --> 00:04:53.230 programs. It sets your path. It starts your menu. 00:04:53.410 --> 00:04:55.709 That makes so much sense. So if config .sys is 00:04:55.709 --> 00:04:57.949 wrong, the house might not even have a front 00:04:57.949 --> 00:05:01.310 door. Exactly. If config .sys fails, the operating 00:05:01.310 --> 00:05:02.949 system doesn't know how to be an operating system. 00:05:03.209 --> 00:05:07.170 If autoexe .bat fails, you just didn't launch 00:05:07.170 --> 00:05:09.129 your favorite game automatically. It's a much 00:05:09.129 --> 00:05:12.009 smaller problem. I love that analogy. Okay, let's 00:05:12.009 --> 00:05:14.430 get into the magic spells, the directives themselves. 00:05:15.230 --> 00:05:18.279 Because reading the source material, It's like 00:05:18.279 --> 00:05:21.610 a spell book. You had to know the exact incantation, 00:05:21.649 --> 00:05:24.269 device something. Device was the big one. I mean, 00:05:24.290 --> 00:05:26.129 this is what extended the system's capabilities. 00:05:26.610 --> 00:05:28.689 The BIOS knows how to talk to a floppy drive 00:05:28.689 --> 00:05:31.689 and a keyboard. It has no idea what a CD -ROM 00:05:31.689 --> 00:05:34.149 is. Or a scanner or a fancy sound card. None 00:05:34.149 --> 00:05:36.750 of it. So you have to literally say device CD 00:05:36.750 --> 00:05:41.709 -ROM .SYS or device SB16 .SYS. You are manually 00:05:41.709 --> 00:05:43.910 patching the operating system every single time 00:05:43.910 --> 00:05:45.910 you boot, telling it, hey, look over here, I 00:05:45.910 --> 00:05:47.509 have this new piece of hardware. And one of the 00:05:47.509 --> 00:05:49.230 most common drivers, the source. mentions is 00:05:49.230 --> 00:05:53.550 anti -SYS. Ah, anti -SYS. That was for the display. 00:05:53.689 --> 00:05:55.750 It gave you colored text, cursor movement, all 00:05:55.750 --> 00:05:57.810 that good stuff in the DOS prompt. If you wanted 00:05:57.810 --> 00:06:00.230 your BBS or your menu system to look cool, you 00:06:00.230 --> 00:06:02.870 needed anti -SYS. Then there were the memory 00:06:02.870 --> 00:06:05.870 ones. The source highlights HeMancySYS, and this 00:06:05.870 --> 00:06:08.170 just unlocks a core memory of pure frustration 00:06:08.170 --> 00:06:11.459 for me. The memory battleground. The infamous 00:06:11.459 --> 00:06:15.540 640 kilobyte barrier. See, the original Intel 00:06:15.540 --> 00:06:18.420 architecture could address one megabyte of memory, 00:06:18.620 --> 00:06:22.920 but DOS reserved that top 384K for hardware, 00:06:23.079 --> 00:06:26.839 so that left only 640K for you, the user. Which 00:06:26.839 --> 00:06:29.879 was fine in 1981, maybe. But not in 1993 when 00:06:29.879 --> 00:06:31.639 you're trying to run a game. Exactly. Games got 00:06:31.639 --> 00:06:33.980 bigger. Spreadsheets got bigger. So HiMemSuccess 00:06:33.980 --> 00:06:36.079 was the driver that managed extended memory, 00:06:36.199 --> 00:06:38.199 all the RAM that lived above that one megabyte 00:06:38.199 --> 00:06:40.550 mark. And that led to the famous command. DOS 00:06:40.550 --> 00:06:43.009 high UMB. That was the absolute game changer. 00:06:43.149 --> 00:06:45.269 DOS high told the system to load the operating 00:06:45.269 --> 00:06:47.990 system code itself into the high memory area, 00:06:48.069 --> 00:06:50.550 a tiny little slice of memory just above that 00:06:50.550 --> 00:06:52.689 one memory line. And by doing that, you freed 00:06:52.689 --> 00:06:54.470 a precious conventional memory down below. You 00:06:54.470 --> 00:06:56.990 did. And UMB, that stood for upper memory blocks. 00:06:57.029 --> 00:06:58.970 That let you cram your drivers into that reserved 00:06:58.970 --> 00:07:01.050 upper area too. You were constantly shuffling 00:07:01.050 --> 00:07:03.029 things around. It was like a game of Tetris with 00:07:03.029 --> 00:07:05.949 your RAM just to get, what, 600K free so Doom 00:07:05.949 --> 00:07:08.170 would actually launch? It absolutely was. Okay. 00:07:08.209 --> 00:07:09.649 Two other directives here that I know. I know 00:07:09.649 --> 00:07:11.430 I typed a thousand times but never really got. 00:07:12.149 --> 00:07:15.370 Files and buffers. Files 30. It was just standard 00:07:15.370 --> 00:07:19.550 advice, right? Yes. But why? What was I doing? 00:07:19.790 --> 00:07:21.829 It's actually quite literal. It tells the operating 00:07:21.829 --> 00:07:25.290 system how many file handles, which are basically 00:07:25.290 --> 00:07:27.470 just slots for open files, it should reserve. 00:07:27.790 --> 00:07:29.730 How many files can be opened at the same time, 00:07:29.769 --> 00:07:32.250 system -wide. So if a program tried to open a 00:07:32.250 --> 00:07:35.149 31st file and you only set it to 30? The program 00:07:35.149 --> 00:07:37.360 would crash. It would just give up. So why not 00:07:37.360 --> 00:07:39.399 just set it to Faisal 1000 and be done with it? 00:07:39.500 --> 00:07:42.160 Because every single file handle you reserve 00:07:42.160 --> 00:07:45.360 takes up a tiny bit of that precious conventional 00:07:45.360 --> 00:07:47.920 RAM. And remember, we are fighting for every 00:07:47.920 --> 00:07:50.540 last byte. Of course. If you allocate memory 00:07:50.540 --> 00:07:53.819 for 100 files but you only ever use 20, you're 00:07:53.819 --> 00:07:56.660 wasting resources. You are the systems administrator 00:07:56.660 --> 00:07:59.980 of your own desktop, manually balancing the budget 00:07:59.980 --> 00:08:02.199 of your own memory. That is a level of responsibility 00:08:02.199 --> 00:08:04.939 we just do not have today. I don't think I ever 00:08:04.939 --> 00:08:06.740 worried about file handles that much. And you 00:08:06.740 --> 00:08:09.139 shouldn't have to. But back then, you had to 00:08:09.139 --> 00:08:11.639 know. There's one more directive here that leads 00:08:11.639 --> 00:08:14.379 us perfectly into the panic mode section. Shell. 00:08:14.579 --> 00:08:17.439 Yes. The shell directive tells the system where 00:08:17.439 --> 00:08:19.680 to find its command interpreter. By default, 00:08:19.740 --> 00:08:23.459 that's command .com. Okay. But what happened 00:08:23.459 --> 00:08:27.100 if config .js .js was broken? Or if that shell 00:08:27.100 --> 00:08:29.240 command pointed to a file that didn't exist? 00:08:29.800 --> 00:08:31.500 Well, if the file's just missing or corrupt, 00:08:31.639 --> 00:08:33.700 the system can still boot. It just uses default 00:08:33.700 --> 00:08:36.639 settings, which are usually terrible. But if 00:08:36.639 --> 00:08:39.500 the shell is missing, that's a full -blown crisis. 00:08:39.919 --> 00:08:43.220 The dreaded message. Bad or missing command interpreter. 00:08:43.480 --> 00:08:45.879 It still sends a chill down my spine. In versions 00:08:45.879 --> 00:08:48.559 of DOS before 6 .0, if the system couldn't find 00:08:48.559 --> 00:08:50.340 the shell you told it to find, or the default 00:08:50.340 --> 00:08:53.440 one, it just stopped. Halted. Dead in the water. 00:08:53.559 --> 00:08:55.620 That's it. Just a blinking cursor and a complete 00:08:55.620 --> 00:08:58.440 refusal to do anything else. But the source notes 00:08:58.440 --> 00:09:00.379 a really important evolution in safety here. 00:09:00.519 --> 00:09:03.440 By MS -DOS 6 .0 and Novell DOS 7, they added 00:09:03.440 --> 00:09:05.879 a failsafe. A failsafe. Yeah. If it couldn't 00:09:05.879 --> 00:09:07.659 find the shell, it would actually prompt you. 00:09:07.700 --> 00:09:09.960 It would ask you to manually type in the path. 00:09:10.200 --> 00:09:11.899 So it's like saying, hey, I can't find this front 00:09:11.899 --> 00:09:13.759 door. Can you show me where it is? Instead of 00:09:13.759 --> 00:09:16.419 just burning the house down. Exactly. And speaking 00:09:16.419 --> 00:09:19.019 of safety, we have to talk about the bypass features. 00:09:19.789 --> 00:09:22.909 The F keys. F5 and F8. Oh, these were absolute 00:09:22.909 --> 00:09:25.210 lifesavers. They really were. F5 was the skip 00:09:25.210 --> 00:09:28.950 mode. It just ignored config, techSYS, and autoexe 00:09:28.950 --> 00:09:31.769 .bat entirely. Gave you a clean boot. And F8 00:09:31.769 --> 00:09:34.309 was the trace mode. F8 was the single most powerful 00:09:34.309 --> 00:09:37.129 tool a user had. It let you step through the 00:09:37.129 --> 00:09:39.929 file line by line. It would ask you, load this 00:09:39.929 --> 00:09:42.730 driver. Yes. Load this one. Yes. Load this one. 00:09:42.809 --> 00:09:45.309 No. I remember doing that. Yeah. It was how you 00:09:45.309 --> 00:09:47.309 found the one line that was crashing your computer. 00:09:47.529 --> 00:09:50.159 Okay, the mouse driver is fine. The CD -ROM is 00:09:50.159 --> 00:09:52.279 fine. Oh, wait, it's the scanner driver. That's 00:09:52.279 --> 00:09:53.980 the one that crashed it. It turned debugging 00:09:53.980 --> 00:09:56.899 into a simple process of elimination. It empowered 00:09:56.899 --> 00:09:59.220 you to fix your own system. Now, this is where 00:09:59.220 --> 00:10:01.399 it gets really, really interesting for me. I 00:10:01.399 --> 00:10:03.639 always thought ConfigTexYS was just ConfigTexYS. 00:10:03.720 --> 00:10:06.539 But the source material dives into this OS war 00:10:06.539 --> 00:10:09.700 between MS -DOS and DocDOS. Yes. And apparently, 00:10:09.759 --> 00:10:12.480 their whole approach to this file revealed their 00:10:12.480 --> 00:10:15.139 entire philosophy. This is one of the most technical 00:10:15.139 --> 00:10:18.279 but also fascinating parts of the source. Because 00:10:18.279 --> 00:10:20.720 on the surface, the files looked pretty much 00:10:20.720 --> 00:10:24.379 the same. But under the hood, MS -DOS and Docker 00:10:24.379 --> 00:10:26.860 DOS processed them in completely different ways. 00:10:27.139 --> 00:10:29.500 Okay, let's start with MS -DOS, the Goliath in 00:10:29.500 --> 00:10:32.659 this story. How did it handle the file? MS -DOS 00:10:32.659 --> 00:10:35.549 used a compilation method. When it read config 00:10:35.549 --> 00:10:39.009 .sys, it would basically compile the whole thing 00:10:39.009 --> 00:10:42.529 into a tokenized in -memory representation before 00:10:42.529 --> 00:10:45.370 it actually executed any of it. Tokenized. Break 00:10:45.370 --> 00:10:47.490 that down for us. It means it converted the text 00:10:47.490 --> 00:10:50.409 into a more compact machine -readable code in 00:10:50.409 --> 00:10:53.509 memory. It was an optimization. But because it 00:10:53.509 --> 00:10:55.610 did this all at once, there was a hard file size 00:10:55.610 --> 00:10:58.210 limit. I think in later versions, it was up to 00:10:58.210 --> 00:11:00.649 64 kilobytes. Which is a lot of text, to be fair. 00:11:00.929 --> 00:11:02.769 But it had a side effect on the order of things, 00:11:02.870 --> 00:11:05.500 didn't it? It did. Because it compiled at first, 00:11:05.720 --> 00:11:08.480 MS -DOS felt it had the right to reorganize your 00:11:08.480 --> 00:11:10.320 directives. For instance, it would always force 00:11:10.320 --> 00:11:12.779 device drivers to load before TSRs terminate 00:11:12.779 --> 00:11:15.179 and stay resident programs, no matter where you 00:11:15.179 --> 00:11:17.159 actually put them in the file. So MS -DOS was 00:11:17.159 --> 00:11:19.759 basically saying, I see what you wrote, but I 00:11:19.759 --> 00:11:22.080 know better, so I'm going to do it my way. Pretty 00:11:22.080 --> 00:11:25.610 much. It was rigid. Now compare that to DockerDOS. 00:11:25.690 --> 00:11:27.889 The underdog. What did they do? DockerDOS was 00:11:27.889 --> 00:11:30.750 an interpreter. It read the file line by line, 00:11:30.769 --> 00:11:33.129 and it executed it line by line. So if I put 00:11:33.129 --> 00:11:35.090 a command at the top of the file, it ran first. 00:11:35.490 --> 00:11:38.029 If I put it at the bottom, it ran last. Simple 00:11:38.029 --> 00:11:40.799 as that. You had absolute control. If you had 00:11:40.799 --> 00:11:43.259 some weird conflict where one driver needed to 00:11:43.259 --> 00:11:45.940 load before another one, DockerDOS just let you 00:11:45.940 --> 00:11:48.879 solve it by rearranging the lines. MS -DOS might 00:11:48.879 --> 00:11:50.879 have just rearranged them back behind your back. 00:11:51.120 --> 00:11:53.039 And the source says this line -by -line approach 00:11:53.039 --> 00:11:55.960 meant DireDOS had, what, unlimited file size. 00:11:56.360 --> 00:11:58.519 Theoretically, yes. Since it didn't have to hold 00:11:58.519 --> 00:12:00.340 the whole compiled file in memory at once, you 00:12:00.340 --> 00:12:03.159 could have a gigantic configuration. But DockerDOS 00:12:03.159 --> 00:12:05.899 didn't just stop there. The source lists these 00:12:05.899 --> 00:12:08.799 advanced features that make MS -DOS look... Well, 00:12:08.919 --> 00:12:11.980 kind of primitive in comparison. Docker DOS effectively 00:12:11.980 --> 00:12:15.120 turned config .osys into a programming script. 00:12:15.320 --> 00:12:18.899 It introduced logic, flow control. Logic in a 00:12:18.899 --> 00:12:21.340 config file. Give me an example. Okay, look at 00:12:21.340 --> 00:12:24.039 the chain command. This let you hand off processing 00:12:24.039 --> 00:12:26.840 to a completely different file. You could modularize 00:12:26.840 --> 00:12:30.679 your configuration or the swissy agent go to 00:12:30.679 --> 00:12:33.019 toe commands. Go to, like in basic programming. 00:12:33.200 --> 00:12:35.179 Exactly like in basic. You could jump to different 00:12:35.179 --> 00:12:38.059 labels inside the file based on what the user 00:12:38.059 --> 00:12:40.039 did. Wait, user input. You're telling me the 00:12:40.039 --> 00:12:41.919 computer could talk to me during the boot process. 00:12:42.200 --> 00:12:45.659 Yes, the dot directive. In dot or dos, you could 00:12:45.659 --> 00:12:48.379 write a line like device, sound dot S -Y -S. 00:12:48.820 --> 00:12:51.259 During the boot, it would - pause and literally 00:12:51.259 --> 00:12:53.940 ask you on screen, do you want to load sound 00:12:53.940 --> 00:12:57.309 .sys? Yes or no? That is incredible. I remember 00:12:57.309 --> 00:12:59.669 having to make different boot disks like physical 00:12:59.669 --> 00:13:01.370 floppies because my setup for Wing Commander 00:13:01.370 --> 00:13:03.950 was different from my setup for Microsoft Word. 00:13:04.210 --> 00:13:06.070 And you're telling me DotRDOS could have just 00:13:06.070 --> 00:13:08.110 asked me. It could have just asked you. And not 00:13:08.110 --> 00:13:09.850 only that, you could build a full menu system. 00:13:10.289 --> 00:13:12.330 Using the get key command, it could wait for 00:13:12.330 --> 00:13:15.509 you to press 1 for your game setup or 2 for your 00:13:15.509 --> 00:13:18.750 work setup. DotRDOS even had color and beep directives. 00:13:18.769 --> 00:13:21.120 I could make the boot menu blue. You can make 00:13:21.120 --> 00:13:22.960 it blue. You can make it beep when it was ready 00:13:22.960 --> 00:13:25.559 for input. You could have nested menus. It treated 00:13:25.559 --> 00:13:27.639 the user as an active participant in the boot 00:13:27.639 --> 00:13:30.240 process, not just a spectator. That sounds so 00:13:30.240 --> 00:13:32.519 much more modern. It feels like a precursor to 00:13:32.519 --> 00:13:34.580 the JRuby boot manager we have in Linux today. 00:13:34.759 --> 00:13:37.039 So we have this really sophisticated system in 00:13:37.039 --> 00:13:42.220 DaraDOS and the solid, if kind of rigid, system 00:13:42.220 --> 00:13:46.120 in MS -DOS. What happened? Why aren't we editing 00:13:46.120 --> 00:13:48.990 config .mores files today? The evolution of Windows 00:13:48.990 --> 00:13:51.830 happened. As Windows technology started to really 00:13:51.830 --> 00:13:55.230 diverge from its DOS roots, the reliance on config 00:13:55.230 --> 00:13:58.409 .sys just diminished. The source mentions the 00:13:58.409 --> 00:14:01.570 Windows 9X era, so Windows 95, Windows 98. They 00:14:01.570 --> 00:14:03.509 still had the file though, right? They did, but 00:14:03.509 --> 00:14:05.970 it was mostly for backward compatibility. Windows 00:14:05.970 --> 00:14:08.250 was starting to take over the job of driver management 00:14:08.250 --> 00:14:11.029 with its own 32 -bit drivers, which, you know, 00:14:11.029 --> 00:14:13.470 didn't live in a 16 -bit text file. And there 00:14:13.470 --> 00:14:15.470 was that weird renaming game. The source mentions 00:14:15.470 --> 00:14:18.669 config .dos. Oh, yeah. If you were dual booting, 00:14:18.669 --> 00:14:20.690 say you had Windows 95, but you wanted to go 00:14:20.690 --> 00:14:24.470 back to real DOS, 6 .22 sometimes, Windows would 00:14:24.470 --> 00:14:27.210 play the shell game with the file names. When 00:14:27.210 --> 00:14:29.549 you booted into DOS, it would swap the name. 00:14:29.590 --> 00:14:33.110 So config DOS became config .js again. And then 00:14:33.110 --> 00:14:36.190 came the end of the line, Windows Me. Windows 00:14:36.190 --> 00:14:38.990 Millennium Edition. And the source is very, very 00:14:38.990 --> 00:14:41.509 clear on this. Windows Me does not use config 00:14:41.509 --> 00:14:45.200 .js at all. Completely ignored. You could put 00:14:45.200 --> 00:14:47.700 commands in there. Windows Me just glosses right 00:14:47.700 --> 00:14:51.100 over them. Instead, it loads all those environment 00:14:51.100 --> 00:14:53.820 variables directly from the Windows registry. 00:14:53.960 --> 00:14:57.019 Right. Specifically from a place called HKLM 00:14:57.019 --> 00:14:59.740 System Current Control Session Manager Environment. 00:15:00.000 --> 00:15:02.480 That's a mouthful. And it is definitely not a 00:15:02.480 --> 00:15:04.679 simple text file sitting in your root directory. 00:15:04.840 --> 00:15:06.820 Not at all. And that really marks the transition. 00:15:06.960 --> 00:15:09.080 We went from a file you could open with Notepad 00:15:09.080 --> 00:15:12.159 to this huge binary database hidden deep inside 00:15:12.159 --> 00:15:14.320 the system that you can only get to with a special 00:15:14.320 --> 00:15:16.220 editor. But wait, the source says there's one 00:15:16.220 --> 00:15:19.549 survivor from this era. Yes, OS2. the operating 00:15:19.549 --> 00:15:22.070 system that could have been king. OS2 and its 00:15:22.070 --> 00:15:24.590 modern derivatives, like Arco OS, they still 00:15:24.590 --> 00:15:27.950 rely very heavily on config .sys. Because of 00:15:27.950 --> 00:15:30.690 the way OS2 is architected, it uses that file 00:15:30.690 --> 00:15:32.950 to configure the whole environment before the 00:15:32.950 --> 00:15:36.049 graphical part even loads. So for a small, dedicated 00:15:36.049 --> 00:15:39.350 group of users, config .sys is still very much 00:15:39.350 --> 00:15:41.230 alive. You know, that makes me happy somehow. 00:15:41.879 --> 00:15:43.960 It's like finding a living dinosaur on a remote 00:15:43.960 --> 00:15:46.659 island. It is. It's a testament to a very specific 00:15:46.659 --> 00:15:51.080 era of computing design. So let's zoom out. What 00:15:51.080 --> 00:15:52.899 does this all mean? When we look back at this 00:15:52.899 --> 00:15:55.799 file, config .gesp .js, what are we really looking 00:15:55.799 --> 00:15:58.220 at? I think we're looking at an era of transparency. 00:15:58.799 --> 00:16:01.200 This single file represents a time when users 00:16:01.200 --> 00:16:04.399 were, yes, forced, but also empowered to manage 00:16:04.399 --> 00:16:06.259 their computer's resources themselves manually. 00:16:06.639 --> 00:16:08.480 You had to know what a buffer was. You had to 00:16:08.480 --> 00:16:10.320 know where your memory was going. It was a burden 00:16:10.320 --> 00:16:12.940 for sure, but it was also, I don't know, educational. 00:16:13.539 --> 00:16:16.000 Absolutely. It demystified the machine. When 00:16:16.000 --> 00:16:18.080 you edit a text file to make your sound card 00:16:18.080 --> 00:16:20.960 work, you understand fundamentally that the sound 00:16:20.960 --> 00:16:22.799 card is just a piece of hardware waiting for 00:16:22.799 --> 00:16:25.500 a piece of software to talk to it. Today, you 00:16:25.500 --> 00:16:28.399 plug in a USB device, it makes a little sound, 00:16:28.539 --> 00:16:31.879 and it just works. Which is convenient, but it 00:16:31.879 --> 00:16:33.960 hides the reality of what's actually happening. 00:16:34.159 --> 00:16:36.220 It's the black box effect. We don't know how 00:16:36.220 --> 00:16:38.340 it works, so we have no idea how to fix it when 00:16:38.340 --> 00:16:40.440 it breaks. And when you look at those DARDOS 00:16:40.440 --> 00:16:43.460 features, the scripting, the logic, it shows 00:16:43.460 --> 00:16:46.440 that config .sys wasn't just a settings list. 00:16:46.500 --> 00:16:49.080 It was becoming a programming environment for 00:16:49.080 --> 00:16:52.320 the boot process itself. We were literally programming 00:16:52.320 --> 00:16:54.580 our computer's wake -up routine. That brings 00:16:54.580 --> 00:16:57.600 us to the so what of this whole deep dive. We 00:16:57.600 --> 00:17:00.019 traded that control for convenience. We traded 00:17:00.019 --> 00:17:02.340 the ability to step through a simple text file 00:17:02.340 --> 00:17:05.119 line by line for a registry that is massive, 00:17:05.259 --> 00:17:07.900 complex, and honestly, pretty opaque to the average 00:17:07.900 --> 00:17:10.069 person. It's the difference between driving a 00:17:10.069 --> 00:17:12.089 car with a manual transmission where you feel 00:17:12.089 --> 00:17:15.430 every single gear change and riding in a self 00:17:15.430 --> 00:17:17.170 -driving car. I mean, the self -driving car is 00:17:17.170 --> 00:17:19.470 safer. It's easier. It's arguably better for 00:17:19.470 --> 00:17:21.910 most people. But you lose that connection to 00:17:21.910 --> 00:17:24.329 the road. Before we wrap up, I want to leave 00:17:24.329 --> 00:17:26.430 our listeners with one last provocative thought 00:17:26.430 --> 00:17:29.430 based on that very transition. The move to the 00:17:29.430 --> 00:17:32.609 registry in Windows Me. Go on. We tend to assume 00:17:32.609 --> 00:17:34.950 that newer is always better. That moving all 00:17:34.950 --> 00:17:37.109 those settings into the registry was an upgrade. 00:17:37.430 --> 00:17:40.589 But was it? Did we really gain stability by hiding 00:17:40.589 --> 00:17:43.329 these settings away? Or did we actually lose 00:17:43.329 --> 00:17:45.890 a valuable layer of transparency and control? 00:17:46.390 --> 00:17:48.750 When your computer's nervous system was just 00:17:48.750 --> 00:17:50.890 a text file you could edit yourself, you own 00:17:50.890 --> 00:17:53.150 the problems, sure, but you also own the solutions. 00:17:53.670 --> 00:17:56.190 Now, when the registry breaks, you're often just 00:17:56.190 --> 00:17:58.130 told to wipe the drive and reinstall Windows. 00:17:58.450 --> 00:18:01.089 That is a provocative thought. Is obscurity really 00:18:01.089 --> 00:18:05.029 security? Or is it just a loss of agency? Something 00:18:05.029 --> 00:18:06.690 to think about the next time you're staring at 00:18:06.690 --> 00:18:09.140 a loading screen. Thanks for diving deep with 00:18:09.140 --> 00:18:11.779 us today into the hidden world of config .sys. 00:18:12.059 --> 00:18:14.259 My pleasure. It was great to revisit the root 00:18:14.259 --> 00:18:17.119 directory. See you on the next deep dive.