Welcome to the deep dive. Today. We're really peeling back the layers of your Windows ten computer.
Yeah, going straight to the core.
Exactly how software actually interacts with the operating system. One of you asked for a deeper look, and well, here.
We are, absolutely and we've got a really good technical book to guide us. We'll be digging into the key insights on the fundamental stuff.
Like processes, threads.
Right, memory management, and that crucial world of IO input output operations.
Our mission then for this deep dive is to get right to the heart of how Windows actually juggles all the programs you run and the resources they all need.
We're aiming for those moments where it just clicks.
Yeah, those aha moments where you think, oh, that's why my system does that. So let's start at the very beginning processes.
Okay, so book right away makes this really important point. It might even surprise you. We usually think of a process as the thing that's running, but it's actually more accurate to think of it as a management object, a container. Basically, I contain yeah, the actual work, the code execution that's done by threads within the process.
Okay, So processes are like maybe office buildings, and threads are the workers inside.
That's a great analogy. Exactly one can't really function without the other, but they definitely have distinct roles.
Interesting, So if the process isn't the runner, what does it actually own what's inside this office building?
Well, a process is responsible for some critical things. First, it gets its own private address space. Think of it like its own dedicated chunk of memory, its floor plan. Okay. Then it holds one or more threads, the workers. It also keeps a handle table.
A handle table like an inventory list short of.
Yeah, yeah, an inventory of all the system resources it's using. And critically, it's assigned a unique process ID.
Or PID PIDs. Right, we see those in task Manager all the time. Now, the book says they're unique but also reusable. How does that work? I sort of assumed a PID was like permanent.
Yeah, that's common thought. But the key thing is a PID uniquely identifies a currently running process.
Ah only while it's active.
Exactly as long as that kernel object representing the process exists, the PID is its tag. But once the process finishes, poof that kernel object is gone.
And the number can be used again.
Later, right for a completely different new process it's like reusing raffle ticket numbers for different draws.
That makes total sense, and it's a good reminder. Then, when we see say multiple Chrome Windows Open or Word instances, each one is its own distinct process, with its own PID, its own resources, even though they all started from the same program file.
Precisely, the dot exc file is the blueprint, but each running instance gets its own private stuff. Now about that address space, the private memory. Yeah, the book lays out some different sizes. It depends on whether it's a sixty four bit or a thirty two bit process.
Right. For sixty four bit processes on sixty four bit Windows, we're talking massive amounts of space, right, like eight terabytes or even one hundred and twenty eight.
Terrabyte, Yes, staggering numbers. Eight terabytes on Windows eight and earlier, and then one hundred and twenty eight terabytes from Windows eight point one onwards. It's like having an almost infinite address book.
Okay, but what about those older thirty two bit programs, the one still running on our modern sixty four bit systems.
Ah Okay, that's where it gets a bit more nuanced. By default, a thirty two bit process only gets a two gigabyte address.
Space only two gigs.
But if the program was built with a special flag, a setting called large address aware.
Large address aware.
Yeah, if it has that flag, it can actually access up to four gigabytes on a sixty four bit system.
So it doubles its potential memory pretty much.
Think of the flag as the thirty two bit program telling the sixty four bit system, Hey, I know how to handle more memory addresses than usual.
Okay, so that flag signals it's ready for more space. Now. Another key piece here seems to be these dynamic link libraries DLLs.
They're everywhere we really are. Dls are essentially packages. They contain codeta resources things a program might need, and they get loaded into a process dynamic or dynamically, meaning either when the process starts up that's called static linking even though it sounds contradictory, or later on when the process explicitly asks for it, which is true dynamic linking.
The book mentions you can't just run a DLL directly, right because they don't have that main entry point like an executable.
Correct, no main function. But the really interesting part and a big efficiency thing is the memory sharing.
Ah, yes, tell me about that.
So when multiple processes are using the same DLL, especially those common Windows DLLs in the system thirty two folder.
Like kernel thirty two dot dll.
Exactly or User thirty two dot DLL. The actual code from the DLL can be shared in physical.
RAM, so you don't have multiple copies loaded, right.
It avoids wasting precious RAM. It's a huge win.
And these particular DLLs, the subsystem ones, they're the ones that actually implement the core Windows API. Aren't they the functions that applications call to talk to the OS.
That's precisely it. They're the gateway for norm user mode applications to access the underlying power of the Windows kernel. And this focus is really what the book is all.
About, which leads us nicely into the broader Windows architecture user mode versus kernel mode.
User mode is where our everyday apps live, Notepad, your browser games, plus those subsystem DLLs we just talked about, and also something called win.
RT and kernel mode is the deeper layer, the engine room.
Correct, that's the privileged part of the OS where the core components run, managing hardware security, that kind of thing.
So user processes, subsystem DLLs and win RT, what's.
That win RT or Windows run Time is a newer API layer. It came in with Windows eight, mainly for those Universal Windows Platform apps UWP apps.
The ones from the Microsoft Store mostly.
Yeah, it's built on an older technology called comm Component Object Model, which is all about software components talking to each other. And win RT supports multiple programming languages.
Interesting, and it's not just for UWP apps. No.
Recently a subset of win rts is actually available for traditional desktop applications too. Seems like Microsoft is trying to bridge the gap between those two worlds.
Makes sense now for anyone listening who's thinking about actually doing some Windows system programming. The book mentions Duols Visual Studio primarily.
Yeah, Visual Studio is the main integrated development environment the ID. The book emphasizes just getting your development set up right from the start.
And it mentions that even doing a basic Hello World application can teach you something.
Absolutely. Just compiling it shows you the process and you might notice subtle differences depending on whether you build it for a thirty two bit system that's by eighty six or a sixty four bit system by sixty four.
Okay, And following on from that, character encoding Unicode this sounds important.
It's crucial, especially for software that needs to work globally. There's a Unicode setting usually set by default and visual studio when you.
Compile, and that affects how strings are handled.
Yes, yes, it determines whether a type like lpctstr in the code represents text using UTFS sixteen, which can handle pretty much any character from any language, or the much more limited ASCI standard.
So UTS sixteen is generally preferred definitely, and.
You see this directly in the Windows API functions themselves. A function like creep mutex, for example, isn't really one function. Well, it's like a macro. The compiler expands it to either create mutex WZ the WS for wide characters UTF sixteen, or create mutexa A for ANSI or ASCI ah.
Okay, So using Unicode means you automatically get the w versions, which prevents your text getting garbled if it contains non English characters.
Exactly. It voids data loss and makes your software work correctly with international text, absolutely vital these days.
The book also flags safer ways to handle strings right like wccswise.
Yes and functions from the struceay dot EA CHEDDAR. It's quick reminder that the old C style string functions can be risky, you know, buffer overflows and security issues. These newer functions are designed to be much safer.
Good practice to use them and for the code example. In the book, it mentions helper libraries WISHL and WTL.
Yeah, the Windows Implementation Library WIL and Windows Template Library WTL. They basically provide convenience C plus plus wrappers around the raw Windows API.
Makes things less tedious pretty.
Much save if you write in a lot of boilerplate code. Makes development quicker and less error prone. The book also touches on Hungarian notation.
Oh yeah, that naming convention like hend for a window handle exactly.
Or else dir for a pointer to a string. It's an older style you'll see in the Windows API documentation. In older code, it embeds the variable type.
In the name, A bit of a historical thing. You don't have to use it in new code.
No, not really, It's just good to recognize you when you see it. Okay, So moving on. No system programming discussion is complete without error handling. What happens when things go wrong?
Right? How does the Windows API tell you something failed?
There are a few common patterns you'll see. Functions return a bool. Generally, non zero means success es.
Zero means failure, but don't check for exactly true.
Right The book warms about that success might be one, or might be two or something else non zero, Just check if it's zero or not. Think you have types like l status or long. With those, zero usually means success. The constant error success is actually zero. Any positive value indicates a specific.
Error code, an h result.
A result is common two, especially with Calm and Newer APIs zero or positive generally means success as okay is zero and negative values signal different errors.
So when a function does fail, how do you find out why?
The main way is to immediately call to get last air function immediately Yes, because the next API call might overwrite the error code and critically get laster gives you the error code for the current thread.
Ah, So each thread has its own last error value precisely.
If you have multiple threads, you can assume one thread's error relates to another's failure. It's threads specific.
Got it? Okay? What about finding out Windows version? The book says the old way get version X is kind of deprecated now.
Yeah, it's not recommended for various reasons related to compatibility settings. The modern approach is better, which is there's a header file version all PRIs dot age with a bunch of simple functions like is Windows expra, greater, is Windows ten or greater is when a server and so on.
They just return true or false.
Exactly, much cleaner for most common version checks. Under the hood they use a more fundamental function called verify version info. Usually the helpers are all unique.
Okay, nice and simple, right, let's ship gears. Objects and handles. These sound absolutely central to Windows.
They are fundamental. Handles are everywhere. The book describes them as basically identifiers for kernel objects.
Kernel objects being what kinds of things.
These are the core resources managed by the Windows kernel itself, things like files you open, processes that are running threads doing work, synchronization tools like Mutex's events, all the basic building.
Blocks, okay, And the handle is how our program.
Refers to them, exactly. It's an abstract token, like a ticket or a claim check. Your user mode program uses the handle to tell the kernel which object it wants to.
Interact with, so it provides a layer of abstraction and security.
Yes, you don't get direct access to the kernel's internal data structures. You operate through the handle.
So when we call say, create mutechs to make a synchronization object.
If it works, you get back a handle value, a number basically that represents that mutex object living down in the kernel. And if it fails, the return values usually zero or null. And then there's open mutex, which is specifically for getting a handle to a mutex that already exists and has a name.
Right. Create mutex is interesting because if you give it a name, it can either create a new named mutex or it can open an existing one with that name.
How do you know what happened?
Even if create mutex succeeds in opening an existing one, if you call get last ray after, it will return error already.
Exists, ah okay, whereas open mutex just fails if the name mutex.
Isn't there, correct, it won't create one for you.
Now, the book breaks down what's sort of conceptually in a handle, A pointer to the object and access mask and flags.
Yeah, that's a simplified view. The access mask is super important. It defines what operations you're actually allowed to perform using that specific handle, like permissions exactly. For instance, if you want to terminate another process. You first need a handle to it. You get that using open.
Process, but when you call open process you have to explicitly request the process terminate access right. If the handle you get back doesn't have that right in its access mask, then calling terminate process with that handle will just fail.
So the handle encodes the permissions. What about the flags inheritance Protection from close.
Inheritance means whether a child process created by this process automatically gets a copy of the handle. Protection from close handle flag protects from close is a safety feature makes it harder to accidentally close a really important handle.
Can you change these flags?
Yes, using set handle information and get handle information. And if you really want to see all the handles a process has.
Open process explorer.
Process Explorer from cysinternals is the tool. It's invaluable. It shows the handle value, the type of object, file, thread, mutex its name if it has one, the object's address in kernel memory, the raw access mask, and even a decoded human readable version of the access rights like looking at the process's internal toolkit.
Definitely a must have tool. Now, managing these handles in code, especially C plus plus plus A, seems error prone. The book introduces a smart handle wrapper class.
Yes, it demonstrates a concept called r AII. R AI resource acquisition is initialization. It basically means the handle resource is acquired when the C plus plus wrapper object is created, and crucially, it's automatically released. The handle is closed when the wrapper object goes out of scope or is destroyed.
Ah, so it cleans up after itself. Prevents handle leaks exactly.
It makes handle management much safer and easier. The example class also prevents axidel copying of handles, but allows transferring ownership using something called move semantics. Very useful C plus plus features neat.
Okay, What about object naming and sessions? Names aren't always global usually?
Know when your regular user application creates a named object like a name mutex, that name is typically only visible within your current user login session.
So another user logged in wouldn't see it.
Correct unless you specifically create it in the global name space.
How do you do that?
You prefix the name with global like global mouse, shared, mutechs. These live in a special base named objects directory in the kernel's object manager name space.
Can any application do this?
Well, there's a catch. Modern sandbox apps called app containers usually don't have the permissions to create objects in the global name space. It's mainly for services or older desktop apps needing system wide coordination.
So if you have two separate programs, maybe even started by different users, they could use these global named objects to communicate or synchronize.
Yes, that's a primary use case. One process creates the named object, create mutex with the global name, and another process can open it using the same name, open mutext, or even create utechs. Again, the name acts is the rendezvous point.
Interesting. Another mechanism mentioned is handle duplication using duplicate handle. What's that about?
This lets you take a handle you have in your process and create a new handle, potentially in a different process that refers to the exact same underlying kernel object.
Why would you do that?
A common reason is when a parent process starts a child process, the parent might want to give the child access to one of its own open handles, like maybe it's standard input or output pipe, So.
You duplicate the parent's handle into the child's process space.
Exactly, you need a handle to the target process with the process you panel permission to do this. You can even duplicate a handle within the same process if you need another handle to the same objects, maybe with different access rights.
Okay. The book then briefly mentions user objects Windows menus and GDI objects bitmaps, fonts. They're handled a bit differently.
Yeah. User objects like Windows don't use reference counting in the same way kernel objects do. The first process to destroy one affects everyone sharing it and their handles their scope to something called a Windows station, which also manages things like the clipboard for applications on.
The same desktop, and GDI objects.
Managed by the GDI subsystem, a separate part of Windows.
This is giving us a really solid grounding. Now the book starts talking about different types of processes. Protective processes light PPL sounds like a security thing.
It is introduced in Windows eight point one. PPL provides enhanced protection, making these processes much harder to tamper with or terminate, even for administrators like antivirus software. That's a key example. Yes, anti malware services often run as PPLs to protect themselves from malicious software trying to shut them down. There are different protection levels within PPL.
Then there are minimal processes Windows ten features. These sound really stripped down.
They are. They start with a completely empty address space, no executable no DLLs initially mapped, super lightweight.
What uses them?
The registry process is one example. Another key one is the memory compression process, which works behind the scenes to optimize RAM usage.
Memory compression I might not see that in task manager.
Sometimes it is hidden or aggregated, but Process Explorer will definitely show it. These minimal processes are typically created directly by the kernel itself.
Fascinating how processes are evolving. The book also clarifies that PIDs are just special handle values internally, and it covers the statuses running suspended and not responding. Not responding is just for GUI apps, right correct.
It happens when the main UI thread gets stuck and doesn't process window messages for about five seconds or more. Command line apps never show not responding, okay.
The book then mentions PE files portable executable, the format for dot exe and dot dll files, and how they list their dependencies the other DLLs they.
Need right in the import table. And when you launch a program, the Windows loader has a specific search path that follows to find those needed DLLs.
What's the order it checks known.
DLLs first, special system ones, then the application's own directory, then the current directory, then the main system directory System thirty two or siswas sixty four, and finally all the directories in the system's path.
Environment variable and if it can't find one, you get.
That dreaded air message box and the process usually fails to start. Dependency loading is critical.
Then we get to actually starting processes create process. Wow. Look at all those parameters.
It's like the master control panel for launching applications. You specify the command line security settings, whether handles are inherited, creation flags.
Creation flags like creating new console or create suspended exactly.
Also the environment variables, the starting directory, the startup INNEFO structure which controls the window appearance, and you get back the handles and IDs in the process information structure. Huge amount of control.
And process priority classes affecting thread priorities.
Yes, ranging from idle up to real time. Most apps run at normal setting. Real time usually needs admin rights because it can really impact system responsiveness if misused.
That startup infos structure too, controls window size position, whether it's shown, minimize, maximized, even redirecting standard input out pewter.
It's how a parent process shapes the initial state of its child. The book also gives a nod to a useful visual studio extension for debugging child processes and reminds us again you can't just launch UWP apps like normal executables.
Right, They need that special activation mechanism, which brings us back to PPL again briefly.
Just reinforcing that they have different signer levels, restricting access even preventing termination by admins. You can see the protection level and process explorer. The book shows. Trying to launch calculator fails if you just copy its command line.
Because it's a UWP app needs the proper.
Launch exactly, which involves using those Windows run Time win rt API. As we mentioned, the I Application Activation Manager interface is key. Using methods like activate application, you often need the app's full package name.
Okay. Then a quick mention of minimal and PICO processes. Again, minimal are kernel created. PICO processes are for things like the Windows subsystem for Linux WSL translating Linux calls.
Right, but not the main focus here?
Then, how processes end three ways? All threads exit exit processes call or termain it process from outside.
Pretty much even when your main function returns. In CC plus plus two, the runtime library calls exit process from the kernel's view the process ends when its last thread terminates.
And getting info about a running process, get exit code process, get process times for CPU usage.
Query full process image name. To get the executable path, you need to allocate a buffer for that one.
And listing all processes. The tool help thirty two snapshot functions.
Create tool help thirty two snapshot process thirty two first, process thirty two next. That gives you the basics like PID in name for everything running.
But to do more like terminate or get detailed info, you need open process first.
Yes, and you need to request the right access permissions. It might fail for protected system processes. Air five is access denied. AIR eighty seven often means invalid parameter. Maybe the PID doesn't exist anymore.
Debug privilege helps.
Sometimes yes, it lets you open more processes running elevated and visual Studio often grants it implicitly. For even more detail, there's WTS enumerate process X.
What does that give you things like.
The username, session id, detailed CPU times, handle counts, threadcounts, or rich review.
Okay, that's a lot on processes. Let's talk about jobs, grouping processes exactly.
Job objects let you manage a set of processes as a single unit Process Explorer actually shows if a process is in a job, how do you use them? Create one with the separate job object, then add processes to it using assigned process to job object. You can even have hierarchies of jobs.
But the real power is restrictions.
Definitely. Using set information job object, you can set limits on the entire group of processes in the job, things like total CPU time, total memory commitment.
You can limit UI interactions too, like blocking clipboard access.
Yes, there are UI restrictions you can apply the book mentions a sample app job monitor that lets you play with this, like limiting notepad CPU or blocking certain actions.
CPU rate control is newer Windows eight plus.
Reret Right, let's you set a hard percentage limit on the CPU usage for all processes in the job combined. Very useful for resource management and sandboxing.
Okay, super useful concept. Now let's dive into threads. We said these are the actual workers inside a process.
Yes, the independent paths of execution. They allow a single process to do multiple things concurrently, potentially using multiple CPU cores.
You create them with create thread. Need to give it a starting function, right.
The threads entry point function plus an optional parameter to pass to it, stack size settings, creation flags like create suspended if you don't want to run immediately and you get back a handle and a thread ID.
Tids are unique system wide like PIDs.
Yes. The book also mentions HyperThreading as MT, where one physical core looks like multiple logical processors to the OS.
Can boost performance, but potential cache issues can be.
Yeah, threads on the same physical core might compete for cash. You see logical processors and task manager usually can disable SMT in the bios if needed.
Now, terminating threads termat thread sounds.
Bad, very bad. Generally it's abrupt. Kills the thread instantly without cleanup can lead to resource leaks, deadlocks, corrupted data. Much better to signal the thread to exit gracefully itself. Okay.
Threads have stacks for local variables and handles like processes. You get one from create thread or open thread right.
Open thread is like open process needs a TID in permissions. Interestingly, threads don't have a built in name property in the kernel.
But there's a trick for debugging.
Yeah. Using structured exceptions to set a pseudoname helps identify threads in the debugger, and.
Choosing between c plus plus plus standard library threats and the Windows API.
Standard librarystd dot thread et cetera. Is cross platform, which is great, but the Windows API Create thread gives you much finer control over things like priority, affinity, stack size, which leads us to scheduling.
Right, How does Windows decide which thread runs when the scheduler and.
The key thing. Most threads are usually waiting, waiting for IO, waiting for a lock, et cetera. The scheduler focuses on threads in the ready state. It's priority based.
Higher priority runs first. Windows has levels from real time down to idle.
Correct. A thread's actual priority comes from its processes priority class plus its own relative priority within that.
Process and the quantum the time slice.
Yeah, how long a thread gets to run before the scheduler might switch. Yeah, It can vary client versus server tuning and the four ground apps. Threads often get longer quantums. Quantum stretching for responsiveness.
Can be tweaked in the registry WIN thirty two priority separation.
It can. Yeah. You can also control which ars a thread runs on process or affinity set thread affinity mask is the basic way set thread group affinity for systems with sixty four.
Processors and CPU sets a newer way to group processor Yes.
Windows ten introduce them more abstract way to manage affinity using functions like set thread.
THEEP sets now priority boosts. This sounds important for keeping things smooth.
Very the system temporarily boosts a threads priority after certain events like IO completing or a window needing. Attention prevents the UI freezing.
It decays back down afterwards.
Yes, after the thread runs for a bit four ground threads get a bigger boost when they wake up from a weight. It's all about perceived responsiveness.
Suspending and resuming threads. Suspend thread, ReSm thread Still a bad idea.
Generally, Yes, very easy to cause deadlocks. Better to use proper signaling. There are also ways for threads to yield voluntarily. Sleep baze gives up the rest of its time slice to another ready thread of the same priority.
Switch to thread yields more aggestively yes to any.
Other ready thread, and sleep infinite just waits forever until woken up.
It's amazing how much orchestration is going on. Okay, synchronization within a process. Why do we need it?
Because if multiple threads in the same process access shared data without coordination, chaos, race conditions, corrupted data, weird bugs.
The simple counter example shows this clearly.
Yeah, the final count is unpredictable for simple increments decrements, there are interlock operations.
Like interlocked increment. These are atomic, yes.
Hardware guaranteed atomic. The whole read, modify write happens as one indivisible step, save for simple updates.
For more complex stuff, protecting blocks of code.
Critical sections of the workhorse for that, within a process initialized critical section X, enter critical section to lock it, leave critical section to unlock. Only one thread can be inside the critical section at a time, and delete critical section when done.
Mutual exclusion. The hashcatch example uses one to protect.
A map exactly std dot unordered map isn't thread safe, so the critic section ensures safe access from multiple threads. The book also mentions ETW event tracing.
For Windows for diagnostics.
Yeah, powerful kernel level tracing can see image loads, context switches, tons of stuff, useful for deep analysis.
Okay, what about SRW locks slim reader.
Writer These are often more efficient if you have lots of threads reading share data but only occasional rights. They allow multiple readers or one writer acquires RW lock shared acquires our wots exclusive, et cetera.
Got it and condition variables used.
With a lock always with a critical section or an SRW lock. They let threads wait efficiently for some condition to become true. You call sleep condition variable CS or sleep condition variable SRW.
This atomically releases the lock while waiting yes.
And reacquires it upon waking. Other threads use weight condition variable or wake all condition variable to signal crucially, you must recheck the condition in a loop after waking because of spurious wakeups.
Spurious wakeups, they can and wake up even if the condition isn't met sometimes.
Yes, so you always loop while sleep condition variable. The producer consumer example demonstrates this pattern well with a shared queue right.
Newer primitives, too, wait and address very efficient way to wait for a specific memory location to change value, often without needing a separate lock and synchronization barriers like a Runov point exactly enter synchronization barrier. Threads wait there until a specified number of threads arrive. Then they all proceed together and C.
Plus plus standard library has its own versions std dot mutex std dot condition variable Yes.
Good for cross platform code, but often less control or potentially different performance characteristics than the native Windows APIs. Finally, the basic weight functions wait for single object, wait for multiple.
Objects, need the synchronize right for the object.
Handle yes, and you specify a timeout. They tell you if the objects signaled, if you kimbed out, or if there was an error.
Okay, that covers coordinating threads inside one process. What about between different processes?
For that, you need kernel objects with system wide visibility, usually achieved using named.
Objects like a named mutex.
Exactly create it with create viewtex and give it a name, maybe global prefix for system wide. Another process can use open mutex with the same name to get a handle to the same mutex. Then they use weight for single object and release mutechs to coordinate.
Process Explorer can show these named mutexes.
Yep and whether they're currently held. Semaphors work similarly.
Somemophors control access to a limited number of resources.
Right create with create semaphore, give it an initial max account and a name. Wait for single object, tries to decrement the count, release semaphor increments it. Good for managing pools of resources across processes.
Weaightable timers can also be named yes.
Create weightable timer with a name, set weightable timer to schedule it once or periodically. Other processes can open weightable timer and wait for single object. Can even trigger APCs and events.
Named events also possible.
Create event with a name, manual or auto reset, open event by name, use set event, reset event, wait for single object. Simple signaling between processes.
Interprocess APCs are less common.
Much less common and trickier named objects the usual way. The book also mentions weight for impuddle.
Waits for a GUI app to be ready.
Yeah waits until it's finished initializing and is waiting for input. Useful after create process and signal object and weight atomically signals one object and weights on another, avoiding certain race conditions.
Lots of tools for interprocess coordination. Let's move to thread pools, a managed way to handle threads.
Yeah, Windows provides a sophisticated threadpool big advantages, reuses threads, less overhead, manages resources, better limits concurrency automatically.
What do you use it? Simplest way?
Try submit threadpool callback, give it a function to run, and the pool schedules it on one of its worker threads eventually.
That it can do more weight callbacks yes.
Instead of blocking your own thread waiting for an object, tell the thread pool to weight, create threadpool weight, set thread pool weight. When the object signals, the pool runs your callback function. Much more efficient. Timer callbacks too, yep, create threadpool timer, set thread pool timer schedule callbacks ceriodically or one shot handled by the.
Pool and io callbacks rising operations.
Right to create thread poolio start thread Polio integrates acinc iiocompletion with the threadpool.
Can you create your own private pools?
You can create threadpool allows customization minmax threads, stack sizes, set threadpool thread maximum, et cetera. Need to close thread pool when done.
Callback environments, cleanup groups.
More advanced features environments, TP callback environ let you set priority, affinity, etc. For callbacks. Clean up groups help manage the lifetime of related pool objects. Together.
Thread pools seem very powerful, okay. Advance threading topics. Thread local storage TLS.
G LS gives each thread its own private coffee of some data. Use to get an index, then tlset value, TELS get value, operate on the calling threads specific slot for that index. No sink needed because it's thread private. TLS free releases the index.
C plus plus s thread local two Yes t lous.
Pec thread older and thread locals entered. C plus plus provide language level support for static TLS variables.
How do list threads again, tool help thirty two YEP.
Create tool help thirty two snapshot with th h three two CSS snap thread then thread thirty two first next gives TIDPID priority, CPU times.
Cash awareness, False.
Sharing important performance consideration. False sharing is when threads modified different variables that happen to be in the same CPU cache line, causing unnecessary cash and validations. Padding data structures can help avoid it.
Weight change reversal WCT for.
Dead's locks yes an API open thread weightchain, session get thread weight chain to analyze what locks and objects threads are waiting on. Can help diagnose deadlocks by showing circular weights.
And the concurrency run time. High level C plus plus library.
For Microsoft Ya provides tasks parallel loops agents simplifies many common parallel programming patterns.
Okay, nearly there. File and device io Create file and create file two are key absolutely fundamental for opening creating files, devices, pipes, tons of parameters, path access rights, read write, share mode creation disposition like creating new open existing flags and attributes.
File flag overlapped is crucial for ACNC io.
Yes, and paths can include for devices or things like symbolic links. Drive letters themselves are often similark.
Getting file info size.
Attributes, get file size x sixty four bit size, get file attributesx, get file information by handle for more details, set file information by handle. Can even modify some things reading.
And writing read file, write file, sync or async both. ACNC requires the file flag overlapped flag during create file and using an overlap structure. APCs are one way to handle ACNC completion, but iocompletion ports IOCP are more scalable.
IOCP involves create iocompletion port associating hands than worker threads, calling get cubed completion status.
Exactly highly efficient for servers handling many concurrent acinc io operations. Threadpool io create thread poolio is a simpler wrapper around similar concepts.
Canceling IO, conciliox yes, cancilo.
X for ACNC cancel synchronusio exist but isn't guaranteed to work.
Device io uses create file with device paths like physical drive YEP.
Then device iiO control since commands directly to the driver using control codes.
Finding devices, the set up DAPI right.
Set of digit class, DEEVS setup dynam device info. Setup DIET Device interface detail lets you find devices by type and get their paths.
Interprocess communication again pipes anonymous and named.
Create pipe for simple parent child anonymous pipes, create name pipe for more powerful. Name pipes can be duplex workover network. Clients connect using create.
File mail slots one way.
Yes, connectionless, create mail slot for server, Create fil rite file for client Yeah less common now also file finding find first file etcter and system info.
Get system info okay, last major topic. Memory management fundamentals Virtual memory.
The big abstraction. Each process gets its own private address s base managed by the virtual memory and manager. VMM uses paging to swap memory between RAM and the disc page file.
Memory states free, reserved, committed, free is unused.
Reserved allocates address range but no storage. Committed allocates storage RAM or page file commit, charge and task Manager is the system wide total committed.
Memory for a process commits size, private bytes is key, working set is RAM usage generally.
Yes, virtual size includes reserved, working set is physical. RAM. Process Explorer shows these well.
Process memory map shows layout code, DLL stack keep, Get process memory info, gives detailed stats.
Page faults working set size, pool usage, page file usage, and page protection. Read write execute is critical set by virtual ALC, change by virtual protect access violation if you break.
The rules virtual virtual query X lets you walk the address space.
Yes, gives in memory based information about regions, base size, state protection type. Let's you see the map programmatically.
And finally, WAWW sixty four for running thirty two bit apps on sixty four bit Windows file system redirection system thirty two versus siswell sixty four.
Exactly the emulation layer that makes it mostly seamless. Wow sixty four disabled whole sixty four f's redirection can turn off the file redirection temporarily if needed.
Wow. Okay, that was genuinely a deep dive. We covered so much ground.
We really did, from processes as containers, threads as the workers, through handles, synchronization nightmares huh.
And io memory basics.
It's a lot, it is. You know, one thing that always strikes me is that PID thing just being a handle value and those minimal processes completely empty to start with. That's pretty wild.
Yeah. And the whole dance of threads scheduling the boosts. It really helps understand why things feel responsive for sometimes why they don't and for you listening, even if you're not writing this kind of low level code. I think understanding these concepts gives you a much better feel for what your computer is actually doing under the hood.
It definitely demystifies some of it takes away the magic feeling.
So thinking about all this complexity. It's what makes Windows powerful, right, but it also feels like there are so many moving parts.
Absolutely, it's this incredible layering of abstractions and mechanisms built up over decades. It enables amazing things. But yeah, complexity can also mean fragility.
Sometimes it makes you wonder how does this foundation contribute to both stability and the occasional crash, And what other deep system areas might be interesting to explore next time, maybe digging into how memory actually gets allocated or how drivers work.
Definitely food for thought, something to mull over until our next deep dive. Thanks for joining us.