Anyone else getting a bit annoyed with auto-updates?
For some reason yesterday I had the urge to play Little Big Planet on my PS3, only to find out that I had to download 12 updates for it since I hadn't played it in a long time. I then got so bored waiting for the updates to download and install that I started up the Xbox 360 and earned an achievement in Sam and Max, then started building a railroad in OpenTTD on my laptop before the update finally finished. I suppose it could have been worse and I could have gotten a browser update while going to look up a walkthrough and then asked to install a plugin update, a language update (sans unwanted browser toolbar and caffinated beverage Quick Start), and then forced to leave the laptop on for a bunch of queued updates when I tried to shut down.
The reason for updates is understandable, particularly when network services are involved or when security vulnerabilities are patched. However, it seems like the amount of updating that occurs now is overwhelming. It's getting to the point that you never know when you'll have to postpone what you had planned for an update, but it's almost inevitable that something will do so. Link speed plays a part too... it's OK when the network link is fast, but if it's slow for any reason that 100MB patch suddenly takes an awfully long time to download. And, of course, there's always the risk that you're the one special person who gets broken by the update and has to somehow resurrect the system or program involved. I feel like updates are also sometimes abused in a not-so-subtle way to try to periodically force a program back into the user's view, which doesn't do anything for the average user's perception of a computer as a snarling, angry beast.(Read more....)
I'm one of those people who uses the Command Prompt all of the time on a Windows system, and I frequently run into cases where some program has annoyingly locked a directory and I get "in use by another program" errors trying to remove it.
The usual reason is that some program that I've launched has it locked as its process current directory. Most often it's Notepad, since I launch Notepad all the time to view one-off files or to temporarily record snippets of text. Each Win32 program has a current directory as part of process state, and annoyingly, it keeps a lock on this directory -- which means you can't move or delete it. Usually what I do then is dig out Process Explorer and use its search function to hunt down the offender.
A more subtle cause of this problem is a program in which you've used an Open or Save dialog and have browsed into a directory. The common file dialogs change the process current directory as the user browses the filesystem, and this can also lead to accidentally locking folders. For example, you could open a file through File / Open, thus changing the process current directory to that file's containing folder, and then use drag-and-drop to reopen a different file. However, the drag and drop operation doesn't change the current directory, which still points to and is locking down the old location. This nonintuitive behavior also causes some gotchas for GUI programs:
- Any relative paths lacking a drive specifier need to be used or resolved before the GUI comes up. Otherwise, the user may change the current directory, and then those paths can't be properly resolved anymore.
- Worker threads shouldn't ever use relative paths since the current directory is a per-process and not a per-thread state. (Corollary: A module or library should never attempt to use SetCurrentDirectory to try to resolve relative paths.)
On the bright side, this behavior also has a use: if a program is stuck with an unwanted current directory, you can bring up a file dialog to change it. You do need to either accept the operation or keep the dialog up while you fiddle with the directory, because when you cancel the file dialog it will attempt to restore the original current directory. I've seen some people work around this issue by using an unlocker style program to forcibly close the offending file handle instead, without the program knowing. As a programmer, the thought of a user closing random kernel handles in a program terrifies me, but somehow they manage not to lose all of their work constantly.
For these reasons, my current thinking is that for programs which don't have file UI, it might be a good idea to call SetCurrentDirectory() on startup to change the current directory to a decent default, such as the program EXE directory or the user profile root, to avoid mysteriously locking down a random directory. This also has the benefit of avoiding random surprises if someone accidentally sneaks a relative path into a config file. For programs that do have file UI, it's less clear as doing so might undesirably change the initial file dialog location. The rules for that are somewhat obscure and change with each version of Windows; they are documented under the lpstrInitialDir parameter of the OPENFILENAME Structure.(Read more....)
Want to know why programs aren't well documented? It's because writing documentation sucks, and people don't want to do it. And even when someone does, it doesn't necessarily mean they're good at it, or that they'll keep doing it.
I'm currently using Microsoft Compiled HTML Help as my help format for programs, and I like it. It's way better than the old Rich Text Format (RTF) method of WinHelp, from which I still have nightmares about strikethrough and double underlines, and that slightly scary uses-System-font hotspot editor. What I like most about HTML Help is that it uses HTML, but bundles everything into one file with compression, and puts a desktop-app interface on it, avoiding a messy set of loose HTML files or a crappy browser-based interface. The build process is also surprisingly easy, too: you just take a set of HTML pages and feed it to the compiler, along with project and TOC files. The compiler just takes all of the HTML pages and bundles them up.
For VirtualDub, I use a home-grown HTML template preprocessor that evolved from the one I use to generate my web site. It was born out of my frustration with XSLT, which at the time was just transitioning from draft to final, and wasn't very well documented or debuggable. At one point I tried porting my preprocessor to .NET/C# and real XML/XSLT, but got screwed by three issues:
- Entities/DTDs. XML doesn't understand HTML entities, so you need to provide a DTD. If you just enable DTD support and use the validating reader though, the .NET Framework will happily go and download the XHTML DTD from the W3 every single time, without caching. This drove me nuts; not only is it slow and a bit rude, but I can't imagine why this would be desired behavior. I didn't know how to fix this at the time.
- Namespaces. My preprocessor uses elements in a namespace, but didn't actually declare one, so the XSL processor couldn't ever resolve the names, and I didn't know how to set up a resolver.
- Recursion. I had implemented templates such that they could auto-expand within the output of other templates, but stock XSLT doesn't allow this, because input and result node sets are distinct. You'd have to manually call the child templates, which is verbose.
Thus, I abandoned the idea at the time. For Altirra, though, I decided to try again as I'd learned enough about XSL to actually use it, and I'd hit upon a new idea. Previously, in order to preview the help file, I had to either (a) build the CHM file and load it in the HTML Help viewer, or (b) run the preprocessor and view it in a browser. Both of these workflows suck. The new idea was to use a processing instruction to invoke client-side XSLT in the web browser, and just preview the source .xml file that way. The processor would then just invoke a standalone XSLT engine to generate the intermediate files for the HTML compiler.
After trying this for a bit, I have to say that I really like it. I use CSS a lot more than templating now, so the lack of easy recursion isn't a problem anymore. I can preview the result a lot faster and I can debug the stylesheet in Visual Studio if necessary. (Nothing like adding a template and having all elements in the output vanish.) The main downside is that with XSLT I can't generate multiple pages and TOC entries off of a table like I could before, but that wasn't necessarily a good idea anyway (the interface XML doc files for the VirtualDub Plugin SDK are a big unwieldy mess). On the other hand, XSL has sorting and keying abilities that my preprocessor didn't have, and XPath is a lot more powerful than the simple paths I had before.
The one problem I had remaining after I had everything working apparently well, is that I had written the new preprocessor in C#, in order to use .NET's XML and XSLT engines. That wouldn't be so bad except that everything else I write in native C++, and I try to avoid having mixed solutions to avoid screwing over the Visual Studio Express editions. Even the help files themselves use C++ projects in order to invoke a makefile. What I ended up doing is hack-porting the C# code to C++/CLI so that everything could stay all-C++-projects. I feel a bit dirty, but the program's only a couple of hundred lines, and it works.(Read more....)
I just spent the last hour or so trying to figure out why the newly added 64-bit configuration of my program didn't run, only to discover it was because Visual Studio happily linked in all *.manifest files it found in the project even though I don't see any docs or options mentioning this, and the manifest command line in project settings doesn't show it. Okay, we can deal with that, just set "exclude from build" and hope it works. Run it from the command line, and, yup, it now launches.
Crash. Oh well, the first launch never works anyway, probably a simple 64-bit porting issue. Visual Studio JIT dialog comes up, choose to debug.
To my horror, I then saw this dialog (this is Windows 7, btw):
Uh, WTF? I'm trying to debug the program, why would I want to enable a compatibility mode for it? And where's the cancel button??(Read more....)