The Old New Thing

If you really wanted to keep the LED you could add a LED font to windows (I know, I know, money and time)

Offtopic/Nitpick: Your trip reports are getting very long, does your blogging software support some kind of "read more" link. I like to checkback a couple of time a day to read the new comments, but now I have to scroll like crazy to see the comment counts for the last two windows related posts

What? No snapshot of the new and improved display?

Not all of us have international versions of Windows installed (or plan to install them).

I love the Nitpicker's Corner.  

s/8-segment LED/7-segment LED/

What does "lost" mean here exactly ?

I guess It can't be "lost all source codes including backups", since the window class for the displays (AND some frames) is "DavesFrameClass"...

Ahh... I wish we used Roman numbers more. Where I lived, before computers, it was pretty standard to do months like this (today): 25. VII 2007. Neat, huh?

To be honest, while the old one is "kinda cool retro" the new one looks better.

And I'm assuming "lost" means that it was removed from the source for future versions.

@Medinoc: probably that it's no longer called that in Windows Vista.

Task Manager thankfully got quite a big overhaul so some of the stats are no longer (quite so) misleading.

"s/8-segment LED/7-segment LED/"

Nope, it's an 8-segment LED.  Notice that the middle horizontal bar on the 3 doesn't go all the way across.  That requires 2 segments in the middle bar, not just 1.

I'm more surprised it has a windows class. I'd expect TaskManager to bypass quite a few OS layers, because it's the OS component you need when things start to misbehave. I.e. when an app starts using 100% CPU or starts trashing the disk, or starts creating thousands of windows, Ctrl-Alt-Del should not try to start another app. Instead, I'd expect a component that's already loaded to tell the graphics layer it needs a few pixels, the scheduler it needs a CPU core, and to draw directly. That suggests to me an implementation as part of CSRSS

I just checked with Spy++ and it's still called DavesFrameClass in Vista Ultimate x64.

Raymond commented: [Um, just run Task Manager on Windows XP or later to see the new display.]

It will have to wait until I am home. We still run 2000 at work.

"How do you render characters U+0660 through U+0669 (٠.١.٢.٣.٤.٥.٦.٧.٨.٩) in an LED font?"

You* could try emulating a 16-segment LED instead. Zero looks awkward, but 1-9 shouldn't be a problem. 7 Would look more like Y than V, and 8 would be similarly odd upside-down, but it's not like 4 ever looked entirely right in a 7-segment display.

Adding dots at each intersection (we don't have to stick 100% to the classic display, it's more about getting the look - as GregM pointed out, my nitpick was incorrect as the original splits the middle bar to make the 3 look better, which almost never happens with real LED displays) would allow indic 0 and a few more roman letters (e.g. lowercase i and j become possible)

And it would still be retro cool!

*Not actually you. This is idle speculation, and even if it weren't, it would aimed at MS in general.

The trouble with 25-VII-2007 is that it doesn't confuse anyone because it's unambiguous. That is boring. 11/9/2001, on the other hand, confuses the hell out of dim colonials who think it means 9 November.

[Note that the bombers who blew up London ostensibly on Islamist grounds the day after Paris lost out to London on staging the 2012 Olympics chose the date 7/7 to promote international harmony and understanding].

Thanks for this insightful post Raymond, since the first day I installed XP back in 2002, I always wondered why the LED-digits had disappeared from the Task Manager.

I originally thought it was because there was not enough space to display all the digits on a computer that would have a lot of RAM (pre-XP shows the commit charge in kilobytes, XP and later shows them in megabytes).

For those of you with out access to XP (and google or live search)

http://www.updatexp.com/images/taskmanagerlge.gif

Dave's not here, man.

</oblig>

@Raymond 'Somewhat paradoxically, many Arabic-speaking countries don't use Arabic numerals! They use Indic numerals.'

And to add to the confusion they don't use Indic numerals in India. They use Devanagari numerals. At least when they're using Hindi and not English.

० १ २ ३ ४ ५ ६ ७ ८ ९  (0-9)

Slightly off topic maybe but...

Mr. Chen, do you have any idea why Taskmanager (Windows XP) seems to not have a higher task priority than other running software?

End result being that if a application hogs the system it is very hard to get taskmanager up.

I've always been curious why this behavior has not been improved/tweaked since XP was launched!

*scratches head*

There was a method behind the madness, actually.

If I remember correctly (and it was 10+ years ago, so its a little hazy), someone on the Win3 or User teams thought it would be clever and efficient for the Group box to paint itself during WM_ERASEBACKGROUND instead of during WM_PAINT.  This meant that regardless of where you had clip children turned on, the only way to get a group box to paint was to let it obliterate the controls within it first.

I hate flicker.  I had three criteria for taskmgr, which is that it should never, ever crash, it should never flicker during resize, and it should stay under 100K total.  Hence, I wound up subclassing the group box to make it do what I thought was correct, and you get a taskmgr without resize flicker.  Putting my name in the window class was not particularly creative, but this was before profanity was discouraged in the source code even, so it wasn't that outrageous.

Now, if you look at the pages that were added after I left MSFT, such as the Networking page, you can grab an airsickness bag, size the thing, and watch those pages flicker like its 1999.  It's also 163K now, but I digress.

If you notice the only other flicker you'll see is in the property pages themselves (such as the tabs), but I wasn't about to subclass the entire property page rendering.

While I'm waxing poetic about taskmgr, some other trivia:

The ASSERT that included my (old) home phone number was a bit of hubris and a genuine attempt to find a bug that was really hard to repro.  About once every trillion cpu cycles the sum of the CPU times would exceed 100.  The kernel team said it was my bug, and I of course was certain that it wasn't.  So I put my home phone number in there so that no matter the time or place, I could debug it if it ever occurred.  As a result I was able to prove it was a kernel book keeping bug, not a taskmgr bug, they fixed it, and the assert should have come out.  But it didn't.  In the next eight years, though, no one ever called after that.

Taskmgr was actually written as a piece of shareware, but at the last minute I asked "The Other Dave and Mark" if I could put it in the build, and given the task list thingy we had inherited from the Win95 shell was less than useful, they gladly agreed.

The LED numbers were cool in their day, but of course we all outgrew them.  At that time NT was not particularly localizeable anyway.  We had a whole team, such as the NT-J team, to port it to another language (like Japanese in that case, which you can see in some old Arnold movie).  So there was the presumption that for other languages they're just replace it with text.

Taskmgr was written in C++, but that required picking up the CRT.  That would have hurt the size, so instead I figured out how to simulate the linker's init code (that calls static contructors and so forth), thus keeping the size down instead of linking in the CRT.

In aid of the "never crash or hang" mantra, any time taskmgr calls an external DLL of questionable quality it dynamically loads it, and if I recall, calls out inside a try/except, sometimes from a separate thread so that taskmgr keeps on chugging.  You might munge the state of shell32.dll, for example, and might even munge your own process, but it does avoid the vast majority of problems.  If you've ever waited for the Start/Run dialog in Win95, it avoids that.

And that's all I have to say about that.

Actually, when I wrote it, I forced taskmgr up to "High" priority (I wanted realtime, but there are various reasons not to do that).

If it's not doing that in Vista, it might be because its not run with escalated rights and hence can't bump its own priority.  That's just a guess.

I guess because of #11 (not zero indexed) his name was really Dave. I understood that when you are mocking, names are not replaced whereas when you are teaching a lesson, names are anonymized. In what category does this posting fall and does this category always imply that names are not anonymized?

And who is so stupid and uses his name for such a feature?

Davepl: I really hate to disappoint you (and it may be out of your control now) but currently Task Manager on Vista is crashable as we speak

I have already submitted several bug reports about it in various places during the past months, so I'm hoping it gets fixed soon

I haven't seen taskmgr crash on Vista yet, but they've partied on it for years since I left.

To Steve:  as for who was so stupid to use their name in a feature (actually, a Window class), I guess that's me.

Then again, you must be truly special to get so worked up and personal about something you saw in Spy++.  Sorry if I ruined your day.

Since we're all sharing fond memories of task manager...

One of the devs who worked on taskmgr after Dave left sat accross the hall from me.  One day he got a 64-proc computer because he had a bug that task manager could only display up to 32 processors (64 being way-beyond belief when the code was written, I suppose).  That was cool, seeing 64 CPU meters all chugging along.  Of course, once he had fixed the bug, they took the machine away...

I <3 task manager

ctr+shift+esc i learned before ctr+c and ctr+v

64 processors? wow, most I've ever seen is 16, and even that made me giddy (it's a dual quad core with hyper threading)

Steve: although a nitpicker should get no response, you might want to consider that the Dave described here *could* be Bob, or any other person mentioned previously.

> One of the devs who worked on taskmgr after Dave left sat accross the hall from me.  One day he got a 64-proc computer because he had a bug that task manager could only display up to 32 processors (64 being way-beyond belief when the code was written, I suppose).  That was cool, seeing 64 CPU meters all chugging along.  Of course, once he had fixed the bug, they took the machine away...

How big was that thing, anyway (and how loud)? I have this image of a half rack of computer in my head.

Further off topic, with the 4x4 stuff being available at a reasonable pricepoint, we're getting closer to an affordable 64 way box.

Good article.  For those interested, here is a very cool shot of taskmgr in action: http://cache.gizmodo.com/assets/resources/2006/08/6800.jpg :)

I do notice that even though the networking tab's graph does flicker pretty badly, according to Spy++ it *is* using DavesFrameClass. What would be different that would cause it to flicker so badly?

The most I ever had access to was a 4-proc back then.  I actually thought the limitation on NT was 32 procs (a DWORD bitmask in a few of the relevant APIs).

Though only tested by simulation, even the earliest taskmgr should support an "infinite" number of procs.  After some number (probably 16) it starts grouping CPUs into the same little graph (ie: pane 0 would be CPU0 and CPU16, etc).

OMG, your finely honed sense of irony is truly delicious!!!

I'd just like to thank Davepl for that hard work: taskmgr has come to my rescue many times in the past when Explorer has been %@$£ed too hard to respond to anything at all for a long period of time.

(Sadly, on my current XP installation at work it no longer updates: the process list is jammed on whatever was there when it opened. Somewhat bizarre, and no doubt not remotely Davepl's fault, since it sounds as if he went to great pains to avoid exactly that problem!)

James: Is it possible you turned off refreshing (View->UpdateSpeed)?   Does F5 refresh it manually?

Exceptionally cool to hear from "the real Dave" :)

I used to have access to a Unisys 32-way server in a previous life. It was about as big as a full rack, but it had redundent everything (just one of the power supplies was about as big as your average desktop PC).

I guess nowadays, though, with quad-core CPUs available, you could squeeze 32 "CPU"s into a much smaller space :-)

Definitely cool to hear from Dave himself. Might I suggest, Raymond, that when doing history posts such as these in future, you try contact the original author(s) so they can add their commentary as well? Assuming that that's not what happened in this case. ;)

Nitpicking dave about "subclassing" the group box : This looks more like superclassing, doesn't it ?

About the priority, for Roger Hågensen : The task manager IS on high priority, but the shell is not. So, the task manager is slow to come up because Explorer is launching it in a separate process.

For Michiel : The problem with the window limit was explained some time ago: A process can only create 10000 windows out of 30000. Of course, if you start multiple instances of the GIMP, you *might* reach the limit...

Davepl: Refresh speed is 'normal', hitting F5 *does* force an update - it's just the periodic updates which aren't firing. Stranger still, changing the frequency seems to have fixed it (even 'normal' works properly now, when it didn't before) - yet rebooting didn't. Perhaps it was stuck on 'Paused' internally, but not reflecting this in the menu, so changing the setting synced the two up again?

Medinoc: when launched from the SAK window or via shift-ctrl-esc, it's winlogon.exe not explorer.exe which launches taskmgr.exe, and winlogon.exe has priority 13 on my system, against explorer.exe's 8.

On multiple CPUs: thanks to HyperTransport, you don't even need to cram them all into one box; a company demonstrated a system recently using external HyperTransport links between a couple of multiple-Opteron machines which made Windows see them as a single system, despite being in different cases.

Of course, if someone had been feeling cruel, they could have given the developer a copy of QEMU instead - IIRC it can emulate multiple CPUs without needing SMP hardware underneath. The performance would be terrible, but good enough to fix a Task Manager 64-CPU issue with!

>> Taskmgr was actually written as a piece of shareware, but at the last minute I asked "The Other Dave and Mark" if I could put it in the build, and given the task list thingy we had inherited from the Win95 shell was less than useful, they gladly agreed.

--

I am amazed how many the best things in software grew out of pieces of passion, that would never have made it through the "accounting firewall".

But I guess that's not limited to software.

Just for fun:

http://supermicro.com/products/system/1U/8014/SYS-8014T-T.cfm

This is a 1U 4way intel box. with current quad core , it's 16 procs and throwing a myrinet card into it allows you to approximate 64 procs in 6U - I have a pedestal rack that's about desk height which could accomodate about 128 cpus using this (2U battery, 2U myrinet router, switch on the side).

> Of course, if someone had been feeling cruel, they could have given the developer a copy of QEMU instead - IIRC it can emulate multiple CPUs without needing SMP hardware underneath.

Is this a complete virtualization package, or would you have to run it inside a virtual PC? Decent virt makes fixing all sorts of problems easy that were once painful and slow.

Qemu is virtualization software, if that's what you're asking.  This is the list of CPUs that it's able to emulate (both to run a user-mode process that was compiled for that CPU on a Linux or OSX system that runs on a different CPU, and to host an entire OS, which is in an alpha state when run on Windows):

http://fabrice.bellard.free.fr/qemu/status.html

[Maybe the developer would be satisfied with an emulator, but the tester will want a real machine. -Raymond]

fair enough, but the developer will have to get a bit more intimate with the bug; if it's good enough for a repro, then that's the important thinig.

I wonder if Dave can give any insight into the "double click on the grey bits to hide all the window controls" behaviour, that people never seem to be able to reverse.

I hate flicker too.  But wouldn't a flicker-free app be more likely to slog or fail in a stressed system due to the additional graphics back-buffering compared to the flicker-free version that blats to the screen as soon as it has something to blat.

Yeah, the double-click to hide the frame elements was a bad idea.  I actually did it because the other applets we had in the NT build at the time, such as the clock, had that "feature", so I added it as well to be orthogonal with them.  This was like 1995 though, so your Mom wasn't using NT :-)

Before desktop widgets, it was also a way to make a little CPU graph and stick it in the corner of your window (if I recall, the minimum size resitriction is removed when in the frameless mode).

As to the person who asked about flicker-free being slower, not really.  It's not double or triple buffering anything, its just painting only what it needs to and in the right order.  I guess it could actually work out faster, since by definition flicker happens (as opposed to tearing) when you paint the same area twice.

And for the person that said the shell runs at regular priority and hence on a crippled system can be slow to bring up task mgr, that only applies to the tray menu.  I put the CTRL_SHIFT_ESC handling in winlogon itself so you weren't dependent on the shell being alive to start taskmgr.  You can have all the priority you like, but if its paged out to disk its not coming back in any faster just because its a higher priority (or at least not to my knowledge, maybe the vm system does...)

> Yeah, the double-click to hide the frame elements was a bad idea.

Well, I don't think so, I still like that feature. I think it actually is a good idea. But maybe there could be a right click context menu, with an entry "switch to normal display", for the users that don't "get it" ...