Windows Installer: Modify Config Files


Recently I put together a Windows Installer package (MSI file) for our team to use internally.

The app I was installing writes to temporary storage, and the app stores a reference to the temporary storage folder in AppConfig.xml, which is included in the install manifest. AppConfig.xml contains a folder specifier like this:

<Options>
  <CacheFolder>c:\cache</CacheFolder>
</Options>

The problem I faced was that I wanted to avoid using a hardcoded “c:\cache.” Not every user has a C drive or wants a cache folder at the root. And I didn’t want the user to have to configure this manually. The installer should default to a reasonable location.

Fortunately, WiX handles this sort of thing with aplomb. You can modify the contents of XML files at install time. Perfect!

Here’s how. In the WXS manifest, add an XML setValue action to modify XML contents.

<?define AppConfigFile = "AppConfig.xml" ?>
<?define CacheFolder = "cache" ?>

<DirectoryRef Id="InstallDir">
  <Component Id="Config" Guid="<your-GUID-here>">
    <File Id="Config" Source="$(var.AppConfigFile)" KeyPath="yes"/>
    <util:XmlFile Id="Cache" File=[#MyAppConfig]"
      Action="setValue" ElementPath="//Options/CacheFolder"
      Value="[TempFolder]$(var.CacheFolder)" />
  </Component>
</DirectoryRef>

Here’s what’s happening. You define your file component as normal. After you’ve specified the file information, use the util:XmlFile specifier. XmlFile File points at the actual file by using the # specifier, which resolves to the full install path of AppConfig.xml. Change the XML value of to “%temp%cache”, which resolves to the user’s temporary folder plus “cache,” e.g. “c:\users\pete\AppData\Local\Temp\cache” — just what we want.

To make this all work correctly, there are two more steps. First, ensure your WSX source references the utility extension where util:XmlFile is located.

<?xml version="1.0" encoding="UTF-8"?>
  <Wix xmlns = "http://schemas.microsoft.com/wix/2006/wi"
       xmlns:util = "http://schemas.microsoft.com/wix/UtilExtension">

And second, reference the extension when you compile and link:

candle source.wxs -ext WixUtilExtension.dll
light source.wixobj -ext WixUtilExtension.dll

That’s it. Now the installation modifies the config file so your app automatically caches data to the user’s personalized temporary folder.

Posted in Computers and Internet, Installers, Microsoft, WiX | Tagged , , | Leave a comment

Windows Installer: Shut down System Tray Apps


Recently I put together a Windows Installer package (MSI file) for our team to use internally. The package installs a system tray app (sometimes called a notification app or notification area app). One common property of system tray apps is that they don’t actually close on exit — they simply return to the system tray and continue running in the background.

In order to properly uninstall this component, the app needs to be shut down by the installer/uninstaller. Typically, in WiX, you’d do this with the CloseApplication element, which sends a WM_CLOSE message to the system tray app, which it ignores completely. What to do?

Here was my solution, embedded in the WiX WXS source file (toolset v3.9):

<?define SysTrayAppExe = "mySysTrayApp.exe" ?>

<CustomAction Id="KillApp" Directory="InstallDir" Return="ignore" ExeCommand="&quot;[SystemFolder]taskkill.exe&quot; /F /IM &quot;$(var.SysTrayAppExe)&quot;" />

First, we define a custom action that will execute the taskkill Windows system command. We ignore the return value because we don’t care if the app was actually running. Just in case the Windows system folder has embedded spaces, we wrap the command in quotes using the XML quote specifier. The /F flag requests a forceful termination, and the /IM flag requests that we terminate the specifically named process, which is again wrapped in quotes in case it has embedded spaces.

Next, we set up the custom action to execute in the first phase of the install process. This ensures that the system tray app is always shut down when the install/uninstall begins.

Ideally, we’d use the CAQuietExec special custom action to avoid a command screen from briefly flashing on the screen, but CAQuietExec must be run after the InstallInitialize phase, by which time the Windows Installer has already detected that the system tray app is running, and it’s too late for us to do anything about it.

Posted in Computers and Internet, Installers, Microsoft, WiX | Tagged , , | 2 Comments

VR Toolset


It was fun to compare and contrast the toolset we’re using at HBO for the creation of VR products with what the folks at Oculus Story Studio are using. More similarities than differences. Story Studios’ Dropbox solution as a backup system is rather clever.

Posted in Computers and Internet, Game Programming, VR | Leave a comment

VR: Inside Looking Out


For the past year, I’ve been working on virtual reality projects at HBO. We’ve learned a ton, but there is still so much we don’t know.

Although VR experiences borrow from the language of film and borrow from the language of video games, one of the most important things we’ve learned is that VR is truly a new medium.

With traditional media, you are on the outside looking in. You read a book. You watch a movie. You play a game. The view you have of the book or the film or the game is a window into another world. It may be an immersive experience, but you can easily exit that experience by simply casting your gaze in a different direction.

With virtual reality, you’re on the inside looking out. You can’t look away, because everywhere you turn is part of the experience that’s been created for you.

Perhaps the most apt metaphor is Disneyland rides. When you’re on the Pirates of the Caribbean ride, you are in the center of the experience. The experience surrounds you, engulfs you. Cannons roar. Water sprays. Fires rage. Wenches run. Pirates sing. And you are in the middle of it all. You can’t look away.

The “inside looking out” notion is key to understanding VR. For instance, it’s one of the reasons we no longer talk about having a camera in VR, because the very notion of a camera harkens back to an “outside looking in” perspective, with a window on the world. Instead, we talk about the person in VR — a person who can (and often will) look in every direction, the person who is completely immersed in the experience, and the person who can’t escape the experience without physically removing their headset!

Posted in Computers and Internet, Game Programming, VR | Leave a comment

Package Perfect


Recently I needed to package up an Unreal build for distribution. You can do this from the Unreal Editor v4.6 by selecting File->Package Project. However, I wanted to automatically create packages on a build machine without human intervention. That meant I needed to find a command I could execute in a script. Skipping to the hard won result, here’s the wooly command line I ended up with:

.\Engine\Build\BatchFiles\RunUAT.bat -verbose BuildCookRun -nocompileeditor -nop4 -project=MyProject.uproject -cook -allmaps -CrashReporter -stage -archive -archivedirectory=c:\Package -package -WindowsNoEditor -clientconfig=Shipping -ue4exe=UE4Editor-Cmd.exe -clean -pak -prereqs -targetplatform=Win64 -build -utf8output

Over twenty command line parameters. How did I figure that all out?

First I searched on the web for “Unreal command line package.” That led me to a promising page, so I tried the recommended command line there. However, when I compared my output with the output generated by the in-editor packaging step, not only were most of the files quite different, there were some files that were in one place and not the other. No dice.

Time to think like a software engineer.

Unreal distributes source code for their engine and editor. So I searched the code for the word archivedirectory (one of the parameters mentioned at the link above), which led me to .\Engine\Source\Editor\…\MainFrameActions.cpp. It has a line that starts with

FString CommandLine = ...

Bingo!

I set a breakpoint on that line in Visual Studio, started up the Unreal Editor, attached to the Unreal Editor from Visual Studio (Debug->Attach to Process), and then selected File->Package Project->Win64 in UE. Breakpoint hit! From there it was simple to copy the actual CommandLine value that UE uses to a batch file and tweak path names as needed.

Notes

  • I repeated this process a few times, tweaking the settings at Packaging Project->Packaging Settings so I could extract the various command line parameters that can be configured in the editor.
  • The –project setting must be the fully qualified path name
  • For shipping builds, use –clientconfig=Shipping. For development builds, use –clientconfig=Development. I didn’t try creating a Test build, but that would be an interesting experiment, since you can’t package test builds from inside the editor.
  • clean ensure a full build is done, –build builds code, –cook builds content, and –pak puts the content in a single pak file
  • The only platform I was targeting was 64-bit Windows, so you’ll need to validate the targetplatform parameter for other platforms

 

Posted in C++, Computers and Internet, Game Programming | Leave a comment

Random Fail


One of my common software interview questions involves the creation of a game board. Part of the problem includes the generation of random numbers. If the candidate is writing in C/C++, the typical code I see looks something like this:

srand(seed); // one time seeding of generator
// later on ...
r = (rand() % 6) + 1; // throw the dice

Plenty of people have discussed the drawbacks of rand(), but the interview problem is not focused on the random number generation itself, so I consider the code above reasonable. Recently I had a candidate use JavaScript as their language of choice. The candidate wrote:

r = Math.Floor((Math.Random() * 5) + 1); // [1...6] ?

I’m not a JavaScript expert, but I noticed a couple things right away. First, there appears to be no way to seed the generator, so it’s not reproducible. Second, Math.Random() returns a float in the range [0.0 to 1.0). In other words, the code above will never return the number 6 because Random() never generates a 1.0! Even if Random() returned values in the range [0.0 to 1.0] there would still be a big problem. Random() is a uniform generator, so it only returns precisely 1.0 on very rare occasions. Hence the distribution of numbers will look something like this, which is clearly not random:

Takeaway: getting random numbers correct is a non-trivial problem. A lot of information available on the Internet about generating random numbers is plan wrong. Beware. Test your generators to ensure that they are both random and uniform. If I was writing C++ code today that needed to throw a d6, it would look like this:

#include <random>
std::mt19937 mt(seed); // generation engine
std::uniform_int_distribution<int> ud(1,6); // distribution engine
// later on ...
r = ud(mt); // [1...6], uniformly distributed

For a hilarious 30 min excursion into the pitfalls of C/C++ rand(), see Stephan’s talk: rand Considered Harmful. You’ll never use rand() again.

Posted in C++, Computers and Internet, Game Programming | 1 Comment

A galaxy var, var away


My current project has me writing C# scripts in Unity. Cool. I haven’t written C# for more than a decade. Today I was reviewing code, and noticed this line:

foreach (var child in Children)

Nothing too exciting. Readable. Easy to understand. But as I took a second look, I realized I didn’t truly know what var is all about. Is it defining a variable? What’s the type of child? Could var be replaced with ChildType? What’s best practice? Should I be using var?

Var was introduced in C# v3.0 circa 2007. It turns out it’s the equivalent to auto in C++, which I wrote about not long ago. Var allows the compiler to determine the type automatically.

So, var defines a variable. The type of var is the type that the compiler deduces. Var could be replaced with the actual type, but best practice is to use var whenever you can, just like auto. I’ll be using it regularly from now on.

Var out.

Posted in CSharp, Game Programming | Leave a comment