Inside the Windows Vista Kernel 298
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."
Finally... (Score:4, Insightful)
Re:Soft links? (Score:3, Insightful)
The usage is established, but "symlink" or "symbolic link" are far more common:
Wikipedia: Wikipedia article [wikipedia.org] (redirects to "Symbolic link" article)
Google hits: ~1M hits for ("symbolic link" OR "symlink") unix [google.com] vs. ~419K hits for ("soft link" OR "softlink") unix [google.com] ("unix" appended to avoid potentially irrelevant matches)
Ocurrences in manpages (my Gentoo Linux system):
$ find /usr/share/man -type f -name '*.gz' | xargs zcat | grep -i "soft link" | wc -l /usr/share/man -type f -name '*.gz' | xargs zcat | grep -i "softlink" | wc -l /usr/share/man -type f -name '*.gz' | xargs zcat | grep -i "symlink" | wc -l /usr/share/man -type f -name '*.gz' | xargs zcat | grep -i "symbolic link" | wc -l
27
$ find
1
$ find
380
$ find
1458
(Yes, it might not be that elegant, but my shell scripting skills are not the best.)
Re:MMCSS (Score:5, Insightful)
Yes, as it should. If the AV activity is a scheduled full system scan, then it can indeed wait those few tenths of seconds extra, as if you're already infected, they won't make any difference. If it's a real time scan on a file you're accessing, then it can definitely wait, as the file won't be opened/executed until the scan has completed anyway.
So what exactly is the problem with giving a multimedia app a higher priority on the processor than your AV software? We're not talking about killing the AV soft, just lowering the priority; it's still running.
they've merely reimplemented nice
You've been able to set process priority through the Task Manager since at least NT4 (the earliest I remember it being available; it may have been in earlier versions too, I just don't remember seeing it personally).
Re:MMCSS (Score:1, Insightful)
OS classes will always be open OS based (Score:5, Insightful)
For this reason, OS classes in school will be based on Linux,BSD,Minux,or even ReactOS. With all of these, if want to really know how it works, there is the code.
The secret-software-business is quite different that the shared discoveries of the scientific method that works well in education and science.
Historically, the open ones will be the only ones that survive. In 50 years: You want to know how DOS worked in the 1980s? Well, no source is available. But freedos provides a good example of how it worked. You want to know how some random UNIX worked. Well the source to that specific one is not available, but BSD and Linux are a good examples of how it worked. You want to know how Windows-2000 worked? Well, no source code is available, but ReactOS provides a close approximation of how it worked.
Re:MMCSS (Score:5, Insightful)
Re:MMCSS (Score:5, Insightful)
There are basically two options here:
1. Antivirus hooks into the OS, and scans every program BEFORE it gets executed. In that case, the scanner's priority doesn't matter, it gets run before the program starts anyway.
2. You run the antivirus scanning every file on disk, as a normal process. This would be what the priority adjustments affect, but doing things this way you can't really detect a new virus in real time. You can just find it during the scan, and the priority only determines how fast it will proceed when something else wants CPU time.
Re:OS classes will always be open OS based (Score:5, Insightful)
Although you're right about closed software, computer science as a whole is actually much more open in many respects than some other scientific fields. In particular, the medical and biological science fields are quite closed-off. Even physics is somewhat closed-off, not by design, but because the equipment required to perform experiments is so expensive.
Few computer science experiments take more than a couple thousand in capital investment. Also, if you have questions, you can often discuss your experiments, ideas, data, findings, etc. with an expert (or even industry leader) simply by signing up to a mailing list or going on IRC.
Re:MMCSS (Score:5, Insightful)
Unfortunately many programmers seem to misunderstand this. Usually you can give user-interface processes very high priority, even if they are far less important than some of the background processes. Very often user-interface processes consume only limited amounts of processor cycles. When this happens, no matter how high their priority, they will leave plenty of cycles for the other processes.
It doesn't matter if a virus-scanning process gets delayed a few additional seconds, because there's no person waiting for it and getting impatient. It does matter if a web browser or text editor gets delayed, because there is a human waiting for them.
Re:MMCSS (Score:5, Insightful)
The general sequence of events is:
1 user double-clicks a file
2 the AV soft's real-time scanner is invoked to scan it
3a the file is clean, access is granted
3b the file is dirty, access is denied
It doesn't matter how long step 2 takes, or what other apps get to use cycles while it's suspended - it will complete before either of steps 3a or 3b.
Making Symlinks in GUI? (Score:4, Insightful)
Correct me if I'm wrong, but don't people criticize Linux all the time of a lack of GUI utilities in comparison to Windows? Yet when I drag a file somewhere in KDE, I can just click on "Link Here" and poof, I've got a symlink. Why have I not heard a single complaint about the lack of a user-friendly way to do this in Vista?
Furthermore, you need to have Administrator access (or use Administrator to give yourself the priviledge) to create a symlink, "because not all applications may handle symbolic links correctly". Doesn't this seem broken to anyone? Or at the very least, worrysome?
If it ain't broken... (Score:1, Insightful)
Re:OS classes will always be open OS based (Score:3, Insightful)
Whereas professors are born knowing Linux, or magical documentation fairies just wave their little wands and give the professor knowledge about the subject.
This might be a wild guess, but a professor teaching OS architecture might already know a thing or two about the OS architecture of the OS implemented by the source he's looking at.
But it IS broken (Score:2, Insightful)
It's the fact that the backwards compatibility is still there. C:\PROGRA~1 etc is fucking ugly and confusing for the new user. They stole long file names from other OSs but implemented it poorly. They need to take the same route as OSX. Start from scratch (sort of) and forget backwards compatibility for once. Allow good implementation of a virtual machine for that sort of crap. You can't get rid of the burdens from your old OS if you allow backwards compatibilty. 8.3 filenames are just one of the burdens.
Re:OS classes will always be open OS based (Score:2, Insightful)
Re:Finally... (Score:3, Insightful)
The longer operating systems are around for, the more heterogenuous they will become. Although Linux/UNIX might have a bunch of features that Microsoft is getting around to implementing, similar arguments can be made in the other direction as well. The fact of the matter is that computer users as a whole will demand certain things from their operating system and the vendors will eventually get around to implementing those things. I think that on a long enough time line, eventually every OS will have appropriated all of the worthwhile features from every other OS.
Re:Finally... (Score:3, Insightful)
Re:Finally... (Score:3, Insightful)
Everytime I read anything about Vista's new features, I hear myself saying "fucking finally" like half a dozen times.
Funny, I think exactly the same thing almost every time I hear about the latest "innovation" in Linux or OS X.
Re:Process startup changed significantly (Score:2, Insightful)
The real reasons actually go like this.
1) Security
2) Performance
3) Reliability
I like your DRM theory, but you could also go for the Vista has added a new audio stack for DRM, or a new video subsystem for DRM, or new caching technology for DRM. When in fact, NONE of them have ANY DRM relations WHAT SO EVER, just like the Process startup changes.
You sound reasonable, but you are trolling based on something you know just enough about to maybe get away with your con...
Re:But it IS broken (Score:3, Insightful)
Would you upgrade to a new version of Windows if it meant you having to repurchase or reinstall *all* your existing software? Consumers want the software they purchased to continue working on their computers once they've upgraded something, be it hardware, software, or the OS.
It's an OS *upgrade*. That means it takes what it already had and adds to it. It is not a *new operating system*. This is why backwards compatibility is important.
Also, you keep on talking about this "16-bit API" as if you know much about it. The functions still exist with their 16bit names, but apart from the ones that specifically remain 16bit due to their very nature, all of the "legacy 16bit api" is either fully 32bit or just maps as an alias to the 32bit equivalent. Which part of the "16bit API" offends you so much? Just because the OS provides backwards compatibility with 16bit programs doesnt mean that your system is suffering in any way due to the presence of that compatibility. The 16bit subsystem only kicks in when you launch a 16bit process. If a 16bit application works 100% without modification, why should the application developers rewrite it just to make you happy?