The arms race between programs and users

Date:February 16, 2004 / year-entry #64
Orig Link:
Comments:    69
Summary:There is a constant struggle between people who write programs and the people who actually use them. For example, you often see questions like, "How do I make my program so the user can't kill it?" Now, imagine if there were a way to do this. Ask yourself, "What would the world be like if...

There is a constant struggle between people who write programs and the people who actually use them. For example, you often see questions like, "How do I make my program so the user can't kill it?"

Now, imagine if there were a way to do this. Ask yourself, "What would the world be like if this were possible?"

Well, then there would be some program, say, xyz.exe, that is unkillable. Now suppose you're the user. There's this program xyz.exe that has gone haywire, so you want to exit it. But it won't let you exit. So you try to kill it, but you can't kill it either.

This is just one of several arms races that you can imagine.

  • "I don't want anybody to kill my process." vs. "How do I kill this runaway process?"
  • "I want to shove this critical dialog in the user's face." vs. "How do I stop programs from stealing focus?"
  • "I don't want anybody to delete this file." vs. "How do I delete this file that refuses to be deleted?"
  • "How do I prevent this program from showing up in Task Manager?" vs. "How can I see all the programs that are running on my computer?"

Eventually you have to decide which side wins, and Windows has decided to keep users in control of their own programs and data, and keep administrators in control of their own computer. So users can kill any process they want (given sufficient privileges), they can stop any program from stealing focus, and they can delete any file they want (again, given sufficient privileges).

Programs can try to make themselves more difficult to kill (deny PROCESS_TERMINATE access, deny PROCESS_CREATE_THREAD access so people can't CreateRemoteThread(EndProcess), deny PROCESS_VM_WRITE so people can't scribble into your stack and make you doublefault, deny PROCESS_SUSPEND_RESUME so they can't suspend you), but eventually you just can't stop them from, say, elevating to Debug privilege, debugging your process, and moving EIP to "ExitProcess".

Notice that you can kill CSRSS.EXE and WINLOGON.EXE if you like. Your computer will get very angry at you, but you can do it. (Save you work first!)

Another useful question to ask yourself: "What's to prevent a virus from doing the same thing?" If there were a way to do these things, then a virus could take advantage of them and make itself invisible to Task Manager, undeletable, and unkillable. Clearly you don't want that, do you?

Comments (69)
  1. Darrell says:

    Of course not. The developers that need their program to be "unkillable" just so that it works are probably not very good anyway.

  2. Mike says:

    Speaking of administrators and "their" machine: I can’t prevent domain policy from doing all kinds of crap on my machine even though I’m local administrator! If I log on as a domain user (with local administrator rights!), I get policy wallpaper and can’t change it!

  3. Raymond Chen says:

    Oksy so there’s a third rule, namely to "keep domain administrators in charge of the computers on their domain". If you’re the domain administrator of a 10,000-computer network, you conceptually "own" all those machines and can set policy on them. If you (the local administrator) don’t like it, then you shouldn’t have joined the domain.

  4. denny says:


    I have seen a few ? on GDN.COM from folks asking how to "Hide" from TaskMan …

    I always ask some of the stuff you posted here… always makes me wonder what they are upto?

    a new way to trojan a client perhaps?

    a new spyware writer perhaps?

    just makes me wonder "why"

  5. Mo says:

    To be completely fair to Windows, this is one aspect which has improved massively between NT 3.1 and XP. Pre-XP, there was this sort of mantra that you had to chant to remind yourself that the only thing in charge of your computer was Windows. Granted, that wasn’t *strictly* true, but it wasn’t until relatively recently that you didn’t have to jump through hoops to do stuff that a typical "power user" wants to do. Nowadays, most things work how you (especially as a UNIX user) would expect.

    Of course, there’s another school of thought which says "the creator of the document has final say over what you can do", but that’s a whole other debate, probably.

  6. I really don’t like the bits of Windows that try to stop applications stealing focus. First of all, some applications have a legitimate reason to take focus (as you say, for critical notifications and the like) and the changes make it harder for those applications. But it also means that applications that do try and take focus now cause the task bar to highlight the application instead of giving it focus. So instead of getting an application appear when I need it, I get the task bar not auto-hiding and an annoying flashing Window which covers the status bar in maximized applications (I have seen this happen with MSDN a few times where I press F1, read the documentation and then need to activate MSDN to see the status bar in another application).

    I treat applications that make poor use of focus like applications with any other kind of poor UI – if they are broken, I uninstall them.

    After writing all of this, I have just found the option in TweakUI to disable this behavior. I wish I had found it earlier! I still wonder if this could have been the default.

  7. Stephane Rodriguez says:

    Ahh! the goodness of winsta0…

  8. Raymond Chen says:

    Jonathan: The problem with focus-stealing UI is that they can end up capturing input not intended for it. Consider, you’re typing away, about to type the word "maybe", and while you are doing it, a focus-stealing dialog pops up that says "Do you want to…" and your Enter goes to that dialog. Whatever it was, you just confirmed it because the "y" in "maybe" means "Yes".

  9. Good point! I should have thought of that – I did wonder if the feature was to stop some kind of UI spoofing (for example, an application popping up a dialog box mimicking another app’s UI to get information from a user, eg the proxy server password dialog in IE. Perhaps the thing that annoys me isn’t that Windows stops applications taking focus but that it keeps the task bar visible and on top of other applications when I would prefer it not to be in my way (I realize that for some people, the current behavior is probably very useful).

  10. quanta says:

    Right on. I’m tired of programs that are the virtual equivalents of sweatshops locking their fire exits. I want a way out if things go wrong, and things will go wrong.

    The Logitech Quickcam software is especially thorny in this regard. When it crashes (which is far too often) it hangs the XP UI and refuses to terminate, forcing you to do a hard reset.

  11. Ziktar says:

    Except thanks to Windows File Protection, the system thinks it knows more than me…

    "You really didn’t mean to delete Outlook Express, did you? Nah, no chance of that, so I’ll go ahead and replace it for you."

    Or worse, that silly %Program Files%Xerox folder that’s empty and yet you cannot remove on XP. What’s with that?

    (My main beef is that I agree with you completely Raymond, and WFP takes away my control with no real/semi-convenient option of turning it off.)

  12. Raymond,

    I know you guys try to prevent applications from stealing focus, but it still happens on Windows XP.

    For example, try using dial-up networking to dial a busy number. The notification that says that a number is busy will show up on top and steal the focus.


  13. Raymond Chen says:

    Dejan: I concede that the blockout is not perfect. That’s something for the USER folks to investigate.

    Ziktar: You can disable WFP but you need a kernel debugger. The purpose of WFP is to prevent programs from corrupting system files. This was a horrific problem in Windows 3.1 and Windows 95. You’d install program X and it would replace Windows 95’s COMMDLG.DLL with Windows 3.1’s COMMDLG.DLL…

  14. Jack Mathews says:

    Yeah, I’d have to agree that WFP is necessary, and has probably fixed countless installations and stopped ISV’s from installing their own DLLs in favor of side by side DLL’s.

    I’m liking using the tasktray help bubbles to convey information that would have normally been a box with an OK button. That and MSN style notifications are getting popular. esp. the trillian style of doing them.

    Raymond, any consideration of adding those notification boxes as a common control?

  15. Raymond Chen says:

    The bubbles are already a common control – TTS_BALLOON. Dunno what you mean by the MSN/Trillian notifications; I don’t use either of those programs. I’m guessing you mean the little boxes that pop up in the corner of the screen. Not sure what a common control for that would be like since everybody puts different info in it. Just create a window, show it, then hide it.

  16. Scott says:

    Anyone who’s done any VB development and has installed a third-party app they found has experienced the horror of watching COMDLG32.DLL come flying across the progress bar and wondered "Will my app still complie?". If WFP helps to prevent that feeling, I’m all for it.

    As a developer and a user, my #1 rule is "let the user kill anything they want to, consequences be damned.". Certain processes might be flagged as important enough to warn the users about the consequences. But if I confirm that I want to kill ANY process I should be allowed to (domain security exceptions excluded of course).

  17. Tim Robinson says:

    Killing CSRSS.EXE is a fun way to generate a deliberate blue screen. Google for "NT backspace bug" for how (this may just apply to NT 4, and I’m not about to try it on Windows 2000…).

  18. Anonymous Coward says:

    Nobody has mentioned the future of the user’s control of his own PC under Trusted Windows if and when the new processors and software for them deploy…

  19. Jack Mathews says:


    I know the bubbles are a common control, that’s why I said I like using them :)

    The common control for the notification boxes would really be a couple of things…

    1) Where do they appear? Do they hug the taskbar? Do they appear on the primary monitor only or the secondary monitor when the taskbar is over there? Different programs implement this differently

    2) How do they appear? Some slide them up, some fade them up. Outlook 2k3 and MSN are even inconsistent in this way.

    3) How do you manage overlap? With the bubbles, two can’t appear at once, and they are queued internally. With these things, two programs could bring up two of them at once. The way Trillian manages this internally is really clever. They stack them, and when one is going away, others on top of it fall. You should really check it out in action.

    It just seems like a more and more popular way to convey information to an end user, even internally within Microsoft, and seems like it could use a little attention. I mean, the same "just make a window" argument could be said for Tooltips, and I’m sure glad that became a common control :)

  20. Reuben Harris says:

    There is at least one trivial way to run a program invisible to taskmgr.exe… have your .exe unpack a small dll which contains a systemwide hook which interferes with the LVM_* messages of a certain listview in a certain app…

    Of course you’d need to do the same for other popular GUI task enumerating apps (e.g. Process Explorer), but it’s not exactly hard to do.

    Raymond: I don’t *think* you’ve covered this, but apologies if you have… how about doing a piece explaining NT’s system service processes csrss.exe, lsass.exe and friends? I’ve never been clear on *exactly* what they do. IIRC pre- NT4 there used to be gdi.exe which handled all GDI calls, so every time your app did anything with GDI it cost you two context switches. Why was that ever considered a good idea??

  21. Anonymous Coward says:

    Focus-stealing is ESPECIALLY bad when you’re, ahem, talking intimately with your significant other, and your mother sends you an IM through AIM (popping up a window), and you wind up saying something to her that you REALLY regret.

  22. Raymond Chen says:

    Reuben: I’m going to pass on the variosu *ss.exe’s because I don’t know for sure either myself…

  23. Jerry Pisk says:

    Raymond, WFP is a poot patch for users not using the proper user rights. If you’re installing a program you should not have enough rights to over-write anything that belongs to the system itself. WFP is just a work-around, not a fix to the problem. It just covers up the shoddy security track Microsoft has, I mean, whoever thought about users running as Administrators by default.

  24. The biggest gripe with applications I’ve currently is the focus stealing. Starting Photoshop will cause three focus steals, starting Outlook2003 at least two. And I frankly dont want to wait until they’re fully loaded, yet the stealing annoys the hell outta me.

    I already suggested via Product Wish an advanced global option to disable all focus stealing. I wonder if that one will ever be implemented.

  25. Mike Dunn says:

    Jack Mathews: There’s a shell interface for showing your own tray icon with a bubble tooltip: IUserNotification. See

  26. Raymond Chen says:

    Be careful what you ask for, Mario. If focus stealing were globally disabled, then double-clicking a text document would open Notepad without focus. Typing a URL into the Run dialog would run your web browser without focus. Is that really what you want?

  27. Petr Prazak says:

    Reuben, get the book "Inside Windows 2000" by Solomon&Russinovich, read it, and you’ll know about it more than you ever wanted to. :))

  28. Jack Mathews says:

    Mike Dunn: I know about bubbles, that’s not what I’m talking about. I mean notifications such as these:

  29. Raymond Chen says:

    The deal with those is that a common control isn’t very useful. Every app wants their notification to look "cool" in an app-specific way, so no "common" control would work. Some people want a bitmap at coordinates (x,y); other people want a background bitmap z, some people want markup… it’s all so heavily customized that there isn’t much left for the system to provide aside from ShowWindow.

  30. RichB says:

    I could kill csrss on Win2K with kill.exe from the ResKit – but on XP and 2K3 taskkill won’t let me. What gives? I WANT MY BSOD.

  31. Raymond Chen says:

    There’s a special check in taskkill.exe to not kill csrss, etc. If you want to kill them, you’ll have to write your own kill program that doesn’t check for "special" program names.

  32. Andreas Häber says:


    A big change between NT3.51 and NT4.0 was that a part of the Win32 subsystem, which is a usermode process, was moved to the kernel area. As you said, that part is the GDI. I’ve read some articles about it at One article covering this change is: "Moving Window Manager and GDI into the Windows NT 4.0 Executive" (

    For a more abstract background to the Windows NT architecture you can read "The Foundations of Microsoft Windows NT System Architecture" (

    And of course, get the book mentioned by Petr above. If you don’t want to buy a book then Mark Russinovich has a lot of good articles about the internals of Windows NT, which you can find at There’s also a lot of very nice utilities on that site ;)

    What’s missing is a discussion about the internals of explorer.exe ;-) One question.. will it host the CLR in the next version, so shell extensions can be easier created using .NET? (I’m sorry for asking about the new thing here :))

  33. Jack Mathews says:

    Raymond: I suppose rather than a common control, it would be a shell interface then. Maybe even so much as a SHAddDesktopAlert which the shell would slide up or fade in, and then SHRemoveDesktopAlert which would fade it out and move the others down. Then even Microsoft programs such as Outlook and MSN could share the same API but have their different cool looks.

    I can tell you’re not too hot on the idea or anything, but it seems to be becoming more and more of an issue.

  34. Raymond Chen says:

    There’s a whole new desktop alert mechanism in the Longhorn sidebar.

  35. Tony Cox says:

    This kind of thing seems to be an obsession with some games developers. In particular, there’s a huge number of them want to know how to "disable Ctrl+Alt+Del" and/or task switching in general.

    I think when I did DirectX dev rel, I ended up answering that question about once per week. Part of it stemmed from the fact that handling task switching involved some effort on the part of the game developer with earlier DirectX versions (you could have textures and other graphics objects yanked from you on a switch away from full-screen mode), but also to some extent because some video drivers were just pretty buggy in those situations. Didn’t make it a good idea to try, of course.

  36. Jack Mathews says:

    Well Tony, actually as a former PC game dev (now console), I can tell you exactly why we wanted to disable keys to task switch.

    Because, particularly in first person shooters, you can rebind any keys to do actions. And since people use the mouse with their right hand and keybaord with their left hand, Alt and Tab are common keys to bind. Or even if they’re not bound, they’re easy to hit on accident. Hit them together and bam, there goes the game.

    Same with the Windows key.

    THAT is why game developers want to disable those godforsaken key combinations. Because for normal application use, hitting Alt-tab is kind of hard, and hitting the Windows key doesn’t stop what you’re doing… In an online game it can win or lose you a match.

    That’s why lots of hard core first person shooter players pry their Windows keys off their keyboards, and why it was SO frustrating that Microsoft never gave straight or elusive answers to game devs on the subject for so long.

  37. n4cer says:

    Jack, you can find more info on Longhorn’s notifications API here:

    Notifications for Windows "Longhorn"

    CLI325 – WinFS: Overview of Information Agent and Notifications (MS Producer presentation of session from PDC 2003)

    LH SDK: Notifications Tutorials and Tasks

  38. Tony Cox says:

    Actually, I was and am a game developer myself, both before and after the DirectX dev rel job.

    The accidental key-thing I can buy, especially for the Windows key, and it’s possible to do what you want except for Ctrl-Alt-Del which is the Secure Attention Sequence.

    The task switching thing is really just laziness, though. I had plenty of developers tell me flat out that the reason they wanted to do it was because they had all sorts of problems with their lost surface handling code. Sometimes I could convince them to let me help them fix it.

  39. Tony Cox says:

    I also think that when you say that MS wasn’t giving "straight" answers, you were quite possibly referring to me, or one of my co-workers, telling you why you weren’t going to be able to stop users switching tasks. That’s not being elusive, it’s telling it like it is.

    And frankly, why shouldn’t users be able to switch away from your game? If they couldn’t, what would the implications be? What if your game hangs? It is an acceptable customer experience to make them reboot their whole PC in the scenario? What if they want to pause the game and flip to another application for a moment?

  40. Jack Mathews says:

    I agree about Ctrl-Alt-Del, and I agree that the surface excuse is also pure laziness. Well, except that a lot of the reasons that people had to manage their own surfaces was because DirectX’s automatic texture management was absolutely horrible. But that’s neither here nor there :-)

    As for the "straight" answers, frankly, I didn’t deal directly with D3D. I dealt in the OGL games space, and mostly went by what my developer friends would tell me. I also have a feeling a lot of people in the DirectX groups would be giving workarounds such as the "pretend you’re a screen saver" hack straight to the game devs, which would account for the "not straight" answers I’m referring to. So the conversations would go like this:

    "We want to turn off the Windows Key"

    "Well you can look up the screen saver hack"

    "When will this make it into DirectX"

    "There are issues stopping us from doing it, but you can look up the screen saver hack."

    As for getting out of the game, yeah, I think Ctrl-Alt-Del should definately let them out. As for Alt-Tab and Windows Keys, well, I, and about any other gamedev and hard core gamer will disagree with you and Microsoft on that one. But there’s no real changing that one :) I mostly just wanted to get the reasons out there, since there are very useful and practical reasons for the argument of disabling the keys.

  41. Jerry Pisk says:

    Raymond thanks for letting us know how to write a program that cannot be easily killed :) Just name the executable csrss.exe and voila, your process cannot be killed ;) This is just hillarious, I’m surprised no trojans and adwares use it yet…

  42. Raymond Chen says:

    You can still kill it, you just have to work harder. And I’m surprised too that malware hasn’t discovered this yet….

  43. Jerry Pisk says:

    You can kill it with anything but Task Manager, true. But most regular users don’t really have access to anything else… On the other hand, regular users will not really know that they have something they shouldn’t be running so I guess my point is moot.

  44. Anonymous says:

    Raymond Chen is an ol’ time programmer of Windows and his latest story has made me wonder about whether he wants to reveal the truth about things or not. In this story thus, he explains how to kill a process and tends to omit things that are known for one decade but not often underlined.

  45. Shane King says:

    "THAT is why game developers want to disable those godforsaken key combinations. Because for normal application use, hitting Alt-tab is kind of hard, and hitting the Windows key doesn’t stop what you’re doing… In an online game it can win or lose you a match. "

    And stopping me from hitting it can mean I can’t tab back when I need to answer an IM, or look something up on the web, or anything else I might want to use my computer for.

    If I wanted to only use my computer for gaming, I’d only have a console.

    I absolutely hate it when games decide that they’re the only thing of importance and I couldn’t possibly actually WANT to switch away from them.

  46. In the bag tonight: .NET: 9; Admin: 1; Blogging: 2; Dev: 7; Perl: 1; Rant: 5; Securoty: 1; SQL: 3; Tools: 2; Writing: 2; WTF?: 1; WILY: 3; XML: 5.

    Line of the night:

  47. Pavel Lebedinsky says:

    You can use a built-in tool (ntsd) to kill a process that pretends to be one of the "special" processes:

    c:>ntsd -p <pid> -c "q"

    It might even work for some of the real system processes that can’t be killed with task manager or taskkill (I’m too lazy to test this).

  48. infector says:

    It’s stupid! Why anybody would want to make unkillable process? In unix world Joe the User cannot kill system-critical processes, but mighty r00t always has this power. It’s reasonable, because at the end user is controlling machine, not programmer. For example sometimes I want to shut down extremaly_important_backup_process because the tape got stuck or shut down immediatelly all network connections because I think somebody is penetrating the machine.

    And you cannot win this battle. In the last resort, user is always going to win, because he is in charge of the power switch.

  49. Tony Cox says:

    As I mentioned, there are some game programmers who want to make their process unkillable. They don’t phrase it that way, of course. It’s always phrased as "I’d like to disable all those key combinations that throw me back to the desktop or bring up the Task Manager", but the net result if you did that would be that the user could never get to Task Manager or a shell window in order to kill them, and so in effect they’re asking to be unkillable.

    They also get very upset when they’re told they can’t or shouldn’t do that.

    PS. The ‘screen saver’ hack mentioned earlier only really worked to any useful degree on 9x, not on Win2k/XP. I don’t recall ever recommending it to anyone.

  50. Feh. True again.

    But hoping that ALL application programmers will handle focus-stealing better in future is a nice dream. Wouldn’t it be possible to implement per-application settings (instead global), e.g. to specifically set different priviledges like enabling/disabling focus-stealing seperately on load, on modal dialogs, on new windows, and so on? The ability to control the focus-stealing would be a nice addition, because like this I could stop certain applications from annoying the heck outta me while they’re starting up because they apparently need to steal it tons of times on load. Like this I could also finally stop Trillian from tearing me out of games, when message windows show up, even though I set it to extended away.

  51. Mike Dimmick says:

    The SetForegroundWindow lockout is OK, but it can still cause problems with applications which have a single process owning multiple top-level windows (like IE). Begin navigating to a page in IE, then switch to another IE window and begin typing.

    When the first page finishes loading, it often brings itself to the foreground, and your typing gets redirected to the first window.

  52. Raymond Chen says:

    Mike: That’s because a program is allowed to steal focus from itself, and lots of web pages contain script that screws with focus (usually to shuffle away their pop-up window). I hate it too.

    Mario: Interesting idea, but imagine what a typical user would feel when faced with the UI that would control this proposed setting. "Type the name of the .exe for which you want to change the foreground policy (or hit Browse)".

    As I recall, the rule is that a program is allowed to steal focus *once* – and only if its parent process had foreground. The problem is that people keep hunting for loopholes in this rule because they don’t like it. Google for SetForegroundWindow + AttachThreadInput to see many examples.

    Of course these people don’t realize that AttachThreadInput does a whole lot more than just letting you hijack the foreground queue. (Indeed all that other stuff is the whole point of AttachThreadInput!)

  53. Raymond Chen says:

    Tony: I’ve seen direct queries, "I have a program that updates a database. I want to make sure the user exits my program only by going through my program’s shutdown process. Otherwise my database get corrupted. How do I hide from Task Manager or otherwise make my program unkillable?"

  54. Joe Sixpack would have indeed an issue with such a GUI, but it’d be still nice to have such options for advanced users. Maybe it’d be an idea to tie these options to the shortcuts to applications, as additional tab in the shortcut properties.

  55. Mo says:

    Personally, I find IE to be one of the worst offenders for focus-stealing generally. It’s a great idea: steal the focus at 99% through a process [which is actually 100% downloaded and 0% through copying from the cache to the destination directory]. If the user is mid-way through typing something and happens to chance upon the correct key interpreted by IE as "Cancel", well…you guessed it. Having said that, in some circumstances what it *actually* does is cancel the file copy, but sit there waiting for it to complete. Double-whammy :)

    wget in screen is still my favourite tool for downloading things for precisely this reason (closely followed by "Microsoft File Transfer Manager", which I’m going to have to take a look at in detail to see if it can’t be put to better use than just MSDN :)

  56. Anonymous says:

    Domanda: come scrivere un programma che non si può chiudere? Risposta…

  57. Anonymous says:

    Except there are cases when the user for good reasons should not have control of the application.

  58. Mat Hall says:

    Here’s a Delphi code fragment to trap C+A+D.

    function BlockInput(fBlockInput: boolean): DWord; stdcall; external



    procedure SystemKeys(Disable: Boolean);

    var OldVal : LongInt;


    SystemParametersInfo(SPI_SCREENSAVERRUNNING, Word(Disable), @OldVal, 0);



    BlockInput(True); // Lock input

    until BlockInput(True) <> 0


    // Do something



  59. Centaur says:

    Actually, (1) it is not Delphi code and won’t compile; (2) when fixed, it won’t work against Ctrl+Alt+Del, according to MSDN Library.

  60. I play Everquest in a window. I have 1G RAM and 2.4GHz CPU. The game eats up all the ram, and other apps can’t run. Just launching Internet Explorer would take 1 minute.

    Back in the old days I would use Task Manager to adjust the priority of the eqgame.exe to BelowNormal. Having done this, the game would continue to run smoothly, but not interfere with the other apps. I could even run 3 copies of Everquest concurrently + TS clients + IE + more, and all was good.

    Today when I try to change the process priority, I get Access Denied. You said "keep users in control of their own programs", but here I have no control.

    1. How do they do it?

    2. Why do they do it?

    3. Why is EQ such a resource hog, when it clearly isn’t necessary?

    4. How can I change the process priority anyway?

  61. Cooney says:

    Coming in late, but oh well…

    My take on the whole focus issue is that it’s properly the purview of a window manager, which is something that Windows lacks. Give me the power and the information to implement my own policy and block those irritating popup dialogs, and I’ll happily go down that road. You like it the way it is, that’s fine – I just want my computer to do what I want.

    As for the C-A-D, windows key, etc, you (I think it’s Tony specifically) aren’t being reasonable. The common case for released games is accidentally hitting the wrong key and not worrying about how to restart a crashed app. I don’t ever have to do _that_. I play Civ3 for a few hours until it hits a nasty driver/video card bug and reboots itself, rendering all arguments moot. I always save my work before playing a game like that.

    As for EQ, I’ll bet they did something sneaky like attach a debugger-like app in order to prevent some exploit. As to why it eats so much memory, I guess that’s a matter of priorities – people pay for new shiny things, not smaller memory sizes. Of course, Raymond will probably correct me ;)

  62. "I play Everquest in a window. I have 1G RAM and 2.4GHz CPU. The game eats up all the ram, and other apps can’t run. Just launching Internet Explorer would take 1 minute. "

    That’s another huge question I have about Windows – why does it deal so badly with applications that hog the CPU.

    With EverQuest running, something that is usually nearly instant (like just switching focus to Outlook 2003) can take 15 seconds. That’s just not reasonable.

    Isn’t Windows supposed to boost the priority of the application that has focus? Whatever it is that’s supposed to do that doesn’t seem to be working, at least not when EverQuest is running. And like Jay Bazuzi said, EQ prevents you from changing it’s priority, meaning you have to go and boost the priority of every app you want to be responsive while you’re logged in.

    – Steve

  63. Raymond Chen says:

    The scheduler does an excellent job of making sure that the foreground program gets preferential CPU. The problem is that CPU is not the gating factor. It’s memory. EQ has sucked up all the memory in the system, so the foreground program can barely take two steps before it hits a page fault and needs to swap.

    You can run a program inside a job object to cap its memory use. You can also use a job object to keep the program from messing with its priority.

  64. Norman Diamond says:

    I’m not in the mood to look for the MSDN page that said this, but it did say that Windows 95 and 98 actually got priority inversions right but NT and 2000 didn’t. If a high priority task (e.g. the foreground program) is waiting on a resource that is occupied by a low priority task, the occupier’s priority should be boosted to match the waiter’s priority until the resource gets freed. Then the former occupier gets reduced to its proper priority and the high priority task gets the resource and gets to execute. NT and 2000 gave random amounts of boosts at random times instead. No wonder foreground is less responsive here.

    Meanwhile, the priority system, though more intricate than VMS, still suffers from the same deficiencies. DEC used to recommend not separating various kinds of processes by too many priority levels because even a difference of 1 made a huge difference. They forgot what the purpose was. Yes a difference of 1 priority level nearly halted the lower priority task, but it didn’t help the high priority task. When the low priority task encountered a page fault, VMS boosted its priority by 6 levels. So a page swapping operation took over in order to let the low priority task execute one more machine instruction before getting halted again. All of these page swaps continued to interfere with the desired progress of higher priority tasks. We had to separate different kinds of tasks by 7 levels so that higher priority tasks would not get blocked by the page faults of low priority tasks. And there were only about 13 levels to work within, practically speaking.

  65. Ed says:

    Another example similar to the EQ process hog:

    Try copying a huge file, 1 gig or larger. Wait until it’s about halfway through so that it’s soaked up all of your memory cache, then do something simple, try opening up an IE window, etc.

    It takes forever.

    But if you try it on a dual-proc/hyperthreaded cpu, it does a *much* better job of handling the load.

    If it was just a system memory problem, why can the dual-proc system handle it gracefully, and the single-proc system can’t?

  66. It’s back to the arms race.

  67. jfo's coding says:

    For the most part, activation and focus work pretty darn well in windows, until you want to tweak…

Comments are closed.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index