AVR Classic and third-party controls

ASNA Visual RPG (AVR) Classic is a COM-based Visual RPG development environment. Version 1.0 was released in 1994. There are currently three primary versions still in use today:

• AVR Classic 4.x was retired in 2019. It is not supported on Windows 8 or 10.
• AVR Classic 5.0 , introduced in 2012, was a port of the AVR 4.x product to a much newer Microsoft C++ compiler. Using this newer compiler enabled AVR 5.0 to run on Windows 8 and 10.
• AVR Classic 5.1 , introduced in 2019, uses an even newer version of the Microsoft C++ compiler to help ensure ongoing interoperability with later versions of Windows 8 and 10.

Both AVR 5.0 and 5.1 are direct ports of AVR 4.x and don’t introduce any new language features. They exist solely to provide support for Windows 8 and 10.

When it was originally released, AVR 5.0 also supported Windows 7. However, Microsoft ended support for WIndows 7 on January 20th, 2020 and we are no longer able to test products on WIndows 7; therefore Windows 7 is no longer supported by current ASNA products (including AVR 5.0 or 5.1).

Although AVR 4.x doesn’t support Windows 8/10, we know that some customers do use AVR 4.x on Windows 8/10. Our testing shows AVR 4.0 works only intermittently on these newer Windows platforms. We have seen an AVR 4.x program work fine on one Windows 10 box and fail on another.

We once had a very good customer get exceedingly frustrated with us because AVR 4.0 was working on his users Windows 10 PCs and he thought we were just being difficult by not supporting AVR 4.x on Windows 8/10. We aren’t trying to be difficult, we do know it works on some customers’ PCs. We also know that it doesn’t work on some customers’ PCs.

From godsend to Achilles’ Heel

Microsoft’s Visual Basic 1.0 was first released in 1991. While VB was first dismissed as a “toy” language by many (and, indeed, that criticism may have been warranted because VB 1.0 didn’t natively have any database support!) by the time VB 3.0 was released in 1993 the enterprise was starting to take Visual Basic seriously. One of the major reasons that VB was successful was because of its support for third-party controls. It didn’t take long for an entire new cottage industry of control vendors, from big companies to mom and pop shops to appear.

Here is a great story about how Bill Gates insisted that VB 1.0 not be released without support for third-party controls.

By the time AVR 4.0 was released, AVR supported nearly all third-party OCX and ActiveX controls originally intended for VB. Like VB programmers, AVR programmers quickly embraced third-party controls. Tabs, masked input, collapsible treeviews, and a zillion other cool features were implemented with custom controls. These controls added not only important features, but also added a professional polish to the user interface. If you were around back then you’ll remember control vendor names such as Bcubed, Crescent, FarPoint, Larcom and Young, Mabry, Sheridan, Vantage Point. These vendors are all gone now.

Alas, while these third-party controls enabled great AVR applications in the 1990s and early 2000s, third-party controls are often the Achilles Heal of these COM applications today. ASNA invested heavily in AVR 5.x to ensure Windows 8/10 64-bit interoperability. However, virtually all third-party COM vendors have disappeared and those old COM control binaries used today are exactly the same binaries used back in the day with 16/32-bit Windows 95 and Windows XP. And while Microsoft certainly hasn’t gone out of business, it has for all intents and purposes divested itself of the COM business. Which means that most of Microsoft’s old COM controls are as troublesome as any obsolete third-party vendor’s conrols.

Control inconsistencies

There are some known, consistent trouble-maker COM controls for AVR. For example, we’ve not heard of anyone successfully using the Larcom and Young resizing control–and for many the FarPoint tab control is troublesome (especially with licensing). However, many controls offer inconsistent behavior. Support for many of them can vary from one Windows 10 PC to the next. What works on one PC may not work on another PC.

Another issue we see every couple of months is a customer who has lost a third-party control license. In this case, while the control may indeed be working well on Windows 10, it won’t work on a new PC without a license. With the vendors all gone, these licenses are virtually impossible to get.

Part of this problem may be that there isn’t really such a thing as a standard Windows 10 PC. Since its introduction in 2015, Windows 10 has had several major updates. By saying that “Windows 10 is the last version of Windows,” Microsoft was really saying, “You’ll occasionally get what amounts to new Windows versions until hell freezes over through our recurring update process.” (Windows 10 v2004, from May 2020, was a major Windows update.) Or maybe,¯\ (ツ) /¯, that isn’t part of the problem! All we really know is that some COM controls exhibit inconsistent and unreliable behavior across seemingly similar Windows 10 PCs.

To see what Windows 10 version you’re using, press “Windows key” + R and then type winver in the input field shown. A small dialog displays your Windows version.

These control issues also apply to the graph control that originally shipped with AVR Classic. The vendor who provided this control to us has been out of business for a very long time. The control is no longer supported in AVR Classic — it is known to cause intermittent issues on Windows 10 and 11. See this page for more information about COM controls and AVR Classic.

A real-world example

It’s challenging to get a repeatable example of this COM control inconsistency. However, a good example landed on my desk the other day.

Back in late 90s, Microsoft released the Visual Basic 6.0 Common Controls in a file named mscomctl.ocx. Enterprising AVR programmers quickly realized that this control, although intended to be used exclusively with Visual Basic and MS Office products, worked pretty well with AVR Classic. And the price was right–it was a freely available download (the legalese fine print said something about using this control with only Visual Basic, but I don’t think anyone ever paid any attention to that little detail!). This file provided an interesting set of controls including (among others) buttons, a list view, a treeview and a progress bar.

The other day, ASNA customer Ron Katz was setting up a new Windows 10 dev box and reported getting this error with one of his AVR Classic apps that uses mscomctl.ocx :

Figure 1. mscomctl.ocx “license information” not found error

This is a perplexing error for the mscomctl.ocx file because it is a freely available file and, at least as far as both of us remembered never needed licensing before.

I tested the mscomctn.ocx on two Windows 10 boxes, one version 1607 (effectively a 2016 version of Windows) and one version 2004 (effectively a 2020 version of Windows). The mscomctl.ocx file worked on both of them just by registering the control. But it would not work for Ron on his Windows 10 version 2004 PC.

Ron and I both Googled for a while and found that many programmers are apparently having (or had) this issue. Like so many of these old COM issues, many solutions were offered but none of them worked for Ron.

Ron persisted and finally found this link which resolved the licensing error. The page says that this registry key and string value is needed to resolve the licensing issue:

HKEY_CLASSES_ROOT\Licenses\ED4B87C4-9F76-11d1-8BF7-0000F8754DA1 = knlggnmntgggrninthpgmnngrhqhnnjnslsh

Figure 2. Registry key/value Ron used to fix the license error

I later checked both my Windows PCs and both had that key with the value specified. Just for fun, I deleted the registry key on both machines and rebooted them. To my (slight) surprise the AVR 5.0 example using the mscomctl.ocx worked on both Windows 10 boxes without the key . (Nothing really surprises me when it comes to COM controls being weird on Windows 10!)

Some of the pages that Ron and I found said mscomctl.ocx required that VB 6 be installed. Neither Ron nor I had VB 6 installed so that seems to be bogus advice.

The mysteries abound:

• Why did my Windows PCs have the registry key/value and why didn’t Ron’s have it? I checked a Windows PC that I use for email/Teams/admin work (no development tools installed) and it did not have the key–so it seems like something dev-related put the key there at some point.
• If something dev-related added the key, why didn’t Ron’s dev installs (AVR 5.0 and the OCX) add the key?
• Why did both of my Windows versions continue to run the AVR 5.0 example without failure after removing the registry key/value that Ron needed.

What have we learned?

One important thing we learned is that if mscomctl.ocx gives you a licensing error, before you do anything add the registry key above, reboot, and keep your fingers crossed!

We were also reminded that COM components on Windows 10 are not an exact science. Intermittent errors drive a programmer nuts! We like to live in a binary world where something either works or it doesn’t–on a known and ongoing basis. As we’ve seen here, COM components aren’t binary–sometimes they work sometimes they don’t. This Chuck Berry chestnut sums it up well.

AVR Classic customers

• If you’re still using AVR 4.1 or lower, start now to chart your course to upgrade to AVR 5.1. This involves recompiling your programs and redeploying a new runtime, but it doesn’t require any code changes. A planned, methodical upgrade to AVR 5.1 does require effort, but not as much a panic-driven upgrade because AVR 4.x stopped working on a new Windows 10 version.
• If you’re using AVR 5.0, start now to chart your course to upgrade to AVR 5.1. This isn’t the “gotta move” upgrade that 4.x to 5.x, but you should have it on your radar and do it within the next 18 months or so.
• Take an inventory of every third-party control you use. It’s quite nearly folly to suggest you try to remove them, but if there are any you can remove, we suggest that. Also, be sure to keep track of your third-party control licenses. Make sure you understand how they are licensed and if the licenses will move successfully to new PCs.
• Don’t start using any additional third-party controls. Don’t make your hole deeper than it already is.
• Test AVR Classic deployments on new PCs and Windows upgrades very carefully.
• Take a more active awareness of Windows updates, what versions of Windows 10 you have deployed, and carefully manage upgrades to major new Windows 10 versions. This is a helpful article about Windows updates.
• Please remember than when a third-party control misbehaves, that is unlikely to be AVR Classic’s fault (especially if the control has been working fine for years and all of a sudden goes haywire) and there isn’t much we can do about it. We’ll do our best to help, but there is usually not much we can do.