At the weekly IRC meeetings of the ##copyfree channel, Eitan Adler has been bugging encouraging us to assume maintainership of unmaintained FreeBSD ports. He provided the following script to list any ports that are installed on your system that have no maintainer:

#!/bin/sh
cd /usr/ports;
grep -F "$(for o in $(pkg_info -qao) ; \
    do
	echo "|/usr/ports/${o}|" ;
    done);" $(make -V INDEXFILE) | \
    grep -i \|ports@freebsd.org\| | cut -f 2 -d \|

In the list of 60 such ports on my system I happened to notice “games/sudoku” — a nice little curses console-based version of Sudoku that I play from time to time. The responsiveness of its keyboard interface makes me like it even better than my own Javascript version. I decided to adopt this little orphaned gem.

As soon as I attempted ‘port test’, however, I found that not only was this port an orphan, it was scheduled for execution! It was marked “deprecated” because no more distfiles were available. Apparently, the author’s site went 404. Yet, I obviously had it installed on my system. But did I still have the sources? Most of the time, a port’s “work” directory gets cleaned after installing or upgrading, and I periodically purge my /usr/ports/distfiles directory, too. How long had it been?

Unbelievably, I still had the tarball for sudoku in my /usr/ports/distfiles. I told Eitan I would host it myself, and he walked me through the changes I should make to the port and submit as a PR. The FreeBSD ports team approved the PR, and now I’m both the upstream and port maintainer for games/sudoku.

When I get some time, I plan to fully grok the code for this project, then look at enhancing it. For one thing, I’d like to keep some sort of score. With that in mind, I’ve put the sources into Bitbucket. You can download it from there, or via the tarball, or simply install the FreeBSD port.

Michael Kennett, the original author, released this source into the public domain in 2005. After I modify the code, I’ll release my version under the OWL, as usual.

Since the last time I wrote here about the pcpustat utility:

• I submitted it as a FreeBSD port, and got it accepted.
• I submitted its license (the OWL) to the FreeBSD license makefile, which was also committed.
• I updated pcpustat to version 1.4 and submitted a patch to the port, which “sunpoet” committed in record time (less than 21 minutes!)

Version 1.4 includes a new option, -d (–delim) that allows you to specify a delimiter between columns of output. The default behavior remains the same: the columns will be right-justified with spaces. But if you specify a delimiter, no justification occurs. The delimiter can be one or more characters, and you can get special characters past the shell by enclosing the string in quotes.

Thus, you can take the usual:

$ pcpustat
               cpu 0               cpu 1               cpu 2               cpu 3
  us  ni  sy  in  id  us  ni  sy  in  id  us  ni  sy  in  id  us  ni  sy  in  id
   2   0   1   0  98   0   0   2   0  98   1   0   2   0  98   0   0   5   0  95

and change it, for instance, into a CSV format:

$ pcpustat -d ,
cpu 0,,,,,cpu 1,,,,,cpu 2,,,,,cpu 3,,,,
us,ni,sy,in,id,us,ni,sy,in,id,us,ni,sy,in,id,us,ni,sy,in,id
0,0,4,0,96,1,0,2,0,98,2,0,2,0,97,0,0,1,0,99

Or, make a nice, compact string of “percent used” for a status bar:

$ pcpustat -xiqd :
4:1:5:2

If you’re on FreeBSD, you can just install or update the port. Or:

Now that I’ve been using XMonad as my window manager on FreeBSD for a while, I find that when I have to work on Windows one of the more painful aspects thereof is, ironically, window management. I spend way too much time hunting for the right window or arranging windows so I can clearly see all the ones I need at once. Windows Vista and 7 have the ability to view windows side-by-side or stacked, but that’s not adequate to my needs and it virtually requires using the mouse. I desperately want an automatic tiling window manager like XMonad.

So, I created the next best thing: a command-line utility that will arrange all the windows in a tiled fashion, according to a pattern specified per monitor. In the download below you will find all the sources, plus in the Release subdirectory I’ve included an executable built with Visual Studio 2010.

For usage, type ’tile’ at a command prompt without arguments. But, to give you some examples:

tile 1 2

This tiles both the primary and second monitors using a column-based scheme, with no maximum of columns. Each display will be divided into the number of columns needed to hold all of the windows on that monitor.

tile 1:2r 2:3c

This tiles the primary monitor into 2 rows, with each row split as evenly as possible to accomodate all of the windows. Thus, if the primary window contains three windows, the first window will occupy the entire top row, and the second row will be split between the other two windows. On monitor #2, we’ll have three columns — so if we have five windows there, we’ll get one window in the first column and two windows stacked in each of the two remaining columns.

If you specify more rows or columns than there are windows on that monitor, it’s automatically reduced to the number of windows. Tile silently ignores most errors, such as specifying a monitor that doesn’t exist. Tile does not affect windows that are maximized or minimized. In order to be considered within a monitor, at least 10 pixels of the window in both directions must intersect the monitor’s rectangle.

As noted above, all parts of an argument except for the monitor number are optional. If omitted, the max defaults to 99, and row/column defaults to column.

So, now I can choose my optimal layout, put it in a little batch file named ‘t.bat’, and whenever I need my windows to snap into place I can just type ‘t’ at a command prompt.

On my FreeBSD system, I like to keep various statistics displayed in my xmobar at all times. Most of the system statistics that are built into xmobar require the /proc filesystem procfs(5), which isn’t mounted by default in FreeBSD for security reasons. Thus, I have rolled my own pipes to grab this infomation from sysctl(8) and other places. One such statistic that proved difficult was per-CPU usage. The top(1) utility shows this information if you specify the -P option, but you can’t get that output to a pipe in order to filter or reformat it.

After digging around in top’s sources (/usr/src/contrib/top and /usr/src/usr.bin/top), I was able to clone top’s algorithm with an output that mimics iostat(8). Behold:

% pcpustat -c 10
               cpu 0               cpu 1               cpu 2               cpu 3
  us  ni  sy  in  id  us  ni  sy  in  id  us  ni  sy  in  id  us  ni  sy  in  id
  12   1   5   0  83   2   1   3   0  94  79   1   7   1  13   1   0   0   0  99
  46   0   5   0  50   2   0   2   0  97  50   0   2   0  47   1   1   5   0  93
  30   1   5   1  64   3   1   4   0  92  44   0   5   0  51  14   0   5   0  81
   2   2   1   0  95   0   0   6   0  94  92   0   5   0   3   1   1   0   0  98
   6   1   6   0  87   8   2   4   0  87  76   0   8   0  16   1   0   5   0  95
   0   0   6   0  94  33   2   3   0  62  49   0   8   0  44  10   0   2   0  89
   2   1   3   0  94  26   0   5   0  70  69   1   5   0  25   0   0   1   0  99
   2   1   7   0  91  12   1   2   0  85  80   0   5   0  14   2   0   0   0  98
   1   0   6   0  93   7   1   3   0  88  86   1   8   0   5   1   0   1   0  98
  26   1   6   0  68  50   0   4   0  47   8   0   1   1  90  14   0   2   0  84

I have a ‘make buildworld’ in progress, otherwise it would be almost all idle time.

I’ve included options to filter the states and CPUs you want to monitor, as well as to flip the percentages (i.e., not in that state). For example:

pcpustat --not --idle --quiet --wait 2

generates four columns every 2 seconds, representing the overall utilization of each CPU.

Note how I have both long and short forms of each switch. This utility provided a good chance for me to become familiar with the getopt_long(3) function in C. It also serves as a good example of not only how to use it, but also how to provide help for it.

Rather than putting everything into the README, I decided this would be a good opportunity to write my first man(1) page. I’ve included that, and if you want to read it right where it is (after you extract the tarball below or clone the BitBucket Repository), you can use:

man -M project-path/man pcpustat

or copy it to /usr/local/man.

I’m thinking this utility might be a good candidate for my first FreeBSD port. I don’t think it would port well to non-BSD systems, because it makes use of sysctl(3).

UPDATE 2010-09-13: This utility is now available through FreeBSD ports as sysutils/pcpustat. Thanks to pgollucci for committing it!

UPDATE 2010-09-14: Patched for a flaw in determining buffer size that caused a failure on some systems.

A commenter going by Anonymous Coward (I bet that’s not his real name, and I beg forgiveness if the masculine pronoun doesn’t apply) provided a solution to the double-spaced output problem users occasionally experienced with my tee utility for Windows.

Naturally, this issue occurred because of the inconsistent usage of carriage-returns and linefeeds to terminate lines of text, combined with Console::ReadLine’s interpretation thereof.  The solution, simply enough, was to use BinaryReader for input, and BinaryWriter for output, so no interpretation or translation of the characters would occur.

Like most good programmers, once he had inserted hands in the code, Anonymous Coward couldn’t leave this one alone.  He coded up several more features and emailed them to me.  I made a few corrections and included the new version here.

New features include:

• Duplicated file names are silently ignored, rather than causing a file open conflict.
• /? or –help displays usage information.
• -i or –ignore ignores cancel (Ctrl+C), instead of always ignoring it.
• -f optionally marks the end of switches and interprets all remaining arguments as filenames.

Thanks, Anonymous Coward – whoever you are!

How could something so simple turn into something so complicated?

One of my most popular (perhaps the most popular) post on this site is my tee utility for Windows.  I wrote it back in 2003 using the Visual Studio vintage of the same year.  Rather than including stdio.h and writing it in good old plain vanilla C code, I decided to employ the then-new managed extensions for C++ so it could <scare-quotes> benefit from </scare-quotes> the .NET Framework 1.1.  That’s where my troubles were begotten – but it took a while for them to gestate.

The first problem I encountered was trying to run it from a network share.  Microsoft, in a truly dramatic performance of security theater, decided to treat network shares as “Intranet Zone” and untrusted by default.  Sure, there were ways to establish a trusted zone, but it was a pain to remember.  Thankfully, they’ve solved that one for me.

Then recently, user Alex Armstrong noticed a few anomalies when using tee with ping.  He likes to use ping –t to repeat until interrupted, at which point ping prints out its statistics and then stops.  But when ping was piped to tee, Ctrl+C would interrupt tee instead – which closed the pipe and killed ping before it could relieve itself of its statistics.  Not only that, but since tee’s output files were not flushed, some of the output that had already been displayed on the console would not make it to the file(s).

I tried setting the Console property TreatControlCAsInput to true, but when the input stream is a pipe that caused tee to go into la-la land.  Reading further, I found the CancelKeyPress event – but for some reason I couldn’t get it to compile with the old syntax that I had used back in 2003.  With a little research, I found that the only reason why the compiler was tolerating most of my code was because the project upgrade wizard had added the /clr:oldSyntax switch when upgrading to VS2008.  When I removed that switch, all hell broke loose.  How could they change the syntax for writing managed code in C++ so drastically?  This little utility, which is only about 35 lines of real code, required changes on 15 of those lines.  Yes, they were mostly trivial – but how annoying.  It’s not the same language.  Yes, it’s probably better syntax, but it’s not the same language.

One change I would have liked to make is to use List<T>.ForEach to iterate through the list, rather than a for loop.  But I couldn’t find any way to write the Action code inline until lambdas arrive in VS2010.  Now that’s a syntax change I could get excited about.

Long story short, canceling the CancelKeyPress event (is that a double negative?) worked — Ctrl+C is now seen by ping, which prints out its statistics and closes the pipe, which stops tee normally.  If you should ever need to interrupt tee itself, use Ctrl+Break.

One more thing (as Columbo says) – Alex also noticed that ping’s output is double-spaced when piped through tee.  That’s because ping ends each line with a double carriage-return.  Console::ReadLine treats each of those as a terminator.  I don’t know why the command prompt window doesn’t have an issue with that, but I do.  I can’t just ignore zero-length lines, because then I’d lose spacing from other programs that don’t use a double carriage-return.  Any ideas?  This is supposed to be simple.

An interesting question came up on the Code Project’s Lounge:

I’m trying to work out where to place the asterisk when declaring a pointer variable.
Do you think the asterisk belongs next to the type name or the variable name?

CType* Pointer = NULL;

vs.

CType *Pointer = NULL;

At first I was inclined to favor the first form, because I think of “pointer to” as part of the variable’s type information, rather than part of its name.  In fact, the Windows API is full of typedefs for pointers that allow you to declare them using a single token, like so:

LPSECURITY_ATTRIBUTES lpsa = NULL;    // Pointer to a SECURITY_ATTRIBUTES structure

Unfortunately, this practice hides the fact that C/C++ requires you to apply the * to every pointer variable in a multi-variable declaration.  Thus:

CType* Pointer1, Pointer2;

Doesn’t give you what you might expect, as Pointer2 is now an instance of CType, not a pointer to one.  That’s even less obvious when using one of Microsoft’s pointer typedefs:

LPDWORD pWord1, pWord2;

where pWord2 is actually a DWORD.

The C language treats type and level of indirection as separate concepts.  Thus, it makes sense to separate them syntactically.  But rather than attaching the * sigil to the variable name, perhaps it acts as a better signal that indirection is an independent characteristic of the variable to separate it from both its type and its name:

CType * Pointer = NULL;

Or perhaps the best solution is not to use pointers.

What do you think?

There’s nothing particularly magical about this tip, but its solution stumped me for a while so perhaps it will help out some other poor developer who is madly googling for an answer.

An MFC application needs to determine whether the path entered by a user is a valid folder.  The user already has to be an Administrator, so we don’t care about privileges.  All we want to know is, does this folder exist and is it indeed a folder and not a file or something else?

The MFC Way of doing this is to call CFile::GetStatus on the path, which fills in a CFileStatus structure and returns TRUE or FALSE.  The CFileStatus structure contains an m_attribute member that has bit values for whether its a folder, a file, etc.  This works fine most of the time.  But occasionally, calling it on the root folder of a device (e.g., “C:\”) will return FALSE.  The user reported that it failed only when the application was started from a command prompt instead of the Start menu.  That elicited from me a great big “Huh?”

Digging into it, I found that the problem reproduced when running from some command prompts, but not others.  From a command prompt where it normally failed, it wouldn’t fail if I started Visual Studio from that same prompt to debug it.  Thus, I resorted to the dreaded MessageBox debugging methodology.

I also googled this problem, found that others had run across it as well, but didn’t come up with any good solution.  One commenter suggested using SHGetFileInfo, which seemed to solve the problem until I realized that it also returned normally for folders that don’t exist.

I looked through the MFC sources and found that while the instance method for CFile::GetStatus simply uses GetFileAttributes, the static method that I was using does a FindFirstFile instead.  So I changed my application to call GetFileAttributes directly, and that works exactly as I would have expected.  It returns INVALID_FILE_ATTRIBUTES if the file or folder does not exist, and it returns a bit value that includes FILE_ATTRIBUTE_FOLDER if it is a folder of any kind (including a root folder).

GetFileAttributes provides a better solution anyway.  CFile::GetStatus just adds a bunch of extra code I didn’t need – even if I had used the instance version instead (which probably would also work).  The lesson here is that in an MFC application, it’s not always optimal to cling to MFC methods.  Take the blinders off and use the Win32 API when that provides precisely what you need.

Several years ago, Gary Hart said something that has stuck with me ever since: “just because it’s messy doesn’t mean you don’t want to do it.”  We were discussing plans for driving throughout the UK while there on business — but time and again I find this principle applies to other situations as well.  Besides the obvious, um, recreational possibilities, I can think of many more: eating sloppy sandwiches, parenting, electing public officials, starting a relationship, and coding in PHP.

PHP powers a lot of the web, including such popular frameworks as WordPress, so you really need to have it in your programming portfolio.  But it’s a messy language.   I’m not just talking about the way that PHP tends to sprawl like semicolon-laden vines around your HTML, earning an alternative interpretation of “Page Hacked to Pasta”.  Nor am I referring (this time) to its sucky object model.  The language itself contains many little gotchas and “almost right”s that wait like snares for the feet of the unwary coder.

One I ran into yesterday (not for the first time) is PHP’s partial distinction between false and zero.  In PHP, false is boolean, and zero is numeric.  Fine and good.  But if you treat a zero value as a boolean expression, the zero gets converted to a boolean false.

This seems innocent and helpful enough until you get to a function like strpos, which returns the position of one string within another.  If the target is not found in the source, it returns boolean false.  So, to make sure that one string doesn’t contain another, you’d think you’d do something like this:

if (!strpos($source, $target))

But there’s a problem here.  If $target starts at the beginning of $source, strpos will return 0.  Because it’s in a conditional, that gets converted to boolean false, and the test passes.  So, you need to explicitly test for false instead, right?

if (strpos($source, $target) == false)

Wrong.  Because you’re comparing it against a boolean value, the zero still gets converted to a boolean false.  The only right way to do this is:

if (strpos($source, $target) === false)

The triple equal sign tells PHP to only evaluate to true if both operands have the same type and the same value, so no conversion takes place.  Granted, the PHP docs have a great big warning on strpos to this effect, but the net result is something less than intuitive coding.

Languages like Java and C# solve this problem by not allowing automatic conversion between numeric and boolean values.  That’s sort of like castrating the entire population to prevent birth defects.  So why doesn’t this create problems for other languages?

In Synergy/DE, indices start at 1, so the instr function returns zero for not found:

if (!instr(1,source, target))

Quite logical and linguistically elegant (except for having the starting index as the first parameter), but then you don’t get to have the secret handshake.

Even though Ruby uses a starting index of 0, it prevents confusion in routines like String#index by returning nil instead of a number for not found.  Zero is treated as an object — and thus is not false — while nil does evaluate to false.  Thus,

print "good" if ("abcde".index("a"))
print "bad" if ("abcde".index("f"))

prints “good”, even though the index of “a” within “abcde” is 0.  Why should 0 be false anyway?

In C and C++, indices start at 0, and 0 can be used as a stand-in for false (in fact, all falses are zero), yet I hardly ever make the mistake of “if (strpos(…))” in C.  Why?  Because the documented return value for “target not found” isn’t FALSE, it’s -1.  I immediately know that to test for this return value I must say:

if (strpos(source, target) < 0)

The significance of the result does not rely on a distinction between returned values that can be automatically converted from one to the other.  PHP, on the other hand, requires the programmer to explicitly prevent that conversion from happening.  Automatic conversions are supposed to be a convenience for the programmer, not a trap.

Maybe PHP stands for Purposely Hampers Programming.

The downloadable code below implements a form of text compression that I like to call HACC, for Half ASCII-Compatible Compression (say it fast). Only the low-order 8 bits of a character are used for compression op-codes and length, so it is only half as good as it could be in UNICODE environments. The reason for this half-asciid approach is for compatibility with 8-bit character environments (like ASCII). The compressed data can represent embedded nulls, but it never contains a null character. This also helps when transferring data between environments, but reduces the compression efficiency ever so slightly to allow for the representation of “duplicate 1 null”. Thus, lengths must be stored in a representation that allows for a minimum value of 1, whereas otherwise we could have imposed a minumum compression length of, say, 3, and thus have raised the ceiling on our length by 2 as well.

The compressed data takes the form of a series of (op-code character possibly followed by data). The op-code itself is a number between 1-7, which is stored in the low-order 3 bits (0×07) of the character. Most of the op-codes require a length. If the length is in the range 1-16, then it is stored as 0-15 (reduced by 1) in bits 4-7 (0xF0) of the op-code byte. If the length is in the range 17-4096, then it is reduced by 1 to a 12-bit number (16-4095) and the low-order 4 bits of that number are stored in bits 4-7. Bit 3 (0×08) is set on in that case, and the remaining 8 bits of the length (0x0FF0) are shifted four bits (to 0xFF) and stored in the next character. Any remaining data required for the operation is stored in the characters that follow. The op-codes include “duplicate a character” (with specific op-codes for the more common spaces, zeroes, and nulls) and “copy a string”, each taking a length. Special op-codes mark the beginning and ending of compressed data, so that we can be sure that this is our data when decompressing.

For a C# implementation of this algorithm, which is fully compatible with the 8-bit version (provided a conversion between UNICODE and ASCII), see this topic. For an implementation in Ruby, see this topic.

The downloadable code below contains the source and executable for a simple ‘tee’ utility for Windows. The tee utility faced its first fairway on UNIX platforms, and has been ported to Windows by other providers of UNIX-style utilities. While my version may not be technically on a par with the MKS Toolkit version, mine definitely tops the leader board for price/performance ratio.

Now let’s sink the golfing puns, because the name for the tee utility actually derives from plumbing. Input and output can be ‘piped’ from one process to another on UNIX and on Windows, and the tee utility creates a tee in the pipe. Thus, in addition to sending output to standard out, you can also redirect it to zero or more files — very useful for keeping a log of a process while simultaneously being able to view its progress and/or send its output on to somewhere else. For example:

my100steps.bat | tee my100steps.log

can execute all 100 steps and send the output to the console while at the same time writing the output to my100steps.log.

The version you can download below uses the Microsoft .NET Framework (built using Visual Studio .NET 2008), and provides an example of using managed code in C++. It also demonstrates a few of the capabilites of the System::IO::StreamWriter and System::Console classes.

Jeroen Pluimers converted this to C# so it could run on Windows XP Embedded.

For a version in Ruby, go here. How about a Haskell version?

UPDATE 2009-07-27: Added -a (or –append) option as the first argument only to append files rather than overwriting them. Also changed to a Unicode build under VS 2008.

UPDATE 2009-08-18: Upgraded syntax to eliminate /clr:oldsyntax and added an event handler for CancelKeyPress to ignore Ctrl+C, so the originating program in the pipe can handle it instead.

UPDATE 2010-01-25: Changed to use BinaryReader and BinaryWriter to eliminate CR/LF problems that resulted in double-spacing some forms of output. Thanks to Anonymous Coward for the suggestion below.

UPDATE 2010-01-28: Included more suggestions from Anonymous Coward. Use tee --help to see available options.

Subclassing windows using the Windows Platform SDK directly can be a tricky business. You have to be sure that you follow the rules, and hope and pray that anybody else who is subclassing the window will do likewise. Furthermore, it can be difficult to tie your subclassing code into the rest of your application, because window messages are processed at such a low level. Some languages are not even capable of operating at that level. Even if you are using a low-level language like C, it becomes very difficult to interface events from a subclass procedure without a fairly intimate knowledge of the behavior of the window in question.

ActiveX provides a more uniform and compatible event signaling mechanism. The downloadable code below provides an example (using MFC) of how to subclass a window to fire ActiveX events via a monitor control. The control has a “WindowHandle” property that contains the handle of the window to monitor, which must be in the current process. Setting this property to a non-zero value will initiate monitoring on that window. The first control attached to a window will create a CActivationXSubclassHandler object, which in turn subclasses the window to forward window messages back to itself, via an object pointer stored in the window as a window property. The CActivationXSubclassHandler object also contains a list of the monitor controls attached to the window, so that messages can be forwarded to each one.

The example monitor control class, CActivationXCtrl, only acts on the WM_ACTIVATE message. It fires two events: OnActivate when the window is activated, and OnDeactivate when the window is deactivated. Each event is passed a single parameter, which is the content of the UserData property for the control. Naturally, you can extend the control to monitor and act on whatever messages you need.

In order to facilitate testing and usage, I added two methods to this control. The Activate method will activate a window (the monitored window if no handle is passed). The FindWindow method wraps the Windows Platform SDK function FindWindowEx, and adds the ability to specify process and thread.

Purely for fun, I made the OnDraw method for the control display the incoming window messages and parameters, along with simulated LED’s to represent their binary values.

For a simple example of an application that uses this control, see Launch applications by associated file extension, where the launching application waits for itself to become reactivated before trying to establish focus.

Anyone who has ever programmed Dynamic Data Exchange (DDE) applications has experienced pain. Originally, it was done only with Windows messages and global atoms. Since then, Microsoft has added the Dynamic Data Exchange Management Library (DDEML) which makes the job a little easier — using function calls instead of messages, and data handles instead of global atoms. But it’s still more work than it ought to be, what with transferring data to and from handles — and you still have to provide a callback to process the transactions, much like the message model.

The downloadable code below provides the sources and executable for an ActiveX control that wraps DDEML. ActiveX provides a much cleaner interface in terms of calls in and calls back, and especially for marshalling data. Best of all, any language that supports an ActiveX interface (most these days) can use it. This version only supports poke, execute, and request operations, with data in text format up to 255 characters (the limit of a DDE string handle). However, it could easily be extended to support other formats and operations. Rather than using a single callback for transactions, each transaction type signals an ActiveX event.

The single control can act as both a DDE client and a DDE server. It includes methods for adding and removing supported services and events for servicing transactions as a server. It also includes methods for connecting and disconnecting a conversation, as well as poking, executing, and requesting data within the conversation. No limits are placed on the number of services the control can provide or connect to. Many design decisions were made to keep this example simple. For instance, asynchronous operations are not provided for, nor is there any option to filter transactions. These and others are feature that could be added in the future without affecting the existing interface.

One handy little by-product of this project was the CDDEString class. CDDEString encapsulates a CString (the MFC string wrapper class) and provides operator overloads to convert to and from DDE string handle, VARIANT, and of course LPCTSTR (const char *, which also handles CString).

UPDATE 2009-08-22:  For a .NET solution, I recommend NDde.

When generating XML data, you must be careful not to include special characters that will drive the parsers crazy. These are, as defined in section 2.4 (“Character Data and Markup”) of Extensible Markup Language (XML) 1.0 (Second Edition), “&”, “<", and ">“, which must be replaced by the escape sequences “&”, “<”, and “>”, respectively.

The downloadable code below includes separate examples in Synergy/DE and C++ of how this conversion can be performed. The Synergy/DE version is implemented as a function that converts the string in place. The C++ version implements a class, an instance of which can be assigned a string value that is immediately converted on assignment. An extractor allows the converted string to be retrieved.

The downloadable code below provides the sources to a simple program that sets the Windows desktop wallpaper to a randomly selected bitmap file in the Windows directory. If the image is less than or equal to half the height or width of the screen, then it is tiled. Otherwise, if the ratio of the ratios of height to width for the image and the screen are within 0.20, the image is stretched. Otherwise, it is centered. I have this little program execute every 15 minutes in my Scheduled Tasks, just to make life more interesting.

To download just the executable version of this program, visit http://www.camdensoftware.com/Downloads.htm

The downloadable code below provides the sources to a simple utility called heal.exe. Developers who spend a lot of their time creating graphical applications for Windows often get the desktop into a state where windows are half painted or pieces of now-extinct windows are still lying around. This sometimes happens when applications exit while they have redraw turned off. Running the heal.exe utility calls the Windows API function InvalidateRect with the window handle as NULL, which causes all windows on the desktop and the desktop itself to repaint. You can therefore also use the utility to see if a display anomaly in an application is due to a failure to invalidate a region.

If you just want to get the executable for this utility and don’t care about seeing the admittedly simple but brilliant source code, visit http://www.camdensoftware.com/Downloads.htm