Inside the Windows Vista Kernel
Reader trparky recommends an article on Technet (which, be warned, is rather chaotically formatted). Mark Russinovich, whose company Winternals Software was recently bought by Microsoft, has published the first of a series of articles on what's new in the Vista kernel. Russinovich writes: "In this issue, I'll look at changes in the areas of processes and threads, and in I/O. Future installments will cover memory management, startup and shutdown, reliability and recovery, and security. The scope of this article comprises changes to the Windows Vista kernel only, specifically Ntoskrnl.exe and its closely associated components. Please remember that there are many other significant changes in Windows Vista that fall outside the kernel proper and therefore won't be covered."
From the article: "...the symbolic file link (or as it's called in UNIX, the soft link) finally arrives in Windows Vista." - anybody heard "soft link"? Me (after 10 years of using Linux) never...
Hell with all that...I'm sticking with my Windows 2000! Best M$ OS I've run yet. More stable than 95 or 98 and w/o all the wastefull eye candy of XP. If it does someday become totally obsolete, I guess I'll have to switch to Linux or whatever, but in the meantime it's 2k all the way!
I think we've finally seen the very first actually interesting Slashdot story about Vista. About fucking time.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
How much praise was adorned on Linux when it got an O(1) scheduler? NT has had it for over a decade.
And anybody at said university who looks at said source code for any length of time becomes 'contaminated' and can't contribute to any similar non-Microsoft project ever again.
The article doesn't mention that process startup is now quite different from the other versions of Windows NT.
.exe file mapped into memory. No stack is allocated, and no threads are created. In normal process creation, the parent process actually uses the debugger API calls to allocate memory for the stack into the new process's address space, copies the command line and environment into the new memory, and creates the initial thread pointing at kernel32!BaseProcessStartupThunk. It resumes the thread and off it goes. (NT has no concept of environment or command line at the kernel level.)
In previous versions of NT, process creation was quite different from systems such as UNIX. The system call NtCreateProcess creates a "blank" process with nothing in it but ntdll.dll and the new
This changed in Vista for one reason: DRM. Microsoft made it so that certain processes, namely wmplayer.exe and halo2.exe, cannot be a target of the debugger API calls for obvious reasons. It ignores privilege level in blocking the API. If the old method of starting processes were used, then the parent process could start wmplayer.exe with patches to steal the DRM keys or dump decrypted data to disk. Vista's kernel now does the entire initialization for these processes to close this hole.
By the way, Microsoft needs to change that web page so that it doesn't select Spanish over English if you have Spanish listed as an acceptable language in your browser, even if English is higher in the list. This happens for both IE7 and FF2.
Melissa
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
I disagree. I have not had the dubious pleasure of seeing Windows source code but I have worked with older monolithic closed source kernels such as OpenVMS where at various points I had access. With a good book about the kernel, finding your way around wasn't a major issue. Some items were complex but you could easily extract, for example, material for a course on say lock management, I/O or scheduling.
A prof would want a commercial system to counterpoint something like Linux. However, if I was teaching, I would preder a system with less restrictions (i.e., with an OpenSource license) like Solaris, especially allowing students to easily tweak/replace subsystems.
See my journal, I write things there
Ok, I'm not trying to troll, but the latest CPU scheduling algorithm is just yet another example of how when it comes to Windows, the design is done more by the marketing department than by the engineers. At least we hope the engineers would have raised objections!
I understand their CPU cycle counting is intended to improve fairness between applications, but the proposed scheme will have just the opposite effect. Consider, for example, that interrupts aren't counted against a process' cpu usage. All well and good in theory, but the practical result is that a process which is I/O intensive - that is, one which causes interrupts to occur - will actually run much longer than it would otherwise. So, the problem of one I/O intensive process locking out all of the other applications will only get worse in Vista.
And the interesting thing is that this will actually give a subtle priority boost to multimedia applications, without them having to raise their priority level. IOTW, your multimedia app gets realtime priority whether you asked for it or not.
Well intentioned, yes. But also naive.
The society for a thought-free internet welcomes you.
Click here. He talks about a lot of things, including these "protected processes", and even says that the purpose is for DRM.
Melissa
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager