WEBVTT 1 00:00:00.120 --> 00:00:03.759 Welcome to the deep dive. Today. We're really peeling back 2 00:00:03.799 --> 00:00:06.080 the layers of your Windows ten computer. 3 00:00:06.200 --> 00:00:07.599 Yeah, going straight to the core. 4 00:00:07.639 --> 00:00:12.279 Exactly how software actually interacts with the operating system. One 5 00:00:12.320 --> 00:00:14.960 of you asked for a deeper look, and well, here. 6 00:00:14.800 --> 00:00:17.559 We are, absolutely and we've got a really good technical 7 00:00:17.600 --> 00:00:19.960 book to guide us. We'll be digging into the key 8 00:00:20.039 --> 00:00:22.679 insights on the fundamental stuff. 9 00:00:22.480 --> 00:00:24.399 Like processes, threads. 10 00:00:23.960 --> 00:00:27.719 Right, memory management, and that crucial world of IO input 11 00:00:27.839 --> 00:00:29.000 output operations. 12 00:00:29.440 --> 00:00:32.320 Our mission then for this deep dive is to get 13 00:00:32.399 --> 00:00:35.200 right to the heart of how Windows actually juggles all 14 00:00:35.280 --> 00:00:38.119 the programs you run and the resources they all need. 15 00:00:38.240 --> 00:00:40.679 We're aiming for those moments where it just clicks. 16 00:00:40.759 --> 00:00:43.520 Yeah, those aha moments where you think, oh, that's why 17 00:00:43.560 --> 00:00:45.799 my system does that. So let's start at the very 18 00:00:45.840 --> 00:00:47.280 beginning processes. 19 00:00:47.359 --> 00:00:50.840 Okay, so book right away makes this really important point. 20 00:00:50.840 --> 00:00:53.719 It might even surprise you. We usually think of a 21 00:00:53.759 --> 00:00:57.200 process as the thing that's running, but it's actually more 22 00:00:57.240 --> 00:01:01.200 accurate to think of it as a management object, a container. Basically, 23 00:01:01.280 --> 00:01:05.560 I contain yeah, the actual work, the code execution that's 24 00:01:05.599 --> 00:01:07.480 done by threads within the process. 25 00:01:07.560 --> 00:01:11.400 Okay, So processes are like maybe office buildings, and threads 26 00:01:11.480 --> 00:01:12.959 are the workers inside. 27 00:01:13.040 --> 00:01:16.319 That's a great analogy. Exactly one can't really function without 28 00:01:16.319 --> 00:01:18.640 the other, but they definitely have distinct roles. 29 00:01:18.760 --> 00:01:22.079 Interesting, So if the process isn't the runner, what does 30 00:01:22.120 --> 00:01:24.719 it actually own what's inside this office building? 31 00:01:25.439 --> 00:01:28.760 Well, a process is responsible for some critical things. First, 32 00:01:28.799 --> 00:01:31.599 it gets its own private address space. Think of it 33 00:01:31.680 --> 00:01:34.760 like its own dedicated chunk of memory, its floor plan. Okay. 34 00:01:35.239 --> 00:01:38.200 Then it holds one or more threads, the workers. It 35 00:01:38.239 --> 00:01:40.040 also keeps a handle table. 36 00:01:39.879 --> 00:01:42.120 A handle table like an inventory list short of. 37 00:01:42.200 --> 00:01:44.760 Yeah, yeah, an inventory of all the system resources it's using. 38 00:01:45.000 --> 00:01:48.040 And critically, it's assigned a unique process ID. 39 00:01:48.000 --> 00:01:51.200 Or PID PIDs. Right, we see those in task Manager 40 00:01:51.239 --> 00:01:53.239 all the time. Now, the book says they're unique but 41 00:01:53.319 --> 00:01:56.040 also reusable. How does that work? I sort of assumed 42 00:01:56.040 --> 00:01:58.480 a PID was like permanent. 43 00:01:58.680 --> 00:02:01.120 Yeah, that's common thought. But the key thing is a 44 00:02:01.120 --> 00:02:04.799 PID uniquely identifies a currently running process. 45 00:02:04.519 --> 00:02:05.840 Ah only while it's active. 46 00:02:06.280 --> 00:02:10.080 Exactly as long as that kernel object representing the process exists, 47 00:02:10.479 --> 00:02:14.159 the PID is its tag. But once the process finishes, 48 00:02:14.479 --> 00:02:16.879 poof that kernel object is gone. 49 00:02:16.639 --> 00:02:17.919 And the number can be used again. 50 00:02:17.759 --> 00:02:21.039 Later, right for a completely different new process it's like 51 00:02:21.080 --> 00:02:23.199 reusing raffle ticket numbers for different draws. 52 00:02:23.280 --> 00:02:25.400 That makes total sense, and it's a good reminder. Then, 53 00:02:25.599 --> 00:02:29.599 when we see say multiple Chrome Windows Open or Word instances, 54 00:02:30.240 --> 00:02:33.439 each one is its own distinct process, with its own PID, 55 00:02:33.520 --> 00:02:36.199 its own resources, even though they all started from the 56 00:02:36.240 --> 00:02:37.199 same program file. 57 00:02:37.280 --> 00:02:40.719 Precisely, the dot exc file is the blueprint, but each 58 00:02:40.800 --> 00:02:44.439 running instance gets its own private stuff. Now about that 59 00:02:44.560 --> 00:02:47.520 address space, the private memory. Yeah, the book lays out 60 00:02:47.560 --> 00:02:49.840 some different sizes. It depends on whether it's a sixty 61 00:02:49.840 --> 00:02:51.680 four bit or a thirty two bit process. 62 00:02:51.800 --> 00:02:54.840 Right. For sixty four bit processes on sixty four bit Windows, 63 00:02:55.240 --> 00:02:58.439 we're talking massive amounts of space, right, like eight terabytes 64 00:02:58.520 --> 00:02:59.719 or even one hundred and twenty eight. 65 00:02:59.639 --> 00:03:03.000 Terrabyte, Yes, staggering numbers. Eight terabytes on Windows eight and earlier, 66 00:03:03.000 --> 00:03:05.199 and then one hundred and twenty eight terabytes from Windows 67 00:03:05.280 --> 00:03:07.840 eight point one onwards. It's like having an almost infinite 68 00:03:07.879 --> 00:03:08.560 address book. 69 00:03:08.800 --> 00:03:11.759 Okay, but what about those older thirty two bit programs, 70 00:03:12.000 --> 00:03:14.960 the one still running on our modern sixty four bit systems. 71 00:03:15.120 --> 00:03:18.360 Ah Okay, that's where it gets a bit more nuanced. 72 00:03:19.120 --> 00:03:22.080 By default, a thirty two bit process only gets a 73 00:03:22.120 --> 00:03:23.680 two gigabyte address. 74 00:03:23.360 --> 00:03:24.719 Space only two gigs. 75 00:03:25.080 --> 00:03:28.120 But if the program was built with a special flag, 76 00:03:28.360 --> 00:03:30.240 a setting called large address aware. 77 00:03:30.439 --> 00:03:31.319 Large address aware. 78 00:03:31.439 --> 00:03:34.599 Yeah, if it has that flag, it can actually access 79 00:03:34.680 --> 00:03:37.159 up to four gigabytes on a sixty four bit system. 80 00:03:36.919 --> 00:03:39.439 So it doubles its potential memory pretty much. 81 00:03:39.560 --> 00:03:41.719 Think of the flag as the thirty two bit program 82 00:03:41.840 --> 00:03:44.280 telling the sixty four bit system, Hey, I know how 83 00:03:44.280 --> 00:03:46.039 to handle more memory addresses than usual. 84 00:03:46.159 --> 00:03:49.159 Okay, so that flag signals it's ready for more space. Now. 85 00:03:49.159 --> 00:03:51.719 Another key piece here seems to be these dynamic link 86 00:03:51.800 --> 00:03:54.120 libraries DLLs. 87 00:03:54.199 --> 00:03:58.759 They're everywhere we really are. Dls are essentially packages. They 88 00:03:58.759 --> 00:04:02.840 contain codeta resources things a program might need, and they 89 00:04:02.840 --> 00:04:05.960 get loaded into a process dynamic or dynamically, meaning either 90 00:04:06.000 --> 00:04:08.400 when the process starts up that's called static linking even 91 00:04:08.400 --> 00:04:11.039 though it sounds contradictory, or later on when the process 92 00:04:11.120 --> 00:04:13.639 explicitly asks for it, which is true dynamic linking. 93 00:04:13.800 --> 00:04:16.560 The book mentions you can't just run a DLL directly, 94 00:04:16.759 --> 00:04:19.480 right because they don't have that main entry point like 95 00:04:19.519 --> 00:04:20.319 an executable. 96 00:04:20.560 --> 00:04:24.120 Correct, no main function. But the really interesting part and 97 00:04:24.120 --> 00:04:26.399 a big efficiency thing is the memory sharing. 98 00:04:26.720 --> 00:04:29.240 Ah, yes, tell me about that. 99 00:04:29.439 --> 00:04:32.519 So when multiple processes are using the same DLL, especially 100 00:04:32.600 --> 00:04:35.759 those common Windows DLLs in the system thirty two folder. 101 00:04:35.519 --> 00:04:37.519 Like kernel thirty two dot dll. 102 00:04:37.399 --> 00:04:40.839 Exactly or User thirty two dot DLL. The actual code 103 00:04:40.879 --> 00:04:43.079 from the DLL can be shared in physical. 104 00:04:42.879 --> 00:04:45.519 RAM, so you don't have multiple copies loaded, right. 105 00:04:45.600 --> 00:04:48.600 It avoids wasting precious RAM. It's a huge win. 106 00:04:48.839 --> 00:04:51.920 And these particular DLLs, the subsystem ones, they're the ones 107 00:04:51.959 --> 00:04:54.920 that actually implement the core Windows API. Aren't they the 108 00:04:54.920 --> 00:04:57.639 functions that applications call to talk to the OS. 109 00:04:57.759 --> 00:05:00.759 That's precisely it. They're the gateway for norm user mode 110 00:05:00.759 --> 00:05:04.040 applications to access the underlying power of the Windows kernel. 111 00:05:04.560 --> 00:05:06.360 And this focus is really what the book is all. 112 00:05:06.279 --> 00:05:09.759 About, which leads us nicely into the broader Windows architecture 113 00:05:09.920 --> 00:05:12.519 user mode versus kernel mode. 114 00:05:12.680 --> 00:05:15.839 User mode is where our everyday apps live, Notepad, your 115 00:05:15.920 --> 00:05:20.120 browser games, plus those subsystem DLLs we just talked about, 116 00:05:20.360 --> 00:05:21.759 and also something called win. 117 00:05:21.720 --> 00:05:24.600 RT and kernel mode is the deeper layer, the engine room. 118 00:05:24.720 --> 00:05:27.079 Correct, that's the privileged part of the OS where the 119 00:05:27.079 --> 00:05:29.800 core components run, managing hardware security, that kind of thing. 120 00:05:30.000 --> 00:05:35.120 So user processes, subsystem DLLs and win RT, what's. 121 00:05:34.920 --> 00:05:38.319 That win RT or Windows run Time is a newer 122 00:05:38.360 --> 00:05:41.480 API layer. It came in with Windows eight, mainly for 123 00:05:41.560 --> 00:05:45.000 those Universal Windows Platform apps UWP apps. 124 00:05:44.800 --> 00:05:46.600 The ones from the Microsoft Store mostly. 125 00:05:46.680 --> 00:05:49.600 Yeah, it's built on an older technology called comm Component 126 00:05:49.680 --> 00:05:52.240 Object Model, which is all about software components talking to 127 00:05:52.279 --> 00:05:55.600 each other. And win RT supports multiple programming languages. 128 00:05:55.680 --> 00:05:57.920 Interesting, and it's not just for UWP apps. No. 129 00:05:58.399 --> 00:06:00.839 Recently a subset of win rts is actually available for 130 00:06:00.879 --> 00:06:04.079 traditional desktop applications too. Seems like Microsoft is trying to 131 00:06:04.079 --> 00:06:05.720 bridge the gap between those two worlds. 132 00:06:06.079 --> 00:06:08.920 Makes sense now for anyone listening who's thinking about actually 133 00:06:08.959 --> 00:06:12.639 doing some Windows system programming. The book mentions Duols Visual 134 00:06:12.639 --> 00:06:13.639 Studio primarily. 135 00:06:13.839 --> 00:06:17.759 Yeah, Visual Studio is the main integrated development environment the ID. 136 00:06:18.720 --> 00:06:21.519 The book emphasizes just getting your development set up right 137 00:06:21.560 --> 00:06:22.480 from the start. 138 00:06:22.319 --> 00:06:24.959 And it mentions that even doing a basic Hello World 139 00:06:25.519 --> 00:06:27.639 application can teach you something. 140 00:06:27.759 --> 00:06:30.360 Absolutely. Just compiling it shows you the process and you 141 00:06:30.439 --> 00:06:33.079 might notice subtle differences depending on whether you build it 142 00:06:33.120 --> 00:06:35.680 for a thirty two bit system that's by eighty six 143 00:06:36.199 --> 00:06:38.279 or a sixty four bit system by sixty four. 144 00:06:38.639 --> 00:06:42.959 Okay, And following on from that, character encoding Unicode this 145 00:06:43.040 --> 00:06:43.800 sounds important. 146 00:06:43.959 --> 00:06:46.839 It's crucial, especially for software that needs to work globally. 147 00:06:47.160 --> 00:06:50.240 There's a Unicode setting usually set by default and visual 148 00:06:50.240 --> 00:06:51.040 studio when you. 149 00:06:50.920 --> 00:06:53.839 Compile, and that affects how strings are handled. 150 00:06:53.959 --> 00:06:57.720 Yes, yes, it determines whether a type like lpctstr in 151 00:06:57.759 --> 00:07:01.560 the code represents text using UTFS sixteen, which can handle 152 00:07:01.560 --> 00:07:04.199 pretty much any character from any language, or the much 153 00:07:04.199 --> 00:07:05.519 more limited ASCI standard. 154 00:07:05.759 --> 00:07:09.040 So UTS sixteen is generally preferred definitely, and. 155 00:07:09.040 --> 00:07:11.920 You see this directly in the Windows API functions themselves. 156 00:07:12.240 --> 00:07:15.800 A function like creep mutex, for example, isn't really one function. Well, 157 00:07:15.839 --> 00:07:18.360 it's like a macro. The compiler expands it to either 158 00:07:18.480 --> 00:07:22.560 create mutex WZ the WS for wide characters UTF sixteen, 159 00:07:22.920 --> 00:07:26.959 or create mutexa A for ANSI or ASCI ah. 160 00:07:27.000 --> 00:07:30.879 Okay, So using Unicode means you automatically get the w versions, 161 00:07:31.079 --> 00:07:33.759 which prevents your text getting garbled if it contains non 162 00:07:33.759 --> 00:07:34.639 English characters. 163 00:07:34.680 --> 00:07:37.800 Exactly. It voids data loss and makes your software work 164 00:07:37.879 --> 00:07:41.240 correctly with international text, absolutely vital these days. 165 00:07:41.439 --> 00:07:44.560 The book also flags safer ways to handle strings right 166 00:07:44.680 --> 00:07:47.079 like wccswise. 167 00:07:46.279 --> 00:07:49.959 Yes and functions from the struceay dot EA CHEDDAR. It's 168 00:07:50.040 --> 00:07:52.639 quick reminder that the old C style string functions can 169 00:07:52.680 --> 00:07:55.879 be risky, you know, buffer overflows and security issues. These 170 00:07:55.920 --> 00:07:57.680 newer functions are designed to be much safer. 171 00:07:57.759 --> 00:08:00.000 Good practice to use them and for the code example. 172 00:08:00.120 --> 00:08:03.759 In the book, it mentions helper libraries WISHL and WTL. 173 00:08:03.879 --> 00:08:08.519 Yeah, the Windows Implementation Library WIL and Windows Template Library WTL. 174 00:08:08.879 --> 00:08:12.319 They basically provide convenience C plus plus wrappers around the 175 00:08:12.399 --> 00:08:13.800 raw Windows API. 176 00:08:13.639 --> 00:08:15.639 Makes things less tedious pretty. 177 00:08:15.399 --> 00:08:17.319 Much save if you write in a lot of boilerplate code. 178 00:08:17.360 --> 00:08:20.319 Makes development quicker and less error prone. The book also 179 00:08:20.360 --> 00:08:21.720 touches on Hungarian notation. 180 00:08:22.079 --> 00:08:24.920 Oh yeah, that naming convention like hend for a window 181 00:08:24.959 --> 00:08:26.560 handle exactly. 182 00:08:26.160 --> 00:08:29.439 Or else dir for a pointer to a string. It's 183 00:08:29.439 --> 00:08:32.240 an older style you'll see in the Windows API documentation. 184 00:08:32.360 --> 00:08:35.600 In older code, it embeds the variable type. 185 00:08:35.399 --> 00:08:37.120 In the name, A bit of a historical thing. You 186 00:08:37.120 --> 00:08:38.519 don't have to use it in new code. 187 00:08:38.720 --> 00:08:40.879 No, not really, It's just good to recognize you when 188 00:08:40.919 --> 00:08:46.240 you see it. Okay, So moving on. No system programming 189 00:08:46.240 --> 00:08:49.840 discussion is complete without error handling. What happens when things 190 00:08:49.879 --> 00:08:50.360 go wrong? 191 00:08:51.039 --> 00:08:54.159 Right? How does the Windows API tell you something failed? 192 00:08:54.440 --> 00:08:57.360 There are a few common patterns you'll see. Functions return 193 00:08:57.399 --> 00:09:00.159 a bool. Generally, non zero means success es. 194 00:09:00.519 --> 00:09:03.600 Zero means failure, but don't check for exactly true. 195 00:09:03.799 --> 00:09:05.919 Right The book warms about that success might be one, 196 00:09:06.000 --> 00:09:08.399 or might be two or something else non zero, Just 197 00:09:08.480 --> 00:09:10.399 check if it's zero or not. Think you have types 198 00:09:10.440 --> 00:09:14.799 like l status or long. With those, zero usually means success. 199 00:09:15.159 --> 00:09:18.879 The constant error success is actually zero. Any positive value 200 00:09:18.919 --> 00:09:20.519 indicates a specific. 201 00:09:20.120 --> 00:09:21.679 Error code, an h result. 202 00:09:21.879 --> 00:09:25.159 A result is common two, especially with Calm and Newer 203 00:09:25.200 --> 00:09:30.240 APIs zero or positive generally means success as okay is 204 00:09:30.320 --> 00:09:32.919 zero and negative values signal different errors. 205 00:09:33.480 --> 00:09:35.679 So when a function does fail, how do you find 206 00:09:35.720 --> 00:09:36.200 out why? 207 00:09:37.000 --> 00:09:39.519 The main way is to immediately call to get last 208 00:09:39.519 --> 00:09:43.679 air function immediately Yes, because the next API call might 209 00:09:43.759 --> 00:09:47.279 overwrite the error code and critically get laster gives you 210 00:09:47.320 --> 00:09:49.000 the error code for the current thread. 211 00:09:49.200 --> 00:09:52.559 Ah, So each thread has its own last error value precisely. 212 00:09:52.879 --> 00:09:55.639 If you have multiple threads, you can assume one thread's 213 00:09:55.759 --> 00:09:58.200 error relates to another's failure. It's threads specific. 214 00:09:58.320 --> 00:10:01.080 Got it? Okay? What about finding out Windows version? The 215 00:10:01.080 --> 00:10:03.639 book says the old way get version X is kind 216 00:10:03.639 --> 00:10:04.519 of deprecated now. 217 00:10:04.679 --> 00:10:08.200 Yeah, it's not recommended for various reasons related to compatibility settings. 218 00:10:08.519 --> 00:10:11.080 The modern approach is better, which is there's a header 219 00:10:11.159 --> 00:10:13.279 file version all PRIs dot age with a bunch of 220 00:10:13.279 --> 00:10:16.360 simple functions like is Windows expra, greater, is Windows ten 221 00:10:16.480 --> 00:10:18.399 or greater is when a server and so on. 222 00:10:18.519 --> 00:10:20.120 They just return true or false. 223 00:10:20.200 --> 00:10:23.759 Exactly, much cleaner for most common version checks. Under the 224 00:10:23.799 --> 00:10:27.159 hood they use a more fundamental function called verify version info. 225 00:10:27.799 --> 00:10:29.559 Usually the helpers are all unique. 226 00:10:29.639 --> 00:10:34.080 Okay, nice and simple, right, let's ship gears. Objects and handles. 227 00:10:34.480 --> 00:10:36.759 These sound absolutely central to Windows. 228 00:10:36.840 --> 00:10:40.240 They are fundamental. Handles are everywhere. The book describes them 229 00:10:40.279 --> 00:10:42.720 as basically identifiers for kernel objects. 230 00:10:42.840 --> 00:10:45.240 Kernel objects being what kinds of things. 231 00:10:45.360 --> 00:10:48.279 These are the core resources managed by the Windows kernel itself, 232 00:10:48.960 --> 00:10:53.159 things like files you open, processes that are running threads 233 00:10:53.200 --> 00:10:58.600 doing work, synchronization tools like Mutex's events, all the basic building. 234 00:10:58.240 --> 00:11:01.279 Blocks, okay, And the handle is how our program. 235 00:11:01.080 --> 00:11:03.960 Refers to them, exactly. It's an abstract token, like a 236 00:11:03.960 --> 00:11:06.960 ticket or a claim check. Your user mode program uses 237 00:11:07.000 --> 00:11:09.399 the handle to tell the kernel which object it wants to. 238 00:11:09.320 --> 00:11:12.519 Interact with, so it provides a layer of abstraction and security. 239 00:11:12.720 --> 00:11:15.720 Yes, you don't get direct access to the kernel's internal 240 00:11:15.759 --> 00:11:17.879 data structures. You operate through the handle. 241 00:11:18.039 --> 00:11:21.120 So when we call say, create mutechs to make a 242 00:11:21.159 --> 00:11:23.039 synchronization object. 243 00:11:22.960 --> 00:11:25.799 If it works, you get back a handle value, a 244 00:11:25.919 --> 00:11:29.399 number basically that represents that mutex object living down in 245 00:11:29.399 --> 00:11:32.039 the kernel. And if it fails, the return values usually 246 00:11:32.200 --> 00:11:36.039 zero or null. And then there's open mutex, which is 247 00:11:36.080 --> 00:11:39.799 specifically for getting a handle to a mutex that already 248 00:11:39.799 --> 00:11:40.919 exists and has a name. 249 00:11:41.159 --> 00:11:44.840 Right. Create mutex is interesting because if you give it 250 00:11:44.879 --> 00:11:48.639 a name, it can either create a new named mutex 251 00:11:49.120 --> 00:11:51.200 or it can open an existing one with that name. 252 00:11:51.360 --> 00:11:52.519 How do you know what happened? 253 00:11:53.159 --> 00:11:56.000 Even if create mutex succeeds in opening an existing one, 254 00:11:56.000 --> 00:11:58.799 if you call get last ray after, it will return 255 00:11:58.960 --> 00:11:59.840 error already. 256 00:11:59.519 --> 00:12:02.399 Exists, ah okay, whereas open mutex just fails if the 257 00:12:02.440 --> 00:12:03.320 name mutex. 258 00:12:03.080 --> 00:12:05.279 Isn't there, correct, it won't create one for you. 259 00:12:05.720 --> 00:12:08.320 Now, the book breaks down what's sort of conceptually in 260 00:12:08.360 --> 00:12:11.480 a handle, A pointer to the object and access mask 261 00:12:11.600 --> 00:12:12.279 and flags. 262 00:12:12.559 --> 00:12:15.440 Yeah, that's a simplified view. The access mask is super important. 263 00:12:15.440 --> 00:12:18.399 It defines what operations you're actually allowed to perform using 264 00:12:18.399 --> 00:12:22.279 that specific handle, like permissions exactly. For instance, if you 265 00:12:22.320 --> 00:12:24.679 want to terminate another process. You first need a handle 266 00:12:24.720 --> 00:12:26.799 to it. You get that using open. 267 00:12:26.559 --> 00:12:29.639 Process, but when you call open process you have to 268 00:12:29.720 --> 00:12:34.080 explicitly request the process terminate access right. If the handle 269 00:12:34.120 --> 00:12:36.480 you get back doesn't have that right in its access mask, 270 00:12:36.879 --> 00:12:39.720 then calling terminate process with that handle will just fail. 271 00:12:39.919 --> 00:12:42.720 So the handle encodes the permissions. What about the flags 272 00:12:43.360 --> 00:12:45.639 inheritance Protection from close. 273 00:12:45.600 --> 00:12:49.039 Inheritance means whether a child process created by this process 274 00:12:49.200 --> 00:12:52.799 automatically gets a copy of the handle. Protection from close 275 00:12:53.240 --> 00:12:56.159 handle flag protects from close is a safety feature makes 276 00:12:56.159 --> 00:12:58.840 it harder to accidentally close a really important handle. 277 00:12:58.960 --> 00:13:00.000 Can you change these flags? 278 00:13:00.679 --> 00:13:04.120 Yes, using set handle information and get handle information. And 279 00:13:04.159 --> 00:13:05.600 if you really want to see all the handles a 280 00:13:05.639 --> 00:13:06.399 process has. 281 00:13:06.320 --> 00:13:07.799 Open process explorer. 282 00:13:08.000 --> 00:13:11.960 Process Explorer from cysinternals is the tool. It's invaluable. It 283 00:13:12.000 --> 00:13:15.080 shows the handle value, the type of object, file, thread, 284 00:13:15.200 --> 00:13:17.720 mutex its name if it has one, the object's address 285 00:13:17.759 --> 00:13:20.399 in kernel memory, the raw access mask, and even a 286 00:13:20.440 --> 00:13:23.720 decoded human readable version of the access rights like looking 287 00:13:23.759 --> 00:13:25.360 at the process's internal toolkit. 288 00:13:25.600 --> 00:13:29.080 Definitely a must have tool. Now, managing these handles in code, 289 00:13:29.200 --> 00:13:33.159 especially C plus plus plus A, seems error prone. The 290 00:13:33.200 --> 00:13:35.799 book introduces a smart handle wrapper class. 291 00:13:36.000 --> 00:13:40.120 Yes, it demonstrates a concept called r AII. R AI 292 00:13:40.480 --> 00:13:45.200 resource acquisition is initialization. It basically means the handle resource 293 00:13:45.240 --> 00:13:49.000 is acquired when the C plus plus wrapper object is created, 294 00:13:49.360 --> 00:13:53.240 and crucially, it's automatically released. The handle is closed when 295 00:13:53.240 --> 00:13:56.080 the wrapper object goes out of scope or is destroyed. 296 00:13:56.360 --> 00:14:00.159 Ah, so it cleans up after itself. Prevents handle leaks exactly. 297 00:14:00.240 --> 00:14:03.919 It makes handle management much safer and easier. The example 298 00:14:03.919 --> 00:14:08.080 class also prevents axidel copying of handles, but allows transferring 299 00:14:08.080 --> 00:14:11.600 ownership using something called move semantics. Very useful C plus 300 00:14:11.639 --> 00:14:12.480 plus features neat. 301 00:14:12.559 --> 00:14:16.360 Okay, What about object naming and sessions? Names aren't always 302 00:14:16.399 --> 00:14:17.919 global usually? 303 00:14:17.960 --> 00:14:21.519 Know when your regular user application creates a named object 304 00:14:21.759 --> 00:14:24.399 like a name mutex, that name is typically only visible 305 00:14:24.440 --> 00:14:26.399 within your current user login session. 306 00:14:26.159 --> 00:14:27.960 So another user logged in wouldn't see it. 307 00:14:27.879 --> 00:14:30.600 Correct unless you specifically create it in the global name space. 308 00:14:30.639 --> 00:14:31.159 How do you do that? 309 00:14:31.360 --> 00:14:35.240 You prefix the name with global like global mouse, shared, mutechs. 310 00:14:36.080 --> 00:14:39.600 These live in a special base named objects directory in 311 00:14:39.679 --> 00:14:41.879 the kernel's object manager name space. 312 00:14:42.320 --> 00:14:43.799 Can any application do this? 313 00:14:44.120 --> 00:14:48.120 Well, there's a catch. Modern sandbox apps called app containers 314 00:14:48.200 --> 00:14:50.519 usually don't have the permissions to create objects in the 315 00:14:50.519 --> 00:14:54.080 global name space. It's mainly for services or older desktop 316 00:14:54.080 --> 00:14:55.879 apps needing system wide coordination. 317 00:14:56.279 --> 00:14:59.120 So if you have two separate programs, maybe even started 318 00:14:59.120 --> 00:15:02.639 by different users, they could use these global named objects 319 00:15:02.720 --> 00:15:04.240 to communicate or synchronize. 320 00:15:04.320 --> 00:15:07.519 Yes, that's a primary use case. One process creates the 321 00:15:07.559 --> 00:15:10.679 named object, create mutex with the global name, and another 322 00:15:10.720 --> 00:15:13.559 process can open it using the same name, open mutext, 323 00:15:13.639 --> 00:15:15.919 or even create utechs. Again, the name acts is the 324 00:15:15.919 --> 00:15:16.840 rendezvous point. 325 00:15:17.120 --> 00:15:21.960 Interesting. Another mechanism mentioned is handle duplication using duplicate handle. 326 00:15:22.000 --> 00:15:22.679 What's that about? 327 00:15:22.840 --> 00:15:24.440 This lets you take a handle you have in your 328 00:15:24.480 --> 00:15:27.799 process and create a new handle, potentially in a different 329 00:15:27.799 --> 00:15:31.639 process that refers to the exact same underlying kernel object. 330 00:15:31.679 --> 00:15:32.440 Why would you do that? 331 00:15:32.759 --> 00:15:35.480 A common reason is when a parent process starts a 332 00:15:35.559 --> 00:15:38.720 child process, the parent might want to give the child 333 00:15:38.879 --> 00:15:42.000 access to one of its own open handles, like maybe 334 00:15:42.080 --> 00:15:44.240 it's standard input or output pipe, So. 335 00:15:44.279 --> 00:15:47.399 You duplicate the parent's handle into the child's process space. 336 00:15:47.559 --> 00:15:49.919 Exactly, you need a handle to the target process with 337 00:15:49.960 --> 00:15:52.720 the process you panel permission to do this. You can 338 00:15:52.759 --> 00:15:55.440 even duplicate a handle within the same process if you 339 00:15:55.480 --> 00:15:58.399 need another handle to the same objects, maybe with different 340 00:15:58.440 --> 00:15:59.200 access rights. 341 00:15:59.360 --> 00:16:03.600 Okay. The book then briefly mentions user objects Windows menus 342 00:16:03.639 --> 00:16:07.879 and GDI objects bitmaps, fonts. They're handled a bit differently. 343 00:16:07.960 --> 00:16:11.519 Yeah. User objects like Windows don't use reference counting in 344 00:16:11.559 --> 00:16:14.519 the same way kernel objects do. The first process to 345 00:16:14.559 --> 00:16:18.039 destroy one affects everyone sharing it and their handles their 346 00:16:18.080 --> 00:16:21.240 scope to something called a Windows station, which also manages 347 00:16:21.279 --> 00:16:23.159 things like the clipboard for applications on. 348 00:16:23.120 --> 00:16:25.519 The same desktop, and GDI objects. 349 00:16:25.200 --> 00:16:27.639 Managed by the GDI subsystem, a separate part of Windows. 350 00:16:27.679 --> 00:16:29.879 This is giving us a really solid grounding. Now the 351 00:16:29.919 --> 00:16:33.240 book starts talking about different types of processes. Protective processes 352 00:16:33.320 --> 00:16:35.559 light PPL sounds like a security thing. 353 00:16:35.879 --> 00:16:40.360 It is introduced in Windows eight point one. PPL provides 354 00:16:40.480 --> 00:16:43.879 enhanced protection, making these processes much harder to tamper with 355 00:16:44.080 --> 00:16:48.519 or terminate, even for administrators like antivirus software. That's a 356 00:16:48.559 --> 00:16:52.039 key example. Yes, anti malware services often run as PPLs 357 00:16:52.039 --> 00:16:54.879 to protect themselves from malicious software trying to shut them down. 358 00:16:55.399 --> 00:16:57.360 There are different protection levels within PPL. 359 00:16:57.559 --> 00:17:00.679 Then there are minimal processes Windows ten features. These sound 360 00:17:00.720 --> 00:17:01.559 really stripped down. 361 00:17:01.600 --> 00:17:04.079 They are. They start with a completely empty address space, 362 00:17:04.240 --> 00:17:07.960 no executable no DLLs initially mapped, super lightweight. 363 00:17:08.039 --> 00:17:08.920 What uses them? 364 00:17:09.079 --> 00:17:11.759 The registry process is one example. Another key one is 365 00:17:11.799 --> 00:17:14.480 the memory compression process, which works behind the scenes to 366 00:17:14.519 --> 00:17:16.000 optimize RAM usage. 367 00:17:16.279 --> 00:17:19.359 Memory compression I might not see that in task manager. 368 00:17:19.039 --> 00:17:22.519 Sometimes it is hidden or aggregated, but Process Explorer will 369 00:17:22.559 --> 00:17:26.079 definitely show it. These minimal processes are typically created directly 370 00:17:26.119 --> 00:17:27.160 by the kernel itself. 371 00:17:27.480 --> 00:17:31.079 Fascinating how processes are evolving. The book also clarifies that 372 00:17:31.160 --> 00:17:34.839 PIDs are just special handle values internally, and it covers 373 00:17:34.920 --> 00:17:39.680 the statuses running suspended and not responding. Not responding is 374 00:17:39.759 --> 00:17:41.680 just for GUI apps, right correct. 375 00:17:42.039 --> 00:17:44.960 It happens when the main UI thread gets stuck and 376 00:17:45.000 --> 00:17:48.200 doesn't process window messages for about five seconds or more. 377 00:17:49.160 --> 00:17:52.599 Command line apps never show not responding, okay. 378 00:17:53.279 --> 00:17:56.960 The book then mentions PE files portable executable, the format 379 00:17:57.000 --> 00:17:59.480 for dot exe and dot dll files, and how they 380 00:17:59.519 --> 00:18:01.960 list their dependencies the other DLLs they. 381 00:18:01.880 --> 00:18:04.640 Need right in the import table. And when you launch 382 00:18:04.680 --> 00:18:07.839 a program, the Windows loader has a specific search path 383 00:18:07.880 --> 00:18:10.119 that follows to find those needed DLLs. 384 00:18:10.240 --> 00:18:12.079 What's the order it checks known. 385 00:18:12.000 --> 00:18:16.279 DLLs first, special system ones, then the application's own directory, 386 00:18:16.559 --> 00:18:19.839 then the current directory, then the main system directory System 387 00:18:19.880 --> 00:18:22.960 thirty two or siswas sixty four, and finally all the 388 00:18:22.960 --> 00:18:24.519 directories in the system's path. 389 00:18:24.440 --> 00:18:27.200 Environment variable and if it can't find one, you get. 390 00:18:27.039 --> 00:18:29.720 That dreaded air message box and the process usually fails 391 00:18:29.720 --> 00:18:32.000 to start. Dependency loading is critical. 392 00:18:32.079 --> 00:18:35.240 Then we get to actually starting processes create process. Wow. 393 00:18:35.240 --> 00:18:36.400 Look at all those parameters. 394 00:18:36.440 --> 00:18:39.519 It's like the master control panel for launching applications. You 395 00:18:39.559 --> 00:18:43.319 specify the command line security settings, whether handles are inherited, 396 00:18:43.400 --> 00:18:44.680 creation flags. 397 00:18:44.359 --> 00:18:48.160 Creation flags like creating new console or create suspended exactly. 398 00:18:48.200 --> 00:18:51.039 Also the environment variables, the starting directory, the startup INNEFO 399 00:18:51.119 --> 00:18:53.680 structure which controls the window appearance, and you get back 400 00:18:53.720 --> 00:18:57.079 the handles and IDs in the process information structure. Huge 401 00:18:57.119 --> 00:18:58.240