Michaelwhittaker, this is getting too far afield from what I understand to be the purpose of this forum, but let me try to answer your questions in minimum terms, so as to redirect discussion here to what this forum is for (and my apologies to all for being so nit-picky about the difference between Ram (to which the game will only have indirect access, through the OS), virtual memory (which is mapped by the OS to Ram and Swap file space, and is what the OS gives the game for its code and data) and the amount of Ram on the system (the value of which the game can ask of the OS, and may use for special things, like deciding not to run, or limiting map sizes, or other such start of game decisions).
Maintenance and test programs are specially privileged programs that get permission from the OS to perform their functions. Since we are dealing with a game we do not need to be concerned about privileged programs or how they get their privileges.
Windows is an OS, (so is Linux, and Apple's MAC, and Android, ...) and must know about, and keep track, of all the resources available on the system. Games must ask the OS for access to (not control of) these resources. (Your "system configuration" is a file where your OS recorded what resources your OS found on your PC and what you told the OS about how you wanted to use those resources.)
Each program runs in its own address space. Address space sizes can differ between machine types. The business machines I coded for were limited to 31 bit address spaces (their size was increased after I retired), which meant programs were designed for execution in address spaces limited to 31 bit addressing, theoretically 2G of virtual memory (less what the OS had to have in each address space). A program could repetitively ask the OS to map as much virtual memory as it wanted and the OS would return the address of the space it allocated to the request. When the address space was exhausted, the OS would reply to the request with an error code. I won't go into the risks this entails, but those risks are up to the program to manage.
The end object of all compilers and assemblers is object code (more descriptively and perhaps archaically called machine code) which is stored for later, and potentially repetitive, execution. (Interpretive languages are another can of worms.) A designer of a compiler can choose whether an internal or external assembler is to be used, or convert the input directly into machine code. The compiler language does not dictate this choice. Historically (again, perhaps archaically) the creation of an assembler listing was very valuable to the programmer in debugging. These days programmers that understand assembler code, or even machine code, are rare, so if a compiler is capable of producing an assembler listing, it is only there as an option.
I think we should take the rest of this off line, if you wish to discuss any more of it.