Table of Contents
Tip #2: Handling Old RTL
The new Windows 64-bit Modern C++ toolchain is standards-compliant (and very good at compiling massive, difficult libraries!)
Background: New RTL, Old Turbo C
When we worked on the upgrade, we made a number of choices about technologies. Two of those were to do with the runtime library (RTL) that the new toolchain uses. The RTL is what provides the underlying code for most other code, and there are two of them: the C RTL provides standard C functions (things like printf), and the C++ RTL provides things like C++ exception handling.
(On top of that go the STL, the standard library of containers and algorithms, and your own code, and both of those use all the methods and features that the RTL(s) provide. You can view the RTL(s) as providing the often overlooked but foundation code that an app relies on.)
Our old toolchains had custom RTLs, and we had to decide: use these, or use something new?
For the C RTL, we used the fact that Windows ships one by default, the UCRT. Why have a custom one when you can use the system-provided standard RTL? It’s there, it’s safe, secure, updated as a system component, we don’t have to maintain it, you don’t have to worry about it because it’s built in, and almost every app uses it.
Note: out of scope for this tip, but hey! This C RTL, a Windows component, was written by Microsoft. Sometimes for a few obscure C methods they reversed the order of parameters. Keep an eye out in case you have very low level C code and google the method or compare the declaration vs your parameters.
For the C++ RTL, we built a new one based on open source code and code we wrote ourselves. This meant we solved a lot of issues in our old toolchain’s runtime library, and is one reason why our exception handling is so good in the new toolchain (we rewrote it anew, with thousands more tests, but the choices we made allowed us to do that writing anew. It was the right thing to do.)
But here’s the key part: our old RTLs, both C and C++, have their heritage in the old Turbo C and Turbo C++ products from the late eighties and nineties. Obviously, reworked massively over that time, but we’ve never deleted types and methods. And in those long-ago days, before C++ was standardised, we had custom types and methods that were not standard C++ (there was no such thing) but that, of course, customer code used. Those non-standard methods are not in the new RTL.
There is a chance that if you have a very old codebase, you may be using some of those methods.
Impact
We did not know how much code is out there using these pre-standardised methods from the late 80s / early 90s. It’s likely you don’t either, because until now that code just worked if you recompiled and you may not have known it was even there if you never looked at it.
Luckily, in practice, we’ve seen very, very few reports of this in the wild. The single most common missing method has three examples of people finding it that I know of, and it is trivial for those three people to fix. Three is not very many out of the number of C++ customers who have upgraded!
But, you might have old code, and you might be worried. So here’s what to expect and how to fix it.
What You Might See
You would switch over to the new platform, and rebuild. Then, you would get a compiler error about a method not being found.
‘Weird,’ you’d say, ‘That worked in the old one.’ You might switch back (it’s a double-click in the Projects view and this version ships both side by side precisely so you can toggle easily like this) and verify: ‘Yep. Works there.’
At this point you would likely google ‘C++ [methodname] and you would see that you get results for something not quite the same but similar:
And that is a hint that it’s a non-standardised C++ method from before C++ had official versions.
Fixing
Luckily every case we know of is easy to fix. These methods existed because there were no standard methods at the time, but when C++ was standardised it created versions of all these methods.
Here, the same search is telling you the answer (and some googling shows the same thing.) randomize() inits the random number generator, but where it’s used, random(max) can be replaced with std::rand() % max. (Check your code that this is right for you.)
Let us know if you see anything like this (support ticket if it causes you any trouble, or bug report if not). We have seen very few people with any code still using these methods, but we don’t know if that’s because most code has been upgraded and revised enough times these old methods have been removed, or if the people upgrading are finding it so easy to replace them that they aren’t reporting it to us.
We are considering making a ‘shim’ library to help upgrading by making versions of these old RTL areas available, but we honestly don’t know from the small volume of reports here compared to the number of upgrades if it’s worthwhile. We’d love to hear what you encounter. We can help. Plus, remember, we want you to succeed with the new toolchain so please get in touch.
In fact, that’s the real tip. Not that you might encounter something when upgrading: that we want to hear about it, and we want you to succeed. So in the chance your code sees this, get in touch!