The Elusive Control Spy Utility is a WIN32 Programmers Friend.
Control Spy is a unique set of examples of how the common controls work when writing software using the WIN32 API. The last version I personally downloaded was the 2.0 version, but it appears that Microsoft no longer supports it and the download links on their MSDN website are dead links.
Likely because most programmers today write .NET or UWP apps, WIN32 is out of fashion so it probably is not on Microsoft’s top ten list to keep up with WIN32 utilities like Control Spy. Maybe it is simply an oversight and somebody forgot to update Control Spy on MSDN, but no matter, the problem here is how does one find a copy?
Doing a Google search didn’t come up with much either and personally I am suspicious of downloading an EXE from some unknown website, but fortunately I did find something which can be downloaded from Microsoft’s website.
For programmers interested in dabbling with the WIN32 and the common controls, the Control Spy utility is a must have.
Where Can I Download Control Spy?
Fortunately, a series of legacy articles from the 1998 Microsoft Systems Journal are archived on MSDN and each article has a slightly different version of the Control Spy examples. Control Spy has a unique EXE for each control type. The nice thing about this download is that the last one (only one I tried) includes the source code for each example of Control Spy. Here are the three Microsoft Systems Journal article links:
The articles are a good resource for learning how to get the most out of Control Spy and each article has a unique download, obviously the latest version at the time of each article.
Why Use Control Spy?
Windows (WIN32) is a message based operating system. Events are generated by the sending of messages to a window procedure for each window class. Now when a window class (in this case controls) needs to tell the app something, it sends a message to its parent window via a notification message. The two most common are WM_COMMAND and WM_NOTIFY. The common controls use the WM_NOTIFY notification message mostly and Control Spy allows you to see those messages occur in real time. Normal window messages sent to the controls themselves are not accessible without help, since the window procedure for each control class is in the operating system and not in your code. By using subclassing, one can get access to those window messages and the Control Spy apps do this so you can see such window messages sent to the control in real time.
Also communication with the Common controls is done by sending messages unique to that specific control (window class) using the SendMessage API function and the Control Spy apps let you send such messages to the control. Having the source code in these downloads makes it really valuable for those learning WIN32 programming.
Why WIN32 Programming ?
Two words, smaller, faster. Yes, if you want to write smaller and faster native Windows apps, then the WIN32 is the way to go. If you are writing software for Windows Embedded, then WIN32 programming is the way to go. There is no reason why IOT could not be done using Windows Embedded with minimal hardware resources and writing tiny apps using the WIN32 API.
When Windows XP was the current version of Windows, I was writing my software on a Windows 95 PC with a 233 MHz CPU and only 256 meg ram, just so I could see if my apps were running at peak performance. When Windows 7 and 8 were current, I switched to a Windows XP computer which was a simple mass market PC (EMachine), nothing fancy. I had PCs which had current versions of Windows, but I purposely developed on older machines and then tested my software on the newer computers afterwards. Why?
It allowed me to see the bottlenecks in my software and if they ran fast on the older computers, I had little doubt they would fly on newer ones. While most mainstream developers today would not think of developing on anything less than say a core i7 PC with 16 GIG RAM, a WIN32 programmer can write on a 10 year old mass market PC with just a simple code editor/compiler.
Native coding is the key to fast, high performance software. If you haven’t seen the following video talk by Herb Sutter, C++ expert, then I strongly encourage you to do so now:
“Why C++ ?” by Herb Sutter
WIN32 Programmers Don’t Need to Write in C++ Only!
I will go beyond Herb Sutter’s talk and suggest trying out using just a good old C compiler, rather than C++. The core WIN32 API is not object oriented, but is procedurally based. While some may think C is out of fashion, embedded programmers likely will appreciate how powerful good old C is for writing software using the good old WIN32 API which produces lean, small and fast software.
Now if C is not to your liking, there are other programming languages one can use, even BASIC. Yes, you heard me right, BASIC. I have been using Powerbasic (the great grand child of Borland International’s famous Turbo Basic) for a good 20 years now and it still amazes me how small and how fast the software I write with it is, using the WIN32 API.
For more on PowerBasic, take a look here.
Powerbasic produces executables on par with any C compiler and unlike classic Visual Basic, it can produce true WIN32 DLLs,as well as EXEs, without any runtimes. WIN32 programming using Powerbasic can run rings around classic Visual Basic, when it comes to app size and performance. Also, since most WIN32 examples are written in C, porting code from pure C to Powerbasic is not that difficult. Powerbasic provides many different data types, supports pointers and data structures and other constructs which make porting from C to BASIC quite doable. If your company is still using classic Visual Basic 6.0, then Powerbasic is a great way to expand upon Visual Basic, by writing DLLs which Visual Basic can access like any other DLL. Powerbasic produces real DLLs just like a C compiler can generate. No runtimes either.
Here is a Code Project article I wrote which demonstrates pure WIN32 programming using Powerbasic:
You can see that it is not that much different than coding in pure C and that the code is quite readable for a WIN32 program. No OOP to get in the way, just pure procedural code.
As an example of the small size and performance of a WIN32 app, here is a simple 2D Sprite example written using the WIN32 API and 100% in Powerbasic:
The source code for the app is included, but it does use a STATIC library (which I also wrote 100% in Powerbasic) for the sprite engine which is not included (that is proprietary). But all of it was written using the WIN32 , even the static library, (or Powerbasic’s easier WIN32 wrappers called Dynamic Dialog Tools). The entire EXE is only 92 KB in size and no runtimes needed (other than the operating system itself). There are no C runtimes, no .NET runtimes, etc.).
The Beauty of the WIN32 API
One of the beautiful features of the WIN32 API is how customizable it is. Rather than being stuck with a fixed user interface library, the WIN32 was designed for customization. The common controls provide support for CustomDraw and a few support Ownerdraw as well. This allows you to custom draw the control so you can make it look any way you like. Some standard controls support Ownerdraw as well. Here are some examples of where I customized controls using either OwnerDraw or CustomDraw:
It is not whether you like my examples above or not, but the point is that I was able to customize the look of the control to whatever I wanted, rather than be limited.
Learning how to write your own custom controls is also an exciting experience and it opens up all sorts of possibilities. My two favorite custom controls which I wrote for my own GUI framework are a 2D Canvas control with a 2D Sprite engine and a 3D Canvas control with a 3D scripting language built in (using OpenGL).
Learning how to write custom controls using the WIN32 is not easy to learn, simply because there are few tutorials about how to do it. I actually only found one book on the subject and it was a 16 bit Windows (Windows 3.1) book, but fortunately the basic concepts have not changed much with 32 bit Windows. The book is:
“Windows Custom Controls”
by William Smith and Robert Ward
Copyright 1993
R & D Publications, Inc.
You may be able to find it used on the web somewhere, but it may be hard to find. If you can find it, it is worth it to get it.
Once I learned the basics, writing custom controls was much easier than I thought. It is not until you dig into the deeper things of the WIN32 that one appreciates how powerful it is.
Pushing the Limits of the WIN32 API, as Well as OpenGL
Spending 20 years working with the WIN32, the one thing which I found most exciting was learning how to push the limits of the Windows WIN32 API. I built my own GUI framework to make life easier, but remember that my framework is 100% WIN32 based (not counting the OpenGL of course). I also learned basic OpenGL 1.0/2.0 and found that it was better suited for a custom control than DirectX, since I could have multiple OpenGL child windows (controls) open at the same time. OpenGL (early versions) is procedural based and it leant well to the procedural style of coding with the WIN32. It also runs really well on Linux using WINE.
The best book I found for OpenGL programming is the “OpenGL Super Bible” by Richard Wright and it can be found on Amazon. There are multiple versions (7 at least):
One of the hardest tasks I learned was how to write a drag and drop engine, like those found in a programmers visual designer. There were no books or online tutorials for this I could find. I spent years figuring it out. I wrote my own custom Drag Handle control and linked it with a subclassing engine I wrote which could take control of any control type put on a form, whether standard system controls, common controls or even custom controls. I implemented a snap to grid as well. Moving multiple controls was one of the tough tasks. I finally designed a system where I could drag and drop hundreds of controls at one time, using a drag rectangle engine. Now this may all sound easy to some today, but using the WIN32 alone, it is not easy at all and few have mastered it. This is one reason why many an indie (independent) programming language developer has failed, because while they could write a compiler (often using open source tools), building a visual drag and drop environment was often beyond them and the attempts made often were very rudimentary at best. In the indie BASIC world, this has often been the case.
Just take a look at early versions of classic Visual Basic (ie. 1.0 or 2.0). The visual designer was extremely limited and it didn’t handle drag and drop of multiple controls very well. The real test of any visual designer is to select a couple hundred controls at one time and try to drag them. Some designers will simply draw each rectangle one at a time and when multiple drag rectangles are displayed at one time it is a mess.
Here is a video of my latest visual designer (it was designed to use an external code editor of the users choice, so only does the visual design stuff and then generates code to an external editor): https://www.youtube.com/watch?v=QfHa-LJVfL8&t=119s
While most programmers today depend upon higher level GUI frameworks, remember than “under the hood” there still exists the WIN32 API which does all the low level stuff for us. The WIN32 API has been labeled by some as the Assembly Language of Windows. The art of WIN32 programming has nearly been lost by most mainstream programmers, but it is a worthwhile technology to learn.
