Back in the day I had hilarious fun trying to use Norton's (I think) tool for making a bootable virus scan disk.

It put the bootable OS and virus scanner on one floppy, and the virus definitions file on another.

Except that the virus definitions file didn't FIT on a "1.44MB" floppy.

At one point in the original I managed to trigger a bug where one of the enemy's "road flags" was literally on our border, and I found I could join my road to it.

My peasants went and stole everything he had lying around. :)

I loved that game, partly because on the Amiga you could do two-player multiplayer with two mice in splitscreen.

Tennis For Two

Created in 1958 on an analogue computer. ANALOGUE!

However, DLP has its own problems (the rainbow effect is awesome!). LCoS is just another LCD-based technology (assuming I understood the wiki page on LCoS correctly), just with the LCD directly mounted on a mirror instead of projecting through it (and therefore I assume it has the same problem with light getting through "black" as a through-projection LCD). The Wikipedia article on LCoS has an uncited statement that LCoS is better contrast than projecting through an LCD, but doesn't mention black level at all.

LED backlights are no good on very large panels, because they use LED strips around the edge or on one side and a large light diffuser, which still produces an uneven result at large panel sizes. ELP is far better (it's a full panel sized light over the whole display), but far more expensive, and can still have trouble getting even illumination.

Digital projectors often suffer the same problem, as they use a much stronger light projecting a small LCD, it tends to bleed through the black.

There are projectors which dim their bulb for dark images just like you described flat panel TVs doing.

Probably a problem with larger TVs only, which can only use strong backlights around the edges, causing a lot of problems trying to light the middle.

My 22" computer monitor has no trouble what-so-ever with black. Or contrast.

Which drivers?

XP x64 has been my primary/gaming PC's OS (through three (IIRC) PC parts upgrades) since MS did the free XP to XP x64 upgrade for people with "64 bit" PCs which only had a 32-bit XP on.

Driver support is pretty awesome. Even my no-brand webcam works.

However an IO bottleneck will have a tendency to freeze any programs using the same IO device in blocking mode. e.g. trying to browse the web while bittorrent is going at full speed often causes the browser to time out.

Even then that's due to lack of a decent IO scheduler. IIRC XP's is first come first served, aka greedy git takes all. In XP the greedy process even gets disk IO priority over the Windows kernel trying to page another process back in from page file, meaning a disk and ram-usage heavy program can practically lock up the entire pc, by forcing other processes (including explorer) to completely page out to disk and then consuming all the disk IO, denying them a chance to page back in. You can't even start task manager and kill the offending process while this is happening, because Windows can't get any disk IO time to read the tiny taskman.exe.

I think this was fixed in Vista.

I always thought "disks" were those square magnetic things and "discs" were those round mirrored things.

Unfortunately, 16-bit Windows 9x apps can't be run on Windows x64 either, and dosbox can't run them...

Unfortunately IE seems to ignore that completely.

And in the case of the server specifying multiple accepted charsets (say ISO-8859-1 and UTF-8), there is no standard for how the client should inform the server which charset it used.

However, having remote access to the host of a bunch of virtual machines would be the equivalent of physical access to those virtual machines. You can change the mounted media, reboot them...

Forcing the browser to utf-8 doesn't fix the corrupted text, so Slashdot is obviously mangling it server-side.

I never said it was.
I said browsers submit forms (e.g. the comment form) in either the page's charset or in utf-8 if that isn't possible, but don't tell the server which. Which implies that the page's charset isn't already utf-8.

It's possible that the server is safely storing and handling utf-8 data, and it is just the charset being sent by the server in the content-type header which is causing the BROWSER to screw up the rendering. I'll check.

It's not just slashdot, it's also the fact that HTML/HTTP provides no way to know what charset a form was submitted in. Some browsers append a charset to the content-type http header they send, but most try to send in the same charset as the page, or utf-8 if that's not possible, but don't tell the server which...

I.E. is even better, as it ignores the charset the server sends in its HTTP content-type header and tries to guess instead, unless you put a content-type meta tag in the page.