The 1-5 second pause for the UAC message box is caused by a combination of the UAC dialog being on a separate secure desktop object, and since Aero (which I'm assuming you're using) only supports the default desktop, it has to turn off temporarily to display the dialog. The background is a screenshot of the previous desktop put in the background.
You can turn off the switch to secure desktop for UAC prompts. This way, there is no switch and no pause/flicker. Due to the way that integrity levels work with window objects, you won't really be giving up any security, either.
As for explorer and its excessive confirmations (and the things it won't let you do directly, i.e. copy from network to elevation req. directory) are indeed stupid. Then again, the shell has always been one of Windows's worst integrated components, always fighting the way the rest of the OS operates. I was really hoping they were going to overhaul that for Vista...
Yeah, it's called the fundamental attribution error: people tend to over-attribute behaviors to a person's personality (downplaying the situation) when it comes to strangers, and do the opposite when it comes to themselves or (to a lesser extent) people they know.
That's a good idea, but there would still be problems for the chemicals that are absorbed into the bloodstream but not actually metabolized properly that are expelled as waste through some other means or simply generate waste heat that isn't otherwise useful. I would think that the left handed sugars mentioned earlier fall into this category. It also doesn't take into account different people's different metabolisms. Still, it'd definitely be closer than the current method. It's also sure to be a lot more expensive.
FYI, "feces" is a more polite/formal term for "poop." Personally, the choice of terms doesn't matter to me, as long as it gets the point across as intended (which "poop" does nicely).
When you minimize, Win32 sets the working set of the process is set to its minimum (a few MB). Each of the pages removed is indeed marked as invalid in the page table entries of the process. Physical pages have a reference count: removing the page from the process working set reduces the count by 1. When the reference count reaches 0, the page is moved to the standby list. In the standby list, the page cannot be modified (as it's no longer mapped anywhere). A copy is written to disk lazily, but it still exists in memory as long as it's in standby. That way, if the page needs to go back into a working set, it doesn't have to be read from disk, and if the memory is needed for something else, a copy has already been written to disk. When looking for new memory to allocate, the memory manager uses up the free memory first, and then standby memory. When that runs out, it aggressively trims process working sets.
In short, you're both right. In the 2000/XP task manager, standby memory is counted as both "available" and "system cache" (I guess because it's both available for re-use without disk access, and a type of cache).
Without some method to apply that to what actually eat, that's
all academic and pretty irrelevant.
It's possible for theoretical knowledge to be useless for short term application, but it can always grow into a better understanding that IS useful. It's definitely useful to realize that a certain idea (i.e. all calories are equal) is hopelessly oversimplistic.
People can just make their
own observations and adjustments and just ignore everything you
just said.
People can do whatever they want with themselves. What this thread was about is generalizing to all people, not just what seems to work for an individual. In order to generalize accurately, a rigorous understanding is needed. Models that ignore the complex chemistry and biology involved do not work consistently.
It's relevant when an ingredient is labeled as "sugar" but there's no mention of the handedness ratio, and therefore how digestible it is. Sugars in food very often exist in a mixed form, because that's how plants tend to make them.
Calories in food are measured by burning the food and measuring the heat output. More things burn in the food than can be digested, due to things like handedness.
Food chemistry and how the body processes food are fantastically complicated.
Or at least some kind of format that isn't obfuscated. Make it a real database or something.
The registry is a real hierarchical database. It's even journaled. The registry is divided into "hive" files that are mounted at the third level in the hierarchy (in regedit, see File->Load/Save hive. You can also save or restore the current data in a hive in a separate file.) But like most Microsoft formats, it's proprietary.
Besides NTFS, the other engine MS uses for hierarchical databases is the extensible database engine (formerly Jet blue), used in Active Directory, Exchange and others, also uses a proprietary file format.
Or if that's too hard, why not make regedit part of the Computer Management MMC screen? Or for that matter, allow me to have multiple copies of regedit running. I'm finding myself comparing registry entries between computers a lot but when windows will only let you have one copy running at a time [...]
That'd be nice. Getting rid of the one-max-regedit-instance misfeature would be great too. On Vista, regedit also needlessly requires elevation to run, which is annoying.
While were on the subject of poking in the registry, how about making the registry a file system that is mounted and can be checked for errors?
Well, I did write a filesystem driver for Windows that presents the registry as though it were a mounted disk. It's beta quality, though. It's stable as far as I tested it, but there are fundamental mapping differences and not all apps work with it.
You can't prove one way or another what someone else has perceived.
It is possible to use context (such as conflict of interest), interrogation and corroborating evidence to build or destroy confidence in a witness's statements. But overall, you're right: testimony is not a great basis to build strong beliefs upon.
Our society has condemned men to death on the eyewitness testimony of only a handful of witnesses; yet those who claim contact with God throughout history are innumerable. If our justice system believes eyewitness testimony is good enough for life-and-death decisions, why isn't it good enough for the atheist?
A criminal case (in the US anyways) deals with a very small scope: proof beyond a reasonable doubt that the defendant is indeed guilty of committing the crime and deserves the punishment prescribed by law. For such a scope, the testimony of a (non-accomplice) eyewitness can be enough to support the death penalty (AFAIK, IANAL), although it's hardly ideal.
The question of religion (and interpretation thereof) has a much larger scope. It makes claims not just about a single event in a single place concerning the fate of a single person, but for all events (is there a plan for everything? how strict is it?) all places, all times (long before there were any witnesses, and for historical periods we don't have objective records of), and for all people. The methods in a criminal trial for proving an event and guilt are not sufficient here. For this, we need a theory that can generalize to a much larger scale. Such a theory needs 1. consistent, understandable and comprehensive enough content to be able to make such overarching religious claims and predictions concisely, and 2. a great deal of data to back it up. In collecting data, a testimonial is just an anecdote. No amount of anecdotes can substitute for data.
People have a lot of biases that prevent them from judging things rationally:
People are rationalizing creatures: if they take on a belief, they'd much rather defend that belief than question it seriously, particularly if it's one that they feel defines them, or is comforting, or otherwise makes things easier (properties which I think are involved in a lot of people's religious beliefs). This leads to confirmationbias, which causes them to tend to accentuate the events and interpretations that reinforce those beliefs and discard those that don't. Applied here, once someone becomes religious, their credibility as a witness decreases when it comes to offering their opinion on evaluating their own religion. These things are better evaluated by someone who doesn't have an emotional stake in the matter.
Memes
are ideas that spread from person to person on their own momentum, i.e. without the need to be independently verified. Memes represent a lot of people's beliefs and can result in very strong beliefs, including ones that aren't true. This is a huge confounding factor in trying to extrapolate truth from popular beliefs or beliefs of other people. Beliefs based on other people's beliefs run a big risk in becoming an extension to a baseless meme.
The human brain is not a precise, logical, systematic computer like the one you're reading this post on. The brain is subject to many factors that can cause anomalous behavior. Subconscious states can manifest as artifacts that the conscious mind cannot control, or oftentimes interpret correctly. For example, severe depression can manifest even as hallucinations. In the same way, people who believe deeply enough in something may actually hallucinate in support of their belief.
My point is that in an unstructured collection of people's beliefs can never be good enough to support major religious belief rat
First of all, the issue is how Explorer handles extended attributes (EAs), which are distinct from alternate data streams (ADSes). The kernel and NTFS have always provided full support for EAs and ADSes (since NT 3.1). Explorer (and for that matter Win32) has never had very good support for ADSes, and almost nonexistent support for EAs. EAs were implemented in support of the OS/2 subsystem. ADSes are the 'official' way to attach metadata to a file, and scale better than EAs. The only Win32 functions that have ever provided access to EAs are the BackupRead and BackupWrite functions which are designed to handle all metadata on a file transparently. Looking at the imports from shell32.dll to ntdll.dll on Vista, it looks like the shell bypasses Win32 when dealing with EAs, invoking the syscalls NtQueryEaFile and NtSetEaFile directly (bypassing API layers like this is something Microsoft tells ISVs is a big no-no).
This is just Yet Another Windows 95 shell bug (yes Vista uses the same shell architecture ported through each version from Win95). It is not the end of support for EAs or ADSes. If anything, it's a belated attempt at better support, done poorly. The shell has always been, IMO, one of the lower quality windows components, especially when it comes to properly interfacing with lower layers. This bug does not surprise me. I've been using robocopy for nontrivial file transfer for a while now.
The hard fault spike does indicate swapping. If the pages were simply coming back from the standby cache, they'd be soft faults (with no disk access). Also note that the standby cache is counted as both cache memory and available memory, so some of that 1521MB cache may actually be program memory, trimmed from all process working sets but still in RAM. Unfortunately, the cache memory category is used by a lot of things (even the registry!), and I don't know a good way to get a finer grained break down.
You're right about the OOB experience being important, yet crappy. 2GB should be more than enough for Vista to run well, despite bloat. The biggest reason I'm even running Vista instead of XP or 2003 is that I wanted 4GB of memory, and only Vista supports hibernation with that much.
That does sound like swapping... look at the the resource monitor when one of the apps seems to be getting swapped in and check the hard fault rate: the green line on the rightmost graph. If this is non-trivial, then something is indeed swapping in from the pagefile. In that case, I can only imagine that Windows has decided that the disk cache or the superfetch cache is more important than the standby cache. Something you can try is stopping and disabling the superfetch service.
It's a resource hog. The laptop of my Wife is a Core-2-duo, 2GB ram and decent graphics. Should be more than adequate. Isn't. It's -swapping- as I write this very moment, There's no programs open other than FF which eats 112MB, if we believe Vista, and Thunderbird which eats 87MB. Don't ask me why it's swapping under these circumstances, but it is.
What makes you so sure that it's swapping? Maybe its prefetching (see superfetch, which you can turn off)? Maybe pages are being trimmed into the standby list (where a copy exists both in RAM and disk so that it can go back to work without any disk access)? How much of your page files are actually in use? Is this number increasing? Maybe something else entirely is using the disk?
The performance monitor has counters for these things.
Win32 doesn't support forking, but the NT kernel does. For that matter, by far most of the expense of starting a Win32 process on Windows is due to Win32 subsystem overhead, including compatibility database lookups, not the kernel. SFU processes (that belong to the POSIX subsystem) and native processes (that belong to no subsystem) are MUCH cheaper, and incidentally support true kernel level copy-on-write fork.
Cygwin doesn't use the kernel's fork support because Cygwin is built upon on Win32. SFU can because it runs parallel to Win32.
Yes, I'm aware that the article says that. However, with the article title "Attacking Multicore CPUs" and a summary that makes no mention of UP systems, I wanted to mention the fact that this applied to preemptable kernels, even on UP machines, in the context of the kernel I was talking about. The article and summary seem to imply that this is a new issue: it's not.
What I should have said is that the design of Windows NT isn't vulnerable. The article seems to be implying that this is a new sort of vulnerability, but it's not for NT because its preemptable nature has always required this to be done properly to be secure. No, I haven't personally verified the source code because I don't have access to it. Still, the core kernel team that writes such code has a good reputation for writing secure, correct code. Of all the security vulnerabilities I know of on Windows, only one is due to a syscall not validating its arguments correctly (see the NtCreateAtom bug), and only a few are in the kernel. I'm confident that guideline went into the infamous NT design book and the syscalls were audited for it, being such an obvious trust boundary. Being preemptable, race condition opportunities like this are common in NT, so I would think that the core devs would be aware of and doing this already.
As for programs that intercept syscalls in order to filter them (e.g. on-access virus scanners) this behavior is inherently unsafe, and the kernel takes extra steps to disallow this in AMD64 versions. The chances of third party virus scanner ISVs getting this wrong is much higher than Microsoft's kernel devs.
If that's all it is, Windows NT (and its later incarnations like XP and Vista) aren't vulnerable because kernel components facing user mode are always expected to make copies of user arguments before they're validated and used. Since the NT kernel is preemptable this would be a problem even on single CPU machines because the thread handling the syscall could be interrupted by the scheduler to execute another thread while the first was validating the arguments. Only data that is treated opaquely (e.g. a buffer to write to a file) can be accessed directly safely. This has been known and accounted for since NT was originally designed. Of course, that doesn't rule out the possibility of 3rd party developers not following the rules.
Be prepared for changes to the contents of user-mode memory at any time; another user-mode thread in the same process might change it. Drivers must not use user-mode buffers as temporary storage, or expect the results of double fetches to yield the same results the second time.
There is a group policy setting called "Allow Automatic Updates immediate installation", with this description:
Specifies whether Automatic Updates should automatically install certain updates that neither interrupt Windows services nor restart Windows.
If the status is set to Enabled, Automatic Updates will immediately install these updates once they are downloaded and ready to install.
If the status is set to Disabled, such updates will not be installed immediately.
Note: If the "Configure Automatic Updates" policy is disabled, this policy has no effect.
You can find it in gpedit.msc -> Computer Configuration -> Administrative Templates -> Windows Components -> Windows Update
This applies if you select the auto download but wait to install option (#3 in "Configure Automatic Updates"). Is it possible that this update is one of those?
Haskell allows you to define new binary operators trivially, and set/override the precedence and associativity of operators (/w "fixity" declarations). Haskell assumes that a function name consisting entirely of symbols is meant to be used as an operator. You can even apply a function infix style using backquotes, e.g. "3 `func` 4" (yes, you can define precedence and associativity for those too).
OTOH, Haskell is very different from most languages (in a good way, IMO), being pure functional, lazy and statically typed. It's definitely not a drop-in replacement for C++ or Java.
In NT 3.x, the Win32 video driver model was created from scratch. A video driver consisted of two parts: a video miniport driver that does the actual talking to hardware, resource allocation, etc., running in kernel mode and a display driver that handles all the drawing and display functions, running in user mode with the window server (winsrv.dll) hosted in csrss.exe. In NT4, Microsoft moved the window manager into kernel mode (win32k.sys), which took the display driver with it.
Vista supports two display driver arrangements: XPDDM, the XP display driver model, which is compatible with XP drivers (with the display driver in kernel mode like NT4), and LDDM (Longhorn display driver model) which has moved the display driver back into user mode, hosted in dwm.exe with the new desktop window manager.
There is a private interface for the display driver in user mode to communicate with the miniport driver in kernel mode. This is presumably where the ATI driver flaw is: the miniport apparently has a function to let the display driver read and write to arbitrary memory locations. Note that the caller has to be privileged to even open the miniport device object for communication. The flaw here allows a privileged user to bypass driver signing requirements.
For example, with nVidia's drivers, the XPDDM version has nv4_mini.sys as the miniport, and nv4_disp.dll as the display driver (kernel mode). The LDDM version has nvlddmkm.sys as the miniport and nvd3dumx.dll as the display driver (user mode).
The miniport has always been in kernel mode because it has to talk to the hardware. The display driver has gone from user to kernel and back to user mode. Linux also uses a split kernel mode / user mode driver (in the X server) model.
Hear, hear. I, too am annoyed whenever some feature works only as a special case, and not as a generic part of the underlying engine. I also have dreams of building a game engine that is a comprehensive environment first and a set of particular things second. I have partially designed a pure relational data model to support it, but the code is far from being complete. The description of your game sounds just like what I want in mine.
One reason I think many games rely on small scale features is because it's a lot safer than deep widespread features. Small features with all usage paths known can be exhaustively tested, but deep features either have the potential to be unpredictable or need careful design time planning. In your climbing example, the levels probably have a certain linear progression the player is supposed to follow, and allowing the player to do that at any time might allow him to evade that order in a way the map designers didn't anticipate. The underlying problem is that the game needs to follow such a rigid and fragile structure in order to have its storyline.
Another reason may be related to the choice of programming language in most games: the model of small pieces with limited scope connected by a simplified base, each with a predefined set of behaviors is common to both imperative programming and rigid game design. Those that overcome that effectively build some kind of custom functional or declarative system to run the game on, in my experience (sort of like the adage that any sufficiently large project re-implements LISP, badly). From what I could tell from the article, Spore is no exception. If the designers started with a good functional or declarative language (and program in a higher-order style) it would be a big help. It's much easier to create functions that are known to work under any circumstances without having to check every combination, in higher level languages. I know that historically, such languages were too slow, and it is hard to find programmers for them, so I'm not holding out much hope for the near future. I will, however, put some more work into my project. Hopefully, one of us will have something to release soon.
1) Everyone's been waiting for the perfect language that has all the direct power of C but with none of the deficiencies. Let me know when it becomes existant.
2) NT has always had a logical microkernel design. The WDF framework makes common driver types pretty easy to write.
3) NT already uses a single-root namespace for all named objects, not just files. (Unix still has separate namespaces for different object types.) Filesystems are in fact mounted on (and can be unmounted from) logical volume device objects. Win32 is the one with drive letters; e.g. \DosDevices\C: just a symbolic object link to \Device\HarddiskVolume1
4) This would be interesting, although resources other than files aren't too useful across the network. NT has always tended to use RPC for service interfaces that would be useful across the network.
6) In NT 3.x, winsrv.dll hosted in csrss.exe in user mode handled all the graphical and windowing stuff. They moved a lot of that to win32k.sys in kernel mode because the marshalling between the server and client processes was complex, difficult to do properly and slow.
7) MFC and now.NET were created for that purpose.
8) NT has always used UCS-2 Unicode exclusively internally. The Win32 ASCII functions all convert to Unicode to call the real function. NT uses the UNICODE_STRING structure internally for all strings, which includes buffer size and data size.
9) This is a good idea. Unfortunately, lot of the code is still in C and C++, which were state of the art at the time and don't work well with garbage collection.
10) This is an interesting idea. When NT was written, Erlang was much too new to be making OS components out of. C with traditional locking continues to work pretty well. Still, I'm betting the next gen operating systems will be in a higher programming language than C, although I'm hoping for Haskell.
11) There exist filter drivers that prevent changes from becoming permanent. Otherwise, this is the same as having a strong mirokernel, which requires ISVs to be more competent than usual.
It wouldn't be helpful to switch to a Unixy core: NT already does all the things that you've described that Unixes also do, plus more things. Win32 is the source of ugliness here, and I too would be happy to see it go into compatibility retirement. There was a time when Longhorn was going to do that.
You don't know what you're talking about. The kernel and its functions are re-entrant: a syscall causes the user mode thread to continue execution in kernel mode immediately. The thread usually does all of its own work without the need for secondary threads. However, there are cases where auxiliary threads are needed, via work items serviced by thread pools:
In kernel mode, there are thread pools for general and DPC work items, each with multiple threads, expanded based on the number of CPUs and by load.
User mode services in NT use a RPC style request system with a pool of worker threads on the server side: an application calls into a server process by leaving a message, and one of the server's worker threads executes it and returns a result so the calling thread can continue. CSR, back when it was the graphical server, used to create a thread to parallel every application GUI thread. Now, user programs call into win32k directly, executing in the same context.
Looking through the threads with Process Explorer, I see 18 general system worker threads, 2 filesystem worker threads, 8 RDP worker threads, 2 redbook work threads, 3 usbport work threads, 4 client and 3 server SMB work threads + 7 general remote fs work threads, one for ACPI and one for NDIS (most NDIS work happens in the caller's context). CSR has 8 workers for winsrv and 6 for csrsrv. Winlogon has 4 for system file protection, 6 for RPC requests. LSA has 12 for servicing client requests, 2 for ipsec, and 3 specifically for RPC clients. This is for WS2003 (so there's extra workers, expecting many requests) with one CPU.
Most kernel requests are handled directly by the calling thread. Others use pools of multiple threads: hardly the single threaded system you were describing.
As I said, we *should* be able to pick up an app with its configuration and all our customizations and simply move it around, whether that's within the same OS and FS or to another system entirely. We *should* also be able to do that with UI and GUI customizations to the OS and OS utilities, as well.
I move user profiles, complete with registry hive, around all the time. Microsoft guidelines require programs to store their application config inside of \Software\<company/program>, under HKCU for user config and HKLM for computer config. I copy such application config keys around, with my preferences and such, all the time. I don't find it hard to mount a registry hive as needed-- certainly not any harder than mounting a filesystem to copy config files.
OTOH, just how portable are you expecting configuration to be? Do you expect to be able to copy a the/etc directory from a Solaris 9 installation to RHEL 3 and expect all your settings to transfer without a hitch? OSes have different formats for their settings because they're implemented differently. OSes can't even agree on a standard disk filesystem, let alone configuration format.
In short, the registry is a hierarchical database optimized for large numbers of small entries. A filesystem is a hierarchical database optimized for a smaller number of large entries. Problems with people abusing the registry aren't going to be fixed by moving to a more general hierarchical database with unique sub-formats. If anything, the registry is better because it is more specialized.
Since when does regedit support loading an entire hive, as opposed to a registry patch file (*.reg)?
Since Windows NT 3.1 (in 1993) and Windows 95, i.e. since the registry has seriously existed. Open regedit on 9x and XP+ or regedt32 for NT and 2000. Select either HKEY_LOCAL_MACHINE or HKEY_USERS, the two places hives can be mounted into. For regedit, go to File->Load Hive. In regedt32, goto Registry->Load Hive. When finished, unmount via File/Registry->Unload hive. You can also import or export the contents of a hive into any key: in regedit, select the key to replace, and go to File->Import. In the file type selector, select "registry hive files". Similar procedure for export. In regedt32, go to Registry->Save key for export and Restore key for import.
Slashdot Mirror
The 1-5 second pause for the UAC message box is caused by a combination of the UAC dialog being on a separate secure desktop object, and since Aero (which I'm assuming you're using) only supports the default desktop, it has to turn off temporarily to display the dialog. The background is a screenshot of the previous desktop put in the background.
You can turn off the switch to secure desktop for UAC prompts. This way, there is no switch and no pause/flicker. Due to the way that integrity levels work with window objects, you won't really be giving up any security, either.
As for explorer and its excessive confirmations (and the things it won't let you do directly, i.e. copy from network to elevation req. directory) are indeed stupid. Then again, the shell has always been one of Windows's worst integrated components, always fighting the way the rest of the OS operates. I was really hoping they were going to overhaul that for Vista...
Yeah, it's called the fundamental attribution error: people tend to over-attribute behaviors to a person's personality (downplaying the situation) when it comes to strangers, and do the opposite when it comes to themselves or (to a lesser extent) people they know.
That's a good idea, but there would still be problems for the chemicals that are absorbed into the bloodstream but not actually metabolized properly that are expelled as waste through some other means or simply generate waste heat that isn't otherwise useful. I would think that the left handed sugars mentioned earlier fall into this category. It also doesn't take into account different people's different metabolisms. Still, it'd definitely be closer than the current method. It's also sure to be a lot more expensive.
FYI, "feces" is a more polite/formal term for "poop." Personally, the choice of terms doesn't matter to me, as long as it gets the point across as intended (which "poop" does nicely).
When you minimize, Win32 sets the working set of the process is set to its minimum (a few MB). Each of the pages removed is indeed marked as invalid in the page table entries of the process. Physical pages have a reference count: removing the page from the process working set reduces the count by 1. When the reference count reaches 0, the page is moved to the standby list. In the standby list, the page cannot be modified (as it's no longer mapped anywhere). A copy is written to disk lazily, but it still exists in memory as long as it's in standby. That way, if the page needs to go back into a working set, it doesn't have to be read from disk, and if the memory is needed for something else, a copy has already been written to disk. When looking for new memory to allocate, the memory manager uses up the free memory first, and then standby memory. When that runs out, it aggressively trims process working sets.
In short, you're both right. In the 2000/XP task manager, standby memory is counted as both "available" and "system cache" (I guess because it's both available for re-use without disk access, and a type of cache).
It's relevant when an ingredient is labeled as "sugar" but there's no mention of the handedness ratio, and therefore how digestible it is. Sugars in food very often exist in a mixed form, because that's how plants tend to make them.
Calories in food are measured by burning the food and measuring the heat output. More things burn in the food than can be digested, due to things like handedness.
Food chemistry and how the body processes food are fantastically complicated.
Besides NTFS, the other engine MS uses for hierarchical databases is the extensible database engine (formerly Jet blue), used in Active Directory, Exchange and others, also uses a proprietary file format.That'd be nice. Getting rid of the one-max-regedit-instance misfeature would be great too. On Vista, regedit also needlessly requires elevation to run, which is annoying.Well, I did write a filesystem driver for Windows that presents the registry as though it were a mounted disk. It's beta quality, though. It's stable as far as I tested it, but there are fundamental mapping differences and not all apps work with it.
It is possible to use context (such as conflict of interest), interrogation and corroborating evidence to build or destroy confidence in a witness's statements. But overall, you're right: testimony is not a great basis to build strong beliefs upon.
A criminal case (in the US anyways) deals with a very small scope: proof beyond a reasonable doubt that the defendant is indeed guilty of committing the crime and deserves the punishment prescribed by law. For such a scope, the testimony of a (non-accomplice) eyewitness can be enough to support the death penalty (AFAIK, IANAL), although it's hardly ideal.
The question of religion (and interpretation thereof) has a much larger scope. It makes claims not just about a single event in a single place concerning the fate of a single person, but for all events (is there a plan for everything? how strict is it?) all places, all times (long before there were any witnesses, and for historical periods we don't have objective records of), and for all people. The methods in a criminal trial for proving an event and guilt are not sufficient here. For this, we need a theory that can generalize to a much larger scale. Such a theory needs 1. consistent, understandable and comprehensive enough content to be able to make such overarching religious claims and predictions concisely, and 2. a great deal of data to back it up. In collecting data, a testimonial is just an anecdote. No amount of anecdotes can substitute for data.
People have a lot of biases that prevent them from judging things rationally:
People are rationalizing creatures: if they take on a belief, they'd much rather defend that belief than question it seriously, particularly if it's one that they feel defines them, or is comforting, or otherwise makes things easier (properties which I think are involved in a lot of people's religious beliefs). This leads to confirmation bias, which causes them to tend to accentuate the events and interpretations that reinforce those beliefs and discard those that don't. Applied here, once someone becomes religious, their credibility as a witness decreases when it comes to offering their opinion on evaluating their own religion. These things are better evaluated by someone who doesn't have an emotional stake in the matter.
Memes are ideas that spread from person to person on their own momentum, i.e. without the need to be independently verified. Memes represent a lot of people's beliefs and can result in very strong beliefs, including ones that aren't true. This is a huge confounding factor in trying to extrapolate truth from popular beliefs or beliefs of other people. Beliefs based on other people's beliefs run a big risk in becoming an extension to a baseless meme.
The human brain is not a precise, logical, systematic computer like the one you're reading this post on. The brain is subject to many factors that can cause anomalous behavior. Subconscious states can manifest as artifacts that the conscious mind cannot control, or oftentimes interpret correctly. For example, severe depression can manifest even as hallucinations. In the same way, people who believe deeply enough in something may actually hallucinate in support of their belief.
My point is that in an unstructured collection of people's beliefs can never be good enough to support major religious belief rat
First of all, the issue is how Explorer handles extended attributes (EAs), which are distinct from alternate data streams (ADSes). The kernel and NTFS have always provided full support for EAs and ADSes (since NT 3.1). Explorer (and for that matter Win32) has never had very good support for ADSes, and almost nonexistent support for EAs. EAs were implemented in support of the OS/2 subsystem. ADSes are the 'official' way to attach metadata to a file, and scale better than EAs. The only Win32 functions that have ever provided access to EAs are the BackupRead and BackupWrite functions which are designed to handle all metadata on a file transparently. Looking at the imports from shell32.dll to ntdll.dll on Vista, it looks like the shell bypasses Win32 when dealing with EAs, invoking the syscalls NtQueryEaFile and NtSetEaFile directly (bypassing API layers like this is something Microsoft tells ISVs is a big no-no).
This is just Yet Another Windows 95 shell bug (yes Vista uses the same shell architecture ported through each version from Win95). It is not the end of support for EAs or ADSes. If anything, it's a belated attempt at better support, done poorly. The shell has always been, IMO, one of the lower quality windows components, especially when it comes to properly interfacing with lower layers. This bug does not surprise me. I've been using robocopy for nontrivial file transfer for a while now.
The hard fault spike does indicate swapping. If the pages were simply coming back from the standby cache, they'd be soft faults (with no disk access). Also note that the standby cache is counted as both cache memory and available memory, so some of that 1521MB cache may actually be program memory, trimmed from all process working sets but still in RAM. Unfortunately, the cache memory category is used by a lot of things (even the registry!), and I don't know a good way to get a finer grained break down.
You're right about the OOB experience being important, yet crappy. 2GB should be more than enough for Vista to run well, despite bloat. The biggest reason I'm even running Vista instead of XP or 2003 is that I wanted 4GB of memory, and only Vista supports hibernation with that much.
That does sound like swapping... look at the the resource monitor when one of the apps seems to be getting swapped in and check the hard fault rate: the green line on the rightmost graph. If this is non-trivial, then something is indeed swapping in from the pagefile. In that case, I can only imagine that Windows has decided that the disk cache or the superfetch cache is more important than the standby cache. Something you can try is stopping and disabling the superfetch service.
The performance monitor has counters for these things.
Win32 doesn't support forking, but the NT kernel does. For that matter, by far most of the expense of starting a Win32 process on Windows is due to Win32 subsystem overhead, including compatibility database lookups, not the kernel. SFU processes (that belong to the POSIX subsystem) and native processes (that belong to no subsystem) are MUCH cheaper, and incidentally support true kernel level copy-on-write fork.
Cygwin doesn't use the kernel's fork support because Cygwin is built upon on Win32. SFU can because it runs parallel to Win32.
Yes, I'm aware that the article says that. However, with the article title "Attacking Multicore CPUs" and a summary that makes no mention of UP systems, I wanted to mention the fact that this applied to preemptable kernels, even on UP machines, in the context of the kernel I was talking about. The article and summary seem to imply that this is a new issue: it's not.
What I should have said is that the design of Windows NT isn't vulnerable. The article seems to be implying that this is a new sort of vulnerability, but it's not for NT because its preemptable nature has always required this to be done properly to be secure. No, I haven't personally verified the source code because I don't have access to it. Still, the core kernel team that writes such code has a good reputation for writing secure, correct code. Of all the security vulnerabilities I know of on Windows, only one is due to a syscall not validating its arguments correctly (see the NtCreateAtom bug), and only a few are in the kernel. I'm confident that guideline went into the infamous NT design book and the syscalls were audited for it, being such an obvious trust boundary. Being preemptable, race condition opportunities like this are common in NT, so I would think that the core devs would be aware of and doing this already.
As for programs that intercept syscalls in order to filter them (e.g. on-access virus scanners) this behavior is inherently unsafe, and the kernel takes extra steps to disallow this in AMD64 versions. The chances of third party virus scanner ISVs getting this wrong is much higher than Microsoft's kernel devs.
From Common Driver Reliability Issues: User-Mode Addresses in Kernel-Mode Code
This applies if you select the auto download but wait to install option (#3 in "Configure Automatic Updates"). Is it possible that this update is one of those?
Haskell allows you to define new binary operators trivially, and set/override the precedence and associativity of operators (/w "fixity" declarations). Haskell assumes that a function name consisting entirely of symbols is meant to be used as an operator. You can even apply a function infix style using backquotes, e.g. "3 `func` 4" (yes, you can define precedence and associativity for those too).
OTOH, Haskell is very different from most languages (in a good way, IMO), being pure functional, lazy and statically typed. It's definitely not a drop-in replacement for C++ or Java.
In NT 3.x, the Win32 video driver model was created from scratch. A video driver consisted of two parts: a video miniport driver that does the actual talking to hardware, resource allocation, etc., running in kernel mode and a display driver that handles all the drawing and display functions, running in user mode with the window server (winsrv.dll) hosted in csrss.exe. In NT4, Microsoft moved the window manager into kernel mode (win32k.sys), which took the display driver with it.
Vista supports two display driver arrangements: XPDDM, the XP display driver model, which is compatible with XP drivers (with the display driver in kernel mode like NT4), and LDDM (Longhorn display driver model) which has moved the display driver back into user mode, hosted in dwm.exe with the new desktop window manager.
There is a private interface for the display driver in user mode to communicate with the miniport driver in kernel mode. This is presumably where the ATI driver flaw is: the miniport apparently has a function to let the display driver read and write to arbitrary memory locations. Note that the caller has to be privileged to even open the miniport device object for communication. The flaw here allows a privileged user to bypass driver signing requirements.
For example, with nVidia's drivers, the XPDDM version has nv4_mini.sys as the miniport, and nv4_disp.dll as the display driver (kernel mode). The LDDM version has nvlddmkm.sys as the miniport and nvd3dumx.dll as the display driver (user mode).
The miniport has always been in kernel mode because it has to talk to the hardware. The display driver has gone from user to kernel and back to user mode.
Linux also uses a split kernel mode / user mode driver (in the X server) model.
Hear, hear. I, too am annoyed whenever some feature works only as a special case, and not as a generic part of the underlying engine. I also have dreams of building a game engine that is a comprehensive environment first and a set of particular things second. I have partially designed a pure relational data model to support it, but the code is far from being complete. The description of your game sounds just like what I want in mine.
One reason I think many games rely on small scale features is because it's a lot safer than deep widespread features. Small features with all usage paths known can be exhaustively tested, but deep features either have the potential to be unpredictable or need careful design time planning. In your climbing example, the levels probably have a certain linear progression the player is supposed to follow, and allowing the player to do that at any time might allow him to evade that order in a way the map designers didn't anticipate. The underlying problem is that the game needs to follow such a rigid and fragile structure in order to have its storyline.
Another reason may be related to the choice of programming language in most games: the model of small pieces with limited scope connected by a simplified base, each with a predefined set of behaviors is common to both imperative programming and rigid game design. Those that overcome that effectively build some kind of custom functional or declarative system to run the game on, in my experience (sort of like the adage that any sufficiently large project re-implements LISP, badly). From what I could tell from the article, Spore is no exception. If the designers started with a good functional or declarative language (and program in a higher-order style) it would be a big help. It's much easier to create functions that are known to work under any circumstances without having to check every combination, in higher level languages. I know that historically, such languages were too slow, and it is hard to find programmers for them, so I'm not holding out much hope for the near future. I will, however, put some more work into my project. Hopefully, one of us will have something to release soon.
1) Everyone's been waiting for the perfect language that has all the direct power of C but with none of the deficiencies. Let me know when it becomes existant.
.NET were created for that purpose.
2) NT has always had a logical microkernel design. The WDF framework makes common driver types pretty easy to write.
3) NT already uses a single-root namespace for all named objects, not just files. (Unix still has separate namespaces for different object types.) Filesystems are in fact mounted on (and can be unmounted from) logical volume device objects. Win32 is the one with drive letters; e.g. \DosDevices\C: just a symbolic object link to \Device\HarddiskVolume1
4) This would be interesting, although resources other than files aren't too useful across the network. NT has always tended to use RPC for service interfaces that would be useful across the network.
5) Well, Microsoft does have an object oriented LDAP database system now...
6) In NT 3.x, winsrv.dll hosted in csrss.exe in user mode handled all the graphical and windowing stuff. They moved a lot of that to win32k.sys in kernel mode because the marshalling between the server and client processes was complex, difficult to do properly and slow.
7) MFC and now
8) NT has always used UCS-2 Unicode exclusively internally. The Win32 ASCII functions all convert to Unicode to call the real function. NT uses the UNICODE_STRING structure internally for all strings, which includes buffer size and data size.
9) This is a good idea. Unfortunately, lot of the code is still in C and C++, which were state of the art at the time and don't work well with garbage collection.
10) This is an interesting idea. When NT was written, Erlang was much too new to be making OS components out of. C with traditional locking continues to work pretty well. Still, I'm betting the next gen operating systems will be in a higher programming language than C, although I'm hoping for Haskell.
11) There exist filter drivers that prevent changes from becoming permanent. Otherwise, this is the same as having a strong mirokernel, which requires ISVs to be more competent than usual.
It wouldn't be helpful to switch to a Unixy core: NT already does all the things that you've described that Unixes also do, plus more things. Win32 is the source of ugliness here, and I too would be happy to see it go into compatibility retirement. There was a time when Longhorn was going to do that.
You don't know what you're talking about. The kernel and its functions are re-entrant: a syscall causes the user mode thread to continue execution in kernel mode immediately. The thread usually does all of its own work without the need for secondary threads. However, there are cases where auxiliary threads are needed, via work items serviced by thread pools:
In kernel mode, there are thread pools for general and DPC work items, each with multiple threads, expanded based on the number of CPUs and by load.
User mode services in NT use a RPC style request system with a pool of worker threads on the server side: an application calls into a server process by leaving a message, and one of the server's worker threads executes it and returns a result so the calling thread can continue. CSR, back when it was the graphical server, used to create a thread to parallel every application GUI thread. Now, user programs call into win32k directly, executing in the same context.
Looking through the threads with Process Explorer, I see 18 general system worker threads, 2 filesystem worker threads, 8 RDP worker threads, 2 redbook work threads, 3 usbport work threads, 4 client and 3 server SMB work threads + 7 general remote fs work threads, one for ACPI and one for NDIS (most NDIS work happens in the caller's context). CSR has 8 workers for winsrv and 6 for csrsrv. Winlogon has 4 for system file protection, 6 for RPC requests. LSA has 12 for servicing client requests, 2 for ipsec, and 3 specifically for RPC clients. This is for WS2003 (so there's extra workers, expecting many requests) with one CPU.
Most kernel requests are handled directly by the calling thread. Others use pools of multiple threads: hardly the single threaded system you were describing.
OTOH, just how portable are you expecting configuration to be? Do you expect to be able to copy a the
In short, the registry is a hierarchical database optimized for large numbers of small entries. A filesystem is a hierarchical database optimized for a smaller number of large entries. Problems with people abusing the registry aren't going to be fixed by moving to a more general hierarchical database with unique sub-formats. If anything, the registry is better because it is more specialized.
Orca.exe is the tool for creating/editing .MSI packages. It can be used to extract package contents.
MSI packages are databases that store more than files. More about the MSI file format.