Current version

v1.10.4 (stable)


Main page
Archived news
Plugin SDK
Knowledge base
Contact info
Other projects



« April 2021
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  


01 Dec - 31 Dec 2013
01 Oct - 31 Oct 2013
01 Aug - 31 Aug 2013
01 May - 31 May 2013
01 Mar - 31 Mar 2013
01 Feb - 29 Feb 2013
01 Dec - 31 Dec 2012
01 Nov - 30 Nov 2012
01 Oct - 31 Oct 2012
01 Sep - 30 Sep 2012
01 Aug - 31 Aug 2012
01 June - 30 June 2012
01 May - 31 May 2012
01 Apr - 30 Apr 2012
01 Dec - 31 Dec 2011
01 Nov - 30 Nov 2011
01 Oct - 31 Oct 2011
01 Sep - 30 Sep 2011
01 Aug - 31 Aug 2011
01 Jul - 31 Jul 2011
01 June - 30 June 2011
01 May - 31 May 2011
01 Apr - 30 Apr 2011
01 Mar - 31 Mar 2011
01 Feb - 29 Feb 2011
01 Jan - 31 Jan 2011
01 Dec - 31 Dec 2010
01 Nov - 30 Nov 2010
01 Oct - 31 Oct 2010
01 Sep - 30 Sep 2010
01 Aug - 31 Aug 2010
01 Jul - 31 Jul 2010
01 June - 30 June 2010
01 May - 31 May 2010
01 Apr - 30 Apr 2010
01 Mar - 31 Mar 2010
01 Feb - 29 Feb 2010
01 Jan - 31 Jan 2010
01 Dec - 31 Dec 2009
01 Nov - 30 Nov 2009
01 Oct - 31 Oct 2009
01 Sep - 30 Sep 2009
01 Aug - 31 Aug 2009
01 Jul - 31 Jul 2009
01 June - 30 June 2009
01 May - 31 May 2009
01 Apr - 30 Apr 2009
01 Mar - 31 Mar 2009
01 Feb - 29 Feb 2009
01 Jan - 31 Jan 2009
01 Dec - 31 Dec 2008
01 Nov - 30 Nov 2008
01 Oct - 31 Oct 2008
01 Sep - 30 Sep 2008
01 Aug - 31 Aug 2008
01 Jul - 31 Jul 2008
01 June - 30 June 2008
01 May - 31 May 2008
01 Apr - 30 Apr 2008
01 Mar - 31 Mar 2008
01 Feb - 29 Feb 2008
01 Jan - 31 Jan 2008
01 Dec - 31 Dec 2007
01 Nov - 30 Nov 2007
01 Oct - 31 Oct 2007
01 Sep - 30 Sep 2007
01 Aug - 31 Aug 2007
01 Jul - 31 Jul 2007
01 June - 30 June 2007
01 May - 31 May 2007
01 Apr - 30 Apr 2007
01 Mar - 31 Mar 2007
01 Feb - 29 Feb 2007
01 Jan - 31 Jan 2007
01 Dec - 31 Dec 2006
01 Nov - 30 Nov 2006
01 Oct - 31 Oct 2006
01 Sep - 30 Sep 2006
01 Aug - 31 Aug 2006
01 Jul - 31 Jul 2006
01 June - 30 June 2006
01 May - 31 May 2006
01 Apr - 30 Apr 2006
01 Mar - 31 Mar 2006
01 Feb - 29 Feb 2006
01 Jan - 31 Jan 2006
01 Dec - 31 Dec 2005
01 Nov - 30 Nov 2005
01 Oct - 31 Oct 2005
01 Sep - 30 Sep 2005
01 Aug - 31 Aug 2005
01 Jul - 31 Jul 2005
01 June - 30 June 2005
01 May - 31 May 2005
01 Apr - 30 Apr 2005
01 Mar - 31 Mar 2005
01 Feb - 29 Feb 2005
01 Jan - 31 Jan 2005
01 Dec - 31 Dec 2004
01 Nov - 30 Nov 2004
01 Oct - 31 Oct 2004
01 Sep - 30 Sep 2004
01 Aug - 31 Aug 2004


Powered by Pivot  
XML: RSS feed 
XML: Atom feed 

§ Does everything need to auto-update?

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....)

§ The annoying hidden current directory lock

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:

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....)

§ Making help files

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:

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....)

§ An absolutely brilliant way to make sure buggy programs don't get fixed

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):

[Program Compatibility Assistant]

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....)