The Copy Of Doom

Would you like to make a Windows PC that has some network-shared folders containing large files look as if there's something horribly wrong with it?

Well, that is, I have just discovered, easy!

Just copy one of the files - let's say they're movies - over the network to another computer.

Then, before the first copy operation is complete, start copying another. And another. And another.

Like, maybe you're copying all of your absolute favourite TV shows and movies, and you're just clicking and dragging whatever catches your eye, and letting the little copy dialogs pile up.

This is exactly the sort of task that a proper file server is specifically designed to handle. Even if the server's storage isn't terribly fast, six people all asking for different things on the same drive at the same time should be put in a queue, rather than asking the waiter to carry every order for the whole restaurant at once, as it were.

But consumer versions of Windows aren't set up to do that. They're meant to serve a single user, and see nothing wrong with just doing exactly what they're told to do if several remote computers - or even just one - ask them to do something like copy 20 large files at once.

(You can probably alleviate at least some of this problem in consumer Windows versions by something like selecting the "background services" and "system cache" options in WinXP's Performance Options -> Advanced tab. Even a cheap Solid State Drive would immensely reduce the problem, too, since the multi-millisecond seek time of mechanical hard drives is a big reason why it happens, and SSDs have near-zero seek time. But SSDs are, of course, still rather too expensive per gigabyte for tasks like bulk video storage.)

Once you've got several large copy operations all happening at once on, let's say as a random example, the Windows XP computer on which I'm writing this, this "target" computer will be flogging to death the drive(s) on which the big files reside. Data to and from those drives probably has a bottleneck or two of its own before it gets to the network, too; the ATA I/O hardware in consumer PCs is not made to deal elegantly with several drives all talking at once.

The upshot of this is that any operation which expects one of those drives to respond snappily to a request - or, quite possibly, which is just trying to talk to some other drive in the computer - will now suddenly find itself waiting a lot longer for that response. And that's one of the standard ways in which programs can misbehave. It's perfectly normal for programs to, say, ignore user input while they're saving a ten-kilobyte file; that should only take a moment. But if it now takes 30 seconds for that tiny file to be saved, as the save operation tries to push through a storm of seeking and reading, the program will appear to have hung. This applies to lots of things besides saving files - if modal windows suddenly take 30 seconds to appear, for instance, the program will seem just as broken.

On the plus side, as soon as you cancel the 20 simultaneous copy operations, the target PC will immediately start working perfectly again.

On the minus side, before you cancel the copies, it'll be doing a very good imitation of a computer with one or more failing hard drives. And practically anything you do to try to figure out what's going on will just add more input/output tasks to the mess, and make things even worse.

Eventually, the user - let's call him Dan - will try to shut the computer down, get sick of waiting for the numerous simple disk tasks this entails to conclude, and just turn the darn thing off. And now, the metaphorical plate-juggler will forget about all of those plates that are still in the air, and leave them to crash to the floor.

In my case, this meant various programs lost some of their configuration data. Firefox, for instance, was back in the default toolbar and about:config state, and all of the extensions thought they'd only just been installed. My text editor forgot about the files I used to have open, and Eudora lost a couple of tables-of-contents and rebuilt them with the usual dismal results.

(If you lose the TOC in a mail client like Eudora that uses the simple mailbox format in which the main mailbox file is just a giant slab of text, and the TOC is the separate file that tells the programs where actual e-mails start and end within that text, rebuilding the TOC probably won't go well. It'll give you a separate "e-mail" for every version of a given message that looks as if it might exist. So if you saved an e-mail you were writing five times before you finished it, you'll get five separate versions of that e-mail, each at a different stage of completion. When you "compact" a mailbox, you're getting rid of all that duplicate data.)

Oh, and the file I'd been writing something in for the last hour was now a solid block of null characters. As, delightfully, was its .bak file.

I lost very little actual data, because I make regular backups. (Remember: Data You Have Not Backed Up Is Data You Wouldn't Mind Losing.) And stuff I'd done since the last backup which I wasn't actually working on at when the Copy Of Doom commenced was all fine. Good old PC Inspector even let me recover a bit more data.

Even quite a lot of data loss would have been preferable to what I originally thought was going on, though. It looked as if the boot drive - at least - was failing, leading me to another of my disaster-prompted upgrades. It's about time for a new PC now anyway, but it's ever so much more civilised to upgrade when the old computer's still alive.

God damn it

You know that DirectX problem, that I thought I'd fixed by buying a whole new video card?

Well, it looks as if what I actually need is a whole new computer. Isn't that great!

Yes, the problem is back again. Last night I watched a movie just fine; today I open a video file and as soon as I switch to fullscreen I've got three frames per second again, because DirectDraw acceleration has just turned its own self off again for no damn reason at all, and cannot be turned back on.

This is the way it always happens. It doesn't happen after I reboot, or after I install some particular piece of software, or in response to any actual change in the system configuration that I can see. DirectX acceleration just works one minute, and it doesn't work the next, and that's it.

From past experience, I am confident that rolling back to a previous system restore point, removing and reinstalling all video drivers, or even reinstalling Windows from scratch, will solve the problem for only a little while, at best.

I presume it's something wrong with the motherboard. Or something.

I don't need a new computer, I don't much want a new computer (more speed nice, lost day setting everything up again not), and I sure as hell don't want to pay for a new computer.

But since the memory and CPU in this computer won't work in a new one, I might as well get a whole new PC, lacking only a video card. Clearly, nothing else is going to fix this problem.

I feel stupid, contemplating a whole new computer just because a couple of graphics acceleration modes don't work on this one. Everything else works fine, and I can even cheat Direct3D into working, so I can play games if I want to. If I get a new computer, I'll be doing it just so I don't have to use crunchyvision low-res modes when I watch TV on my enormous monitor. How spoiled is that?

Kids are starving in Africa, et cetera.

God damn it.

DirectX redux

So, I've got that DirectX Acceleration Not Available problem again. DirectDraw Acceleration, Direct3D Acceleration, AGP Texture Acceleration; all Not Available. Direct3D was available until I tried turning it off in dxdiag, then ran dxdiag again to see if all of the options were back.

Nope, that trick doesn't even work once, any more; now they're all gone. Again. Graphics card allegedly has "n/a" memory on it, et cetera et cetera.

The last time this happened I tried all kinds of things, not a one of which worked, and ended up reinstalling Windows. But somebody mentioned that this was exactly the kind of problem that Windows XP's System Restore (which I of course did not have turned on) was created to solve.

So in this Windows installation, I left System Restore turned on. And when DirectX screwed up yesterday, I used System Restore to roll the system back to its status of about a week ago.

And hooray, the problem was solved!

For about twelve hours.

I'm not crazy about the idea of restoring my system to that save point once a day for the rest of my life. I can see no other option, though, unless I get a whole new computer. I know for a fact that cleaning out all of the drivers and DirectX files before reinstalling will not help at all; all that does is take a long time and require a large number of reboots.

Perhaps a new video card would do it. This GeForce 7800 GT is pretty old and dusty; perhaps the problem does in fact have something to do with the video card failing some kind of obscure internal test, as when hard drives drop back into PIO mode.

The graphics card does still work just fine, as far as I can see; 3D mode is A-OK when DirectX is, you know, working, and OpenGL 3D is A-OK even now. I just ran OpenGL Quake 2; everything's fine, and the video card fan ran up to higher speed as it's meant to.

But perhaps the card didn't give Windows the right password yesterday, or something.

I could try digging up another graphics card, but I haven't another PCIe card in the house, and this computer's too young to have an AGP slot. So I'd have to find some ancient PCI card, and I think the only one of those I've got is in the file server.

God damn it.

Yet more seam carving

When last we visited the wonderful world of image "retargeting" by means of the cunning seam carving technique, I envisaged a decent free seam carving Photoshop plugin in the near-ish future.

Well, that hasn't turned up yet. But a couple of options besides and that GIMP plugin have.

The inventively named Content Aware Image Resizer is a simple command line utility that can only cope with BMP format images, but gets the job done (a bit slowly...), is multithreaded, and is GPL-licensed so C++ hackers can fiddle with the source.

Resizor is a standalone Windows app, which is only single-threaded but still seems a bit faster than CAIR (I think is faster now than it used to be, too), has a bunch of fancy resizing algorithms as well as the seam carving "Retarget" option, and has a graphical interface too.

Resizor only lets you make an image smaller by seam carving (one of the interesting features of the technique is that it can just as easily enlarge images as shrink them), but it does what most people want to do.

New Nvidia drivers: Worth having.

I just installed the brand new v163.71 Nvidia drivers (the last non-beta release was v162.18), and benchmarked Supreme Commander before and after. There's a small but significant improvement.

I'm tired of seeing articles about AMAZING NEW DRIVER IMPROVEMENTS OMG and then discovering that there's only any difference if you're using a GeForce 8800 on Windows Bloody Vista.

I've got a 32-bit-WinXP computer with a 2.2GHz (at the moment) dual core Athlon 64 and a 256Mb GeForce 7900 GT.

That's probably still faster than the average, but it's pretty far from the current cutting edge. (Only two cores, dahling? However can you cope?)

Driver tweaks aimed at the super-expensive dual-slot super-cards won't help me at all. I'm guessing that they won't help most of you, either. Tweaks that help a GeForce 7900 ought to be some use for various other current affordable Nvidia cards, though.

I've also got an effing big monitor, so I ran the tests in 2560 by 1600 resolution. That's practical for fullscreen Supreme Commander if you've got some flavour of 8800 (ATI aren't really in the very-high-end race at the moment), but it's actually very playable if...

Supreme Commander at 2560 by 1600 split the monitor between the normal view and the easy-to-draw topographic-view map.

Running the standard "perftest" benchmark in that resolution guarantees, despite Core Maximizer, that the game will be video-card-limited most of the time.

The Supreme Commander benchmark reports total frames rendered, "sim" performance (how fast the game calculates everything-but-graphics), "render" performance (graphics alone) and a "composite" score that roughly represents overall performance.

In this graphics-heavy test, my "render" result increased by nineteen per cent with the new drivers. The giant resolution and less-than-incredible video card meant that, in the peculiar jargon of the perftest benchmark, the "render" score only improved from minus 1029 to minus 863. But trust me, that's still good.

The logged-frames difference was +0.7%, which probably means less than experimental error and definitely means nothing you'd ever notice. The sim score improved only slightly more, at +1.6%. But the composite score improved 4.7%, from 5794 to 6065.

You probably wouldn't actually notice that in play - it's a general rule of thumb that differences of less than ten per cent aren't noticeable. But almost five per cent is not a bad improvement to get for free.

Complex Supreme Commander games are almost 100% CPU limited. Smaller games, though - and even complex games when you can't see much of the enormous map you're playing on - don't give your graphics card much time to breathe, especially if you've taken advantage of SupCom's still-rare ability to make use of a second monitor. So I don't think I'm lying with statistics, here.

(I'm not, to be fair, actually playing much Supreme Commander at the moment. I got ETQW yesterday, and intend to Strogg 4 Life for a while before getting back to the direction of vast robotic armies.)

The error message Olympics

The Error'd series on what-used-to-be-TheDailyWTF occasionally features some magnificently huge error boxes. I think the second one in this post has to be the record-holder: A standard Windows error box, 401 by 737 pixels in size.

I, however, quite often see one with 3.8% more area, and even less usefulness.

When the server that supports the excellent Pennypacker Penny-Arcade-indexing Firefox extension is down, the extension becomes unhappy.

It, then, serves you up with not one but two of these petite little beauties...

Pennypacker error

...every time you look at a PA comic page.

That's 683 by 449 pixels, folks.

And feel the quality!

They seek config here, they seek config there...

My recent reinstall reacquainted me with the delightfully varied places in which Windows programs keep their configuration settings.

In the olden days, you knew where the config files were. Old DOS programs didn't necessarily have config info; you just gave 'em parameters on the command line, as the Great Beards intended.

When there were enough persistent settings to require separate configuration storage, you'd just have a text file called progname.cfg or something in the program directory. Easy.

Some programs still do this, even today. Blessed be the name of those programs, for you can often just run 'em from their directory and have everything work, whether or not you've ever run an installer for that program on your current Windows install.

But there are so many other places where Windows programs, in this modern age, may keep settings.

Some of them make their own directory in Documents and Settings\username\Local Settings\Application Data\, for instance.

Others use Documents and Settings\username\Application Data, just to keep you on your toes.

(Documents and Settings\username\Local Settings\Application Data also contains the XP IconCache.db file, deleting which can cure some weird icon problems. Or at least change them.)

And some programs, of course, tuck their settings away in the registry. Typically in some branch that'll have a different name when you reinstall, so you're thwarted even if you get all clever and "Export" that branch from regedit.

(I was quite proud of myself when I successfully edited the exported .reg file to put the settings for that one awkward program in the new long-nonsense-named registry branch.)

Some programs even decide to strike a blow for individualism by putting config files in the parched wasteland of My Documents. Cunning!

(Yes, I am aware that Mac OS X has one place where all of this stuff Must Be Kept, and Often Is. I agree unreservedly that just switching to a lovely trouble-free Mac would make settings transfer a great deal easier, by relieving me of many of the programs whose settings I would otherwise have to transfer, not to mention a substantial amount of the employment that so tiresomely requires me to use said applications.)

The whole installation-transfer adventure did have some bright patches. Some applications that look as if they ought to be a mass of horrible encrypted untransferable setting info actually aren't at all. Valve's "Steam" game download system, for instance, can trivially easily be ported from one Windows installation to another. Just install Steam on the new computer, then copy the (huge) steamapps folder from your old install to the new one. Done.

I even successfully exported and then re-imported the security certificates for the Australian-Government-issue Goods and Services Tax software, which isn't as legendarily bad as you might think but still doesn't inspire confidence that such a feat will actually be possible.

Oh - I'm also sure I'm not the first to be annoyed by all of the software companies who insist on making their install directory not Program Files\ThisProgram, but Program Files\CompuGlobalHyperMegaNet\ThisProgram, apparently because they assume you're going to be so impressed with ThisProgram that you'll buy a whole suite of other Compu-Global-Hyper-Mega-Net software, which must be kept in one directory for, um, neatness. Or something.

Later on, if you're trying to find the ThisProgram install directory (or even its entry on the Start menu, which will of course also be a company-named subdirectory), your eye will slide right over the CompuGlobalHyperMegaNet directory, because nobody outside CompuGlobalHyperMegaNet has any idea what the company is called.

The most outstanding example I've seen of this approach is from one Juan M. Aguirregabiria, whose programs, that's right, want to install themselves in Program Files\Juan M. Aguirregabiria\...

(And then the program of his that I tried had some DLL error or other and didn't even freakin' run.)

The Case of the Vanishing Icons

One of the great entertainments that awaits you whenever you reinstall Windows is seeing what new and strange personality features your fresh install exhibits.

It happens almost every time, and usually within days, or possibly even hours, of the reinstall; some weird thing arises that you've never seen before, even if all you've done is reinstalled the same version of Windows on the same computer you were using before.

Munged icons are a pretty common Windows problem - the OS messes up the pointers to its cached icons file, so each class of file or folder gets a semi-random new icon. But this new install of mine just came up with a variation on that theme which is a new one on me.

Munged icons

Yes, it munged the Quick Launch icons!

(In case you're wondering: No, none of those icons match the programs they're connected to.)

No problem, said I. I opened TweakUI and used its "Rebuild Icons" option, confident that everything would now be fine again.

Very munged icons

Instead, I got this. Now all but one of the icons is invisible!

More "Rebuild Icons" attempts caused the single still-visible icon to change, and more and more icons on the desktop to disappear.

Well played, Windows! Well played!