Read the latest news and views from the OpenCandy team.

CandyPick #1: Rapid Environment Editor, freeware Windows environment variables editor

Welcome to CandyPicks!

CandyPicks are short articles about great pieces of software that are worth trying out. In many cases, like today’s selection, the CandyPick will be an application that solves a specific problem or use-case scenario. CandyPicks articles are intended for anyone, regardless of technical level, that is interested in discovering awesome software.

The Problem

A week ago, my colleague Adrian wrote a CandyWrap article intended primarily for developers about Rundll32.exe and the system PATH environment variable (see Wikipedia for more info about PATH variables). Basically, your system PATH variables are a set of information that tells Windows (in this case) where important system directories are located and are also used to determine how certain processes (or applications) work.

On the surface this may not sound like the type of issue that your average person, or even some power-users, would ever care about… until they try to install a piece of software and it fails for some reason; which is exactly what happened to me recently.

It wasn’t until Adrian asked me to look at my System PATH variable that we discovered the deep dark secret it was hiding; it was missing a reference to the Windows system directory!

Bad System Environment Variables in Windows

How did this happen? Well, because of my days of IT consulting (oh, what fun), I’ve seen instances where installing *certain* third-party software adds a value to the PATH variable and instead of appending to the existing values, wipes them out and leaves its own. This is just plain sloppy programming and bad form, at best. At worst, it is downright ridiculous since it has the *potential* to cause time-consuming headaches down the road.

Continue reading this post…

CandyWrap #1: Process spawning, RunDll32, & the PATH variable

Welcome to CandyWraps!

This is the first in a series of articles intended to help application developers and publishers better understand our system and get the most out of their relationship with OpenCandy.

These posts will serve as our means of sharing the knowledge and experience we’ve gained from building and running OpenCandy products and technologies. This includes everything from PHP and MySQL on the server-side to Win32 APIs and installer platforms on the client-side to designing intuitive product installers and software. The topics covered, amount of detail and level of technicality will vary from post to post and may include everything from general overviews and development-related anecdotes to detailed designs and source code.

The subject of today’s CandyWrap is intended for developers, and is a small but useful tip about executing RunDll32.exe by way of a Windows process.

Very quickly, the tip is: Don’t forget about the PATH environment variable when using Windows process APIs, such as _spawn(). For the details read on…

Say, for example, that you want to call a function that is exported from an unmanaged DLL. The safest way to do so is to use the process APIs provided by Visual Studio’s Runtime libraries, specifically _spawnl().

This is what it looks like:

intptr_t _spawnl(int mode, const char *cmdname, const char *arg0, const char
*arg1, ... const char *argn, NULL );

MSDN _spawn() API reference: http://msdn.microsoft.com/en-us/library/20y988d2(VS.71).aspx

Now, the following example displays a standard Windows message box with the text “HelloWorld!”. It’s done by executing RunDLL32.exe and calling the MessageBoxA function from user32.dll.

intptr_t ret=_spawnlp(_P_NOWAIT, "RunDll32.exe","RunDll32.exe",
"user32.dll,MessageBoxA HelloWorld! ", 0);

The only problem is no message box appears. After monitoring the system you determine the MessageBoxA function isn’t being called so you check the usual suspects:

  • Is the process being spawned?
  • Does RunDll32.exe crash?
  • Is there something wrong with the MessageBoxA function or the way it’s being called?
  • Is there something wrong with the loading of user32.dll? LoadLibrary()fail?

They all look fine, so what could be wrong? Chances are the PATH environment variable doesn’t include a reference to the System32 directory (%SYSTEMROOT%\SYSTEM32), preventing _spawnl() from locating RunDll32.exe!

The lesson? Don’t always expect relative paths to be resolved automatically. In this case, using GetSystemWindowsDirectory() to build an absolute path to RunDll32.exe is well worth the trouble.

That’s it for this CandyWrap. Stay tuned to this channel for more information, tips and hints. See you next time.

Adrian Bourke is a handyman at OpenCandy working on everything. Check out Adrian’s bio.

Creative Commons License
This post is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.