Windows - a brief guide inside

[Twigman]

was someone bored today then?

[Big RICHARD]

I thought BIOS was stored on non-volatile EEPROM? Only the system clock requires battery backup.

[Paul Adams]

I thought BIOS was stored on non-volatile EEPROM? Only the system clock requires battery backup.

Good point, amended accordingly - I still hark back to the days of Complementary Metal Oxide Semiconductors you see

Interestingly, one of my (Shuttle) machines was recently suffering constant resets of its BIOS when disconnected from the mains and that was the result of a failing battery which is why I didn't think it any different.

[Big RICHARD]

You might lose your BIOS settings without the battery, but the BIOS itself is stored in non-volatile memory. I think settings are stored in non-volatile memory too in newer boards.

Ahhhh lovely lovely CMOS.....those were the days!

I remember when this was all fields

[/nostalgia]

[yamangman]

Only just read this thread, for anyone who cares to learn more about Windows it's certainly useful and well written. If you ever consider expanding it I would recommend an overview of marshalling (serilization) and maybe GUID's and COM would be quite informative to your 'above-average' Windows user.

[dangel]

Nice job but i'm certainly not giving up on base 2 - a kilobyte will always be 1024 bytes to me Of course, should they radically alter addressing to align with the 'scientific' POV of 1000bytes then i'll change my errant ways lol But in the real world my compiler doesn't accept this odd POV..

[dangel]

Only just read this thread, for anyone who cares to learn more about Windows it's certainly useful and well written. If you ever consider expanding it I would recommend an overview of marshalling (serilization) and maybe GUID's and COM would be quite informative to your 'above-average' Windows user.

Perhaps more aimed at developers than 'power users'? If you did you'd have to start talking about assemblies etc too in order to keep up with whats current.

[yamangman]

I don't know about that. It's certainly a system that is central to what the Windows platform is/was all about, and would fit well into the section about threading and simultaneous instances of identical processes, not to mention central to user mode/kernel mode operation.

Perhaps more aimed at developers than 'power users'? I you did you'd have to start talking about assemblies etc too in order to keep up with whats current.

[rado354]

Very nice and useful, thanks!

[Paul Adams]

=====================================================================
8. Windows Vista
=====================================================================
As touched on briefly, some things are slightly different in the newest version of the NT kernel (6.0), this is an update to the main post which I might [edit] as time goes by to highlight some of the most important ones.

I am not going to bother with the "eye candy" features which are what a lot of people focus on as the most obvious changes and then start to grumble that on the strength of this it is not worth upgrading to - you have probably seen plenty of demonstrations of Aero Glass & Flip 3D already.


Image-Based Installation
During setup of Vista you are prompted for your product key, and depending on which type of key you enter you will get different components installed - there is not a separate DVD for the Basic, Home, Premium, Ultimate, etc. version.

You can skip entering the key and select to enter it later (within 14 days), but then of course you need to specify which version you have purchased as it cannot automatically determine it.

There are, however, different DVDs for the 32-bit and 64-bit versions.


"Session 0"
On previous versions of Windows, when you log onto the machine directly (or via a "console" connection through Terminal Services) you are logged onto what is known as session number 0.

Every process running has to have a session associated with it so that any output can be directed to the correct device/user and when the session is shut down the processes will be terminated correctly.

"Why not just look at the user the process is running as?" you may ask - the answer is that this is not unique as one user account may create multiple sessions on the same machine, and there is a possibility of launching processes in your session with another user's credentials, so it is not a unique identifier.

As every process has to have a session to run inside, what about the system processes and all services?
They also run in session 0.

This created a few quirks around Terminal Services interacting with background services, as well as the lack of distinction between console (user) processes and services.

With Vista the first user session to log on will create session 1, while session 0 is now the "secure desktop" which is where the System and background services will execute.


User Account Control (UAC)
UAC is called the "Over The Shoulder" (OTS) procedure which ensures that the user is aware that a program they are launching is attempting to (or will require) access to sensitive parts of the OS.

Programs which state in their Program Execution (PE) header that they will need to be elevated to work properly will cause the desktop to darken slightly and make the only active window a prompt to verify that the user really wants to launch the program and knows that it might be asking to make changes to the system.

The process, if allowed to run, will actually get spawned in the secure desktop.


Task Manager & Registry Editor
UAC can be invoked as soon as a program starts, or explicitly when a program is running to request elevation.

An example of a tool which will request elevation on being launched is the Registry Editor - it only has the one function and it is definitely potentially dangerous so must only be available to those with the correct privilege (member of Administrators group) and kick on the OTS procedure.

An example of a tool which a regular user can launch and then later decide to elevate is Task Manager - any user has the right to view the processes in their own session, but not other sessions (including the secure desktop), so there is a button in Task Manager "Show processes from all users" which will, after an OTS prompt, kill the current Task Manager and relaunch it in the secure desktop session.
Now this process running on the secure desktop has permission to see all processes on the system.

It is possible to flag programs as requiring administrative privileges where non-administrators are denied access, or "highest available" where users get the process launched in "regular" mode with some features disabled whilst administrators get the OTS prompt.
This is controlled by the "requestedExecutionLevelLevel" field in the manifest associated with the program.

A regular user logged on would need to right-click and "Run as administrator" and then authenticate with administrator credentials in order to launch it elevated to make administrative changes.

An example here would be an application which has a menu option to "set as default program for this file type" - if a regular user launched the program then this will fail (but through virtualization the application will think it worked), but if launched elevated it will take effect.


Windows components which are tagged as administrative (requireAdministrator) now have a shield on or next to their icons/buttons so you can see which will trigger UAC.

UAC is active for every single user account except the built-in Administrator account, which is disabled by default except when booted into Safe Mode.
Members of the Administrators group are not exempt from UAC.
UAC can only be disabled globally, not on a per-user basis.

Task Manager also had an overhaul and now has a tab for services, from where you can start & stop them with a right-click, and the ability to produce a complete user-mode dump from a process (without killing it) by right-clicking it and selecting "Create Dump File".

On the Processes tab you can also see which processes are being "virtualized", which basically provides a compatibility mode that applications can run in where they think they are updating or using OS components or registry values but they are really accessing their own private sandbox - this is to prevent installation of Product A regressing some modules or making registry changes and affecting the functionality of Product B.


SYSTEM Account NTFS Permissions
Running as an Administrator previously gave you virtually complete access, and often those few things you could not do as an Administrator you could get round by launching a process using the SYSTEM account.
Now, there are parts of the OS which even SYSTEM does not have access to because it does not require them.

One example is the Windows Side-By-Side (WinSxS) folder which is controlled exclusively by the "TrustedInstaller" user account as modifications to side-by-side installations of DLLs for applications should only be made by the Windows Installer service, and installation programs should be using APIs to make requests to register them.

There are some poorly-written setup programs which will fail to install on Vista because they skip the use of documented APIs and try to copy & register their DLLs manually which is now a potential security hole that has been plugged.


Signatures
Verifying the authenticity of the origin, or integrity of data is achieved through signing and verification of the signature.
This is not a new concept, manual MD5 hash checking has been around for years, but now it is being used more within Windows itself.

Launching an application, based on its location, may prompt with an "are you sure you want to run this" message which has to be confirmed - if, for example, the executable is held on a remote (and hence possibly untrusted) server.

Signing of drivers has also been available for a long time, and through system (or group) policies it is possible to enforce only drivers with a signature to be installed on the system.

With the 64-bit version of Vista kernel mode drivers must be signed in order to load (even if you manage to set the policy for installing unsigned drivers or get them registered via some back-door method).
Windows will bluescreen and reboot if an attempt is made to load an unsigned driver if driver signatures are enforced - the only way to allow them to load is to use the F8 key during boot and temporarily (for that session) disable the driver signature enforcement.

If a signed driver is modified or replaced after installation, then it will fail the signature check and refuse to load if signatures are enforced.


User Mode Driver Framework (UMDF)
As mentioned before, all bugchecks (bluescreens) are caused by one thing - unhandled exceptions occuring when executing kernel-mode code - and this means that we are susceptible to crashes caused by 3rd party drivers doing something they shouldn't.

UMDF allows devices to be controlled through code only executing in user-mode, so in the event that they are unstable it will not crash the system - an example of where this will be of major benefit is with audio device drivers in particular.

For those that are unhappy with the enforcing of kernel-mode driver signatures in 64-bit Windows (it is here to stay), they need to address if the driver really needs to be in kernel-mode anyway, because chances are that they do not and should be rewritten.


ReadyBoost
There are a few misconceptions around what this does - it is not an extension to "normal" RAM by plugging in USB storage devices, it is specifically to provide a very fast, large cache to improve system performance.

Basically if a USB 2.0 storage device with a high-enough throughput is connected, a chunk of it can be used to store (in an encrypted format for security) data which might be useful if available instantly without consuming regular memory or being delayed by having to be retrieved from the hard disk.

If you remove the device then Vista just carries on and loses the benefit of the cache but it cannot cause any crash or corruption of essential data (hence why it can't be used as extra RAM, as surprise removal of the device would cause programs and possibly the OS to crash).


Boot Configuration Data (BCD)
BOOT.INI and NTLDR are no longer used - the Boot Configuration Data store contains the boot options and WINLOAD.EXE is the OS loader for Windows Vista.
The BCD store is manipulated using the tool BCDEDIT and is architecture-independent.


Local Kernel Debugging
Previously it was possible to debug the running kernel by launching a debugger as an administrator - now this is blocked unless the OS was booted with the BCD option "/DEBUG" set.


Extra Information
"Developer Best Practices and Guidelines for Applications in a Least Privileged Environment"
http://msdn.microsoft.com/library/de...cProtVista.asp

"Application Compatibility Toolkit"
http://www.microsoft.com/technet/pro...y/default.mspx

"Vista Performance"
http://www.microsoft.com/windowsvist...rformance.mspx

"About BCD"
http://msdn2.microsoft.com/en-us/library/aa362639.aspx

"Kernel Enchancements for Windows Vista and Windows Server Longhorn" (Word Document)
http://download.microsoft.com/downlo.../kernel-en.doc

"10 Things You Need to Know about Deploying Windows Vista"
http://www.microsoft.com/technet/tec...t/default.aspx

[kidzer]

Yay, another addition to an already awesome guide

[johnny02004976]

Yay, another addition to an already awesome guide

agreed, this is extremely useful

[kidzer]

Yep, I've the rest printed off, this shall join it once I can be bothered to take the printer through here!

[Mattus]

Very useful guide, explained a lot of stuff to me which I'd always wondered

[redflyingpig]

Thanks, it's a great post to learn!

[Jenny_me]

Thanks !!! this thred is really informative

Jenny