Originally posted by: kylef
Originally posted by: VirtualLarry
HT is enabled and works in W2K, but the OS doesn't know that those two CPUs share cache resources, etc., so it's not optimized for HT. But it will work.
Which is why it's not true support. In fact, using HT in Win2k actually degrades single-thread performance under most cases: overall throughput in this case is generally better only if multiple threads are in the ready queue more than a certain percentage of time. Below that, overal performance degrades too. In general, HT on Win2k is a losing proposition. (The Win2k situation is much worse on a Dual Xeon system...)
I'm going to be stubborn here, and ask what exactly 'true support' means. HT is a processor feature. W2K supports it, in as much as it properly recognizes and schedules for two virtual CPUs. I'll admit, that XP has slightly optimized this in order to recognize HT explicitly, and to use processor affinity in the scheduler as to avoid cache-thrashing as much as possible.
But the actual operation of HT, and the possible performance degradation that occurs, depends on the two threads scheduled, and the processor itself, not in any way the OS. The problem is the L2 cache and write/write-combine buffer contention on the CPU itself. XP can't magically elide those issues. Therefore, it's my assertion that W2K supports HT just fine. MS's line on requiring XP for HT is marketing FUD designed to push people to upgrade to XP. The only real issue is software licensing, and that has nothing to do with CPU execution efficiency.
Originally posted by: kylef
Sorry, I meant to say live *detachment*. Which is very important when debugging server processes of any kind. You can detach and let the app continue as though it had never been debugged.
You're right, I do remember reading something about that now.
Originally posted by: kylef
And BTW, VC6 has problems of its own (but those are a topic for another thread).
Oh,
trust me, I could tell you some stories too..
Originally posted by: kylef
Worse, I don't think that this can be optionally disabled, correct? I never enable that option when compiling code, it does result in some pretty spectacular bottlenecks in the inner loops.
This can absolutely not be disabled. From a technical standpoint, that would mean distributing two copies of every system binary, which is not feasible.
That's what I suspected, thanks for clarifying.
Originally posted by: kylef
And the /GS flag should incur no "bottlenecks in the inner loops"... the perf hit is in the compiler's generated code for function prologs and exits (using a hash to verify return addresses before blindly jumping to them). In other words, function calls/returns incur the overhead. The interior of functions incur no performance overhead from /GS whatsoever.
Ok, I should have left out the word "inner" there. But in my experience, "/GS" does cause a notable slowdown.
Originally posted by: kylefShell support for these items you have mentioned is not exploitable. And honestly, most people LOVE these particular extensions because you don't have to go install more software just to open a zip file, or view the photos from your digital camera.
You mean, not any more, right? Because there were exploits for some of those features at one point, and if MS's patching of IE can be made an example, it certainly won't be the last.
As for the features, maybe I wouldn't mind them so much, if they were made an
optional install item, kind of like some of the features from the Win98 "Plus" pack, like drive compression, and I think, Zip folder support back then too.
Originally posted by: kylefBut Shell support for random application plug-ins IS highly buggy and exploitable. This problem has existed on every Windows release since Win98 (it's less exploitable in XPSP2 but just as buggy). Shell plug-ins cause all kinds of problems. Have you ever had Explorer.exe crash on you? The chances are good that the culprit was a poorly-written 3rd-party plug-in Dll that caused explorer.exe to crash.
Hate to tell you, but the bundled ones in XP are nearly just as bad, especially when dealing with malformed data formats.
Originally posted by: kylefDivX installs shell extensions, for instance, and has caused my explorer.exe to hang when hovering over .avi files with the mouse (or right-clicking), or worse to fail to delete files because the plug-in is leaving file handles open. I cannot over-emphasize how evil these plug-ins truly are. Whenever I install an application, the first thing I look for are any Shell extensions that I can remove.
Again, hate to tell you, but WinXP's Explorer can do that even without DivX installed, and Explorer.exe has an open-file-handle leak itself, without any dodgy shell extensions loaded. (Yes, even in W2K SP2.)
Originally posted by: kylef
An end-user shouldn't have to go to those extremes, just to configure *their* computing environment in the way that they feel most comfortable about it.
Agreed, absolutely. Luckily Microsoft agrees too and is working on componentizing Windows so that minimal installs are truly possible. With a code base as large as Windows is now, it's a serious engineering feat. The component dependency graphs are amazingly complicated.
That's not a valid excuse here, unfortunately. Most of those user-mode components are already segregated in the installer .INFs. The simple fact is that MS doesn't give the user the choice, that's all. MS wants to make the choice for them, to force as much of their "crapware" onto the user as possible.
As for the compontization of system-level stuff, MS has been selling "Windows Embedded" based on the XP source code base for some time now. It's already componentized. So even if that were the reason for the above, that reason wouldn't be valid any longer.