Actually, there are two parts to a video driver on Windows NT, in all versions up to 5.2. In the "Windows 2000 Display Model" (the same one used in NT4), the vendor supplies a display driver, and a miniport driver.

The miniport handles things like resource allocation, memory mapping, handle interrupts, etc. This has always been in kernel mode, because it has to talk to the hardware.

The display driver is for high level drawing and rendering commands. It provides accelerated interfaces for GDI, DirectDraw and Direct3d. This, along with the Win32 windowing and graphics servers (left side of original diagram), used to live in user mode int NT3.x inside of csrss.exe with winsrv.dll. CSR still contains many functions that were never moved into kernel mode in win32k.sys.

Performance was one reason to move the display driver and winsrv into kernel mode, but I guess the biggest reason was to simplify the interface between the Win32 server and user mode clients by eliminating all the IPC marshaling. Win32k can now just reach into the client process's memory, same pointers and everything, instead of packing things into shared memory or an LPC messages.

Vista's new display model is more complex, but for the most part has a user mode display driver again.

It's called price discrimination. More editions help Microsoft soak up more consumer surplus.

The 6581 SID chip, which produces sound on the C64 is not programmable. The 6510 CPU has to spoon feed it commands to produce a song.

.MID files and windows metafles are a sequence of commands with parameters and (for MIDIs) timings that describe content. These commands are a high level description of the content. A generic player is capable of interpreting these instructions to render output. The C64 never had a common format like that for music. Instead, each song is a unique program for the 6510 CPU dedicated to a single song that outputs through the SID chip. Instead of describing notes directly, it has 6510 machine code instructions for loading registers, doing arithmetic, storing to memory, controlling hardware, etc. just like it was a real computer. These are usually created by excising the music portion of a larger program to make it a standalone program that just plays a song with no input. To play a song, an emulator for the 6510, 6581, memory, ROM and enough other hardware is required to let the sound program execute like it would on a real 64, controlling emulated the SID chip the same way.

This format is popular because the vast majority of original music was already in program format, and the machine code programs are much shorter than a literal description of the program's SID output.

See MOS Technology SID - Software emulation

I agree that Apple should be able to verify that full emulator is safe to execute arbitrary code that can't escape, but as other posters have noted, this may not be Apple's only concern.

That's mostly right, but I think the kernel's role is a bit smaller.

Tokens, which identify the access that a process gets, and access checks against kernel objects with security descriptors are indeed handled by the kernel. Integrity levels attached to tokens and mandatory integrity labels are new properties that the kernel allows for tokens and security descriptors and consults during an access check in Vista. That's really the extent of kernel involvement for integrity labels.

The decision of what to put into a token or security descriptor has always been up to user mode components. Winlogon uses a restricted, medium integrity version of an administrator's token for starting the shell. IE launches a low integrity child process of itself. Certain functions, like Win32's CreateProcess check the image manifest for requestedExecutionLevel and enlist the seclogon service if needed to elevate the new process. The kernel syscall to create a process doesn't do any of this.

Windows messages are implemented by the Win32 subsystem, not the kernel (even though part of Win32 does run in kernel mode in win32k.sys). The kernel does supply several IPC methods, but not this one. Win32 does the target window integrity check (UIPI).

I would say that UAC is a user mode construct, mainly implemented in winlogon, kernel32.dll, LSA and the seclogon service. The kernel does enforce restricted tokens and integrity labels for kernel objects though. I can't say that the NT security model has been followed as well as it could be (part of this is due to its complexity), but Vista (and UAC) do use a lot more of it, and seem to have avoided serious security or compatibility problems. One issue is that NT was designed for use on a LAN with trusted programs and the security system was for protecting users and the system from unauthorized users, not from malicious programs. Thus, the owner of a computer is the Administrator, since the system doesn't have anything that user shouldn't have access to. Unfortunately, this doesn't work so well when that admin can't trust all the programs on the system to behave.

In the book, that's what happens, except that Bowman is able to get to a shelter before decompression completes.

I was thinking of one transaction, where the file is truncated and new contents are written. Either both entirely happen, or neither do.

OTOH, I think you're on to something with a simplified transaction system that allows atomic pairs of operations that can be used to implement things like this, e.g. replace one file with another, ensuring it's written completely on commit.

EFS.

Right click on your profile, go to properties, advanced, check the encrypt box. Alternatively, cipher /e /s on your profile dir. 5 seconds of googling surely would have revealed this.

It sounds like the correct solution is for the file system to implement transactional semantics. That is what the applications need and were incidentally getting, despite it not being in the spec.

Why isn't this being considered as the solution? There are other major OSes have implemented basic atomic transactions in their filesystems successfully, why not Linux?

Then you have some other corruption problem that has nothing to do with the layout of user profiles.

Besides, I didn't have to google to determine the layout, I could see it after a minute of browsing. Google provided me with more formal documentation to reference in my post.

I never said there weren't other problems. I consider the default name for those paths to be hideous. Plus with the ridiculous and horrible limitation that is MAX_PATH in so many Win32 components, that is path real estate that we can't afford to spend. Parts of Win32 go to great lengths to work around MAX_PATH, including searching for shorter surrogate paths to use instead. .NET, foolishly built on Win32, has the same problems.

At least they changed the defaults to "Users", "Documents" and "AppData", etc in Vista.

I was responding to the specific complaint that profile paths were arcane and not understandable.

The preference files in the Windows user directories are hidden in arcane locations.

It took me 5 seconds to google some docs for user profile paths: User Data and Settings Management

Makes sense that the Outlook data would be in C:\Documents and Settings\\Program Data\Microsoft\Outlook but it's not.

Instead, the roaming stuff goes into:
C:\Documents and Settings\USERNAME\Application Data\Microsoft\Outlook
And the non-roaming stuff goes into
C:\Documents and Settings\USERNAME\Local Settings\Application Data\Microsoft\Outlook
Doesn't seem so awful.

The only way to ehfin find it is to back the stuff up! What if the computer crashed and I can't RUN outlook???? I'm hosed (this actually happened)

Copy the user profile over?