Archive for April, 2007

Window- and Console-Friendly Win32 Applications

[This entry was updated on May 2, 2007 with additional information about limitations of this technique when used with the DOS shell, as noted in the comments. –Oliver]

It’s sometimes handy to create an application that can run either with a GUI or, if started from the command line, a command line UI. For example, you might want an installer to work this way so that it can support both GUI-driven and “silent” (command-line) installations. Windows provides a simple but not necessarily obvious way to create these dual-mode applications.

Most Windows applications run on the windows subsystem. These applications can try to write to the console, but they aren’t attached to one by default. Using this method your GUI will work just fine but any command line output will be discarded.

An application can be run on a different subsystem, of which “console” is one choice, by setting the /subsystem flag of the linker. When these applications are run they are attached to the console, and they can also open new windows. The catch is that Windows will make sure there is always a console present. If the program is run by, say, double-clicking it in Explorer then Windows will first create a new black-and-white console window, attach the application to it, and then launch the application. The application can close the console window, but not before it’s been seen by the user.

Here’s an approach that does work: Create a windows subsystem application and call AttachConsole(). If run from the Explorer there’s no console to attach to, but that’s ok–you weren’t going to use it, anyway. If your application is run from the command line then this call will attach your application to that same console–which is exactly what you want.

This technique works when running the application from bash and similar shells, from Ant scripts, and so on. However, it does not work with the DOS shell because the DOS shell will not wait for any GUI (Windows subsytem) application. You can work around this in the DOS shell using the /wait option to the start command, like so:

c:> start /wait dualmode.exe

Apollo Alpha Released

The Apollo Alpha has been released! Old news now, but nonetheless the news with which I was planning to start this blog. Due to various unanticipated technical difficulties, the blog entry took somewhat longer to get out the door. (Better this than the other way around.)

A quick word about the alpha: Traditionally, an alpha release has been one which is feature complete but buggy. This terminology derives from the original IBM hardware design process with steps A, B, and C. [1]

The Apollo alpha is not an alpha in this sense. We are actually using an iterative development process. The alpha release is our fourth iteration. As the first to go public, marketing decided the “alpha” label was most appropriate.

So our alpha is not feature complete, and you can expect to see more features before 1.0 is done. On other hand, some of the features in the alpha have been through several iterations, should be fairly solid, and won’t get too much more attention before 1.0. The filesystem API comes to mind.

Trivia note: The namespace in the application descriptor file is based on our internal iterations. You can tell that the alpha is our fourth iteration by noting that the namespace ends in “M3″–yes, we started at zero.

[1] Lohr, Steve. Go To. Basic Books, 2001. p 53.