One of the things i like to do is to collect older development software, usually from the 90s or early 2000s. This software tends to be focused on desktop application development instead of the more modern focus on web applications (that i personally dislike) and they also tend to be light on resources. So far i have found Visual Basic 4, Visual Basic 5, Borland Delphi 2 (which i also had second hand at the past when it was slightly more relevant, but somehow i lost the CD when i left my parent's place years ago), Borland JBuilder 2 and Borland C++ 5.0. All those have been bought from eBay second hand and usually are in CD only form (with the exception of Visual Basic 5 for which i have the manuals, companion CDs, etc) since this is what most people tend to keep around (well, that and the more complete versions tend to cost a ton more, especially if they are still in shrink-wrap state - also Visual Studio 6 because of VC6 and VB6 which are still be popular, especially VB6, tend to be priced especially high).

These days i managed to grab two new tools: the original Borland C++ Builder and Klik & Play. The former is CD only whereas the latter came with the original (barely used) manual. I will post about K&P at some later point since i am planning on making a clone of it in Lazarus, but for now i will focus on Borland C++ Builder (i will refer to the original version as Borland C++ Builder and modern versions as simply C++ Builder since it got through several hands after Borland).

Borland C++ Builder is a RAD IDE focused on desktop applications for Windows. The original version from 1997 (the one i've got) produces only 32bit executables although modern versions use Clang to produce 64bit executables (the 32bit compiler is still based on the original though). It's interface is made up of a main "toolbar/menu" window which contains the common open, save, etc commands and a component palette that you use to draw the user interface of your programs. In addition a bunch of other helper floating windows are available, usually the Object Inspector which contains the properties and events of the selected component, the Code Editor where you edit the program's source code and the Form Designer which acts as a WYSIWYG editor for the user interface.

The floating windows setup was taken from Delphi, which in turn i suspect took it from Visual Basic 1 (although it wasn't until Visual Basic 2 that a dedicated properties window would be used). I'm not sure if this rabbit hole goes further. Lazarus, the open source, cross platform, almost-Delphi-compatible RAD IDE also uses the same setup. This UI layout is loved by many, me included, although if i have to be honest it can be a bit annoying with modern 1920x1080 and 2560x1440 resulutions having the main windows (menubar, inspector and messages - the latter for Lazarus since it uses a separate message window) spaced out. Modern versions of Delphi and C++ Builder have a "docked" mode which makes the UI work inside a single window (and in fact, the UI is now designed to work like that while the non-docked mode is more of a fallback for people who dislike the docked interface). Lazarus also has a docked mode, although the form designer at the moment is still floating, which makes it unusable.

Borland C++ Builder uses an almost identical interface as the one of Borland Delphi 2, which isn't surprising since the majority of the program was written in Delphi. This preference to Delphi also shows in the C++ language implementation, which has been extended considerably to be compatible with Object Pascal and specifically VCL (Visual Component Library) the application framework that both C++ Builder and Delphi uses and is written in Object Pascal. In my opinion, those extensions feel a bit tacked on and not very well thought out. Some parts seem to use standard C++ features, some parts use macros that resolve to C++ extensions and some parts use those extensions directly - like the __property, __fastcall and __closure keywords that are necessary to use VCL.

Regardless of those issues, Borland C++ Builder is still a C++ compiler (bugs notwithstanding) and as one, it can compile and interface with C and C++ programs and libraries. The original Borland C++ Builder was released before C++98, although it seems to support most of it and comes with an STL implementation (the quality of which i'm not sure about, considering that a single use had the compiler emit warnings about mixing signed and unsigned integers). Still, unlike with Delphi (and sadly Lazarus), it is possible to use a common interface with C/C++ programs (Lazarus has a C header to Free Pascal unit conversion tool, but it is only for C and a bit finicky) and even reuse some libraries (assuming they compile under Borland C++ Builder or under a compiler that can produce OBJ files usable by it). As a quick test, i grabbed an expression parsing library written in C, tried in Borland C++ Builder and the code worked fine.

This C/C++ interoperability makes Borland C++ Builder (and C++ Builder regardless of current owner) a nice solution when you want to create tools for C++ programs quickly. Especially for game development, using C++ Builder for writing the tools can save a ton of time. One of the easiest modding tools - for many players still unsurpassed in terms of ease of use - is the Aurora Toolset from the first Neverwinter Nights.

Aurora Toolset, and the whole engine in fact, was made using C++ Builder. Based on the copyright messade inside the nwn.exe for the runtime library (Borland C++ - Copyright 1999 Inprise Corporation), i guess it was C++ Builder version 4.0 since according to Wikipedia that was the only version released in 1999. The same is true (except perhaps the compiler version) for the next installment - Neverwinter Nights 2. NWN2 and its editor was also written in C++ Builder.

However CodeGear (the Borland spin-off that later was bought from Embarcadero) didn't keep up with standards which made interfacing with existing middleware harder. Today you'll find few libraries to support C++ Builder (whatever works it does by accident) and Embarcadero doesn't help that with their insane prices (1000+ euros for the cheapest version without limitations), not to mention their DRM that has caused people to be kicked out of their IDE (according to messages in their support forum at least).

Before i joined Track7 Games to work on the engine of the Theseis game (a sad tale for another day), the plan was to use C++ Builder to create the tools for the engine. The engine would have to compile under both C++ Builder and Visual C++ (something mandatory since we planned to port the game to XBox 360 and PS3, although the latter was dropped early). By the time i joined, that plan was abandoned (presumably because of C++ Builder's bad C++ support) and the idea was to use the in-game GUI toolkit for the tools (later that was also abandoned since we'd need to add significant functionality to the toolkit and since i was in charge of the tools - and wasn't feeling Neanderthal enough to design user interfaces in code :-P - i decided to interface the engine with Lazarus, which was the method that was used until the end).

A similar path was followed by the Aurora Toolset in CD Projekt RED with the first Witcher game: the engine had to be ported from C++ Builder to Visual Studio and the team build a new editor: D'Jinni.

And of course modern games do not seem to use C++ Builder for making tools either, except maybe some small developers or developers who have left-over tech that they haven't upgrade yet. Which is a pity, since the C++ Builder and Delphi (and of course Lazarus) interface is - in my opinion - the best way to create GUI applications. At least the original interface with the floating windows, i haven't used the newer docked versions much beyond the original Turbo C++ Explorer and Turbo Delphi Explorer that CodeGear released (and the took away) some years ago.

Today a lot of tools are done either using a C++ tookit like MFC, wxWidgets or Qt (in games usually the first two are used due to native controls that tend to interface better with DirectX engines) or in C# and Windows Forms, usually with a Managed C++ interface between the tool side and the engine side. With the exception of WinForms, however, personally i find the approach of using a separate interface designer (or worse, an XML description of the interface) a big step backwards in terms of making user interfaces. WinForms, like C++ Builder, Delphi and Lazarus, allow for a more direct connection between the user interface and the language without unnecessary steps. If you want a button to destroy your entity, you draw that button using the IDE's integrated form designer, double click on it (which creates the handler method and associates it with the click event of the button) and type GEntityManager->DestroyEntity( selectedEntity ); (or the equivalent in your engine) and that is it, ready to be used. With a separate interface designer (in say xWidgets for example) you have to place the button in wxWidgets (and fiddle with the wonky layout managment it has), save the project, export the XRC, declare the control in the C++ header, associate the C++ object with the control using the wxWidgets XRC manager, declare the event handler function in the C++ header, implement it in the C++ source, call Bind or Connect to associate the MSG_BUTTON_CLICKED event with the handler and then write the code. Yeah, not funny. And as far as i know, Qt and GTK+ isn't much better there (the QtCreator IDE might help a bit with that though but i haven't used it personally).

So, to come back to Borland C++ Builder, i tried to install it on my computer, which is a bit on the modern side (Windows 8.1, i7 4770K CPU, 16GB RAM, etc). First i decided to try and install it in a virtual machine just in case something goes horribly wrong, but it installed perfectly fine. After that i decided to try and install it on my machine properly, under Windows 8.1. Which, btw, is 64bit.

And there it failed. The installation program is 16bit. For some reason, it seems that Borland decided in the 90s to save a few KB in the installation program and made it 16bit (no, really, installers used to be 16bit in the 90s because 32bit executables were bigger). However Microsoft didn't provide 16bit support in 64bit Windows (despite it being technically possible, as can be demonstated by Wine which can run 16bit programs under 64bit Linux systems). So i couldn't use the installer.

Fortunately the installer is just a pretty xcopy - all it does is to copy the files from the CD to hard disk (and maybe set up a few registry keys but those aren't necessary, except if you want documentation to work... which is a nice thing, but i'll ignore it for now since the help files open fine after i installed the winhlp32 viewer from Microsoft's site). So i copied the files manually to a directory in my drive and Borland C++ Builder worked perfectly from there.

With a small exception, of course: it looks ugly. You see, the program was released in 1997, before Microsoft added themes in the Windows UI and it doesn't support the themable controls, so it uses the beveled ones from Windows 2000 (something i never understood was why Microsoft didn't add theme support in the controls directly and instead opted to create a separate set of controls).

However despite the lack of themes, it works (and as far as i know, there is a workaround for forcing themes in unthemed programs by adding a special resource in them). And it is a C++ Compiler, which means that C++ stuff should work with it.

So i decided to try and write something C++-y in it and that had to be something that used OpenGL. First i checked if the OpenGL headers were there (since IIRC Borland C++ 5.0 didn't include them, although i might remember wrong) and once i made sure that they were there, i went forth to make a spinning triangle.

In Lazarus to do that is a very simple manner: you make sure that the lazopenglcontext package is installed (it is provided out of the box, but it isn't installed by default) and then you drop the TOpenGLControl component in a form. In code you call its MakeCurrent method, draw OpenGL stuff and then call its SwapBuffers. Simple and neat and because of that (and the utility units i have written over time), i use Lazarus to try ideas in OpenGL.

Borland C++ Builder didn't contain an OpenGL control though and as far as i know, it still doesn't. If you want OpenGL, you have to do it the hard way - create a device context, find the proper pixel format, select it, create the render context, etc. Well, the "hard way" is only about 40 lines of code, but still it is annoying. So i decided to do something about it. Specifically, i decided to make a TOpenGLViewport (not Control, because reasons) for Borland C++ Builder. I'm sure there are tons out there, but i doubt anything works with the first C++ Builder.

And thus i did. I had the control working in a few minutes. And i spent the next few hours trying to figure out why the IDE was freezing when i tried to compile a program using the component placed from the component palette instead of manually via code.

As it turned out (after a ton of trial and error) it was because i used the WM_PAINT message to initialize the OpenGL context (first time the message comes, i initialize the context and then call an OnRender callback that the component user is supposed to handle to do the actual rendering). In the handler, i set the message result to 0 (which says to Windows that i handled the message since i didn't want Windows or C++ Builder to mess with the painting), but i forgot to call ValidateRect on the Window's client area which for some reason causes C++ Builder to hang forever (according to the documentation, Windows would try to repeatedly send WM_PAINT messages until the area was validated, but that didn't seemed to happen). This is a mistake i've done at the past a few times, but that was the first time it caused my IDE to freeze :-P.

And of course once i had the control up and running, the next step was to write a small demo for it.

The initial idea was to just write the demo with a spinning triangle inside an OpenGL control that covered the entire client area of the window. But then what would be the point of making that in Borland C++ Builder? Instead of that, i decided to place a few controls that would, well, control :-P the rendering of a few spheres. I spent a bit of time getting the lighting right (not that i had any particular "right" in mind, of course). I wanted some rim lighting effect, which was done by using four directional lights that were pointing at the back of the spheres with slightly offseted directions. Then a couple of extra directional lights, one for the primary "sun" light and one for the back light. But as is usually the case, i got bored after a while and stopped before figuring out a way to make a more compelling background. In any case, the demo was ready.

While i was writing this post (which already took me by itself a few hours), i decided to try and see if the control works under the latest version of C++ Builder, Embarcadero C++ Builder XE7. Embarcadero offers 30 day trials (otherwise there wasn't a chance i would try it - the Professional license costs €1278 and the only cheaper solution, at €257, forbids its use if you make more than $1000 per year) so i downloaded one and started installing it. After about 40 to 50 minutes of waiting (well, i was writing this actually), the installation finished and i was able to... do nothing because the DRM was failing since i had no network enabled. Enabling it didn't help much, though, since it seems like between Borland C++ Builder 1 and Embarcadero C++ Builder XE7 something changed in the program and the component wouldn't compile. I had to replace all headers from <vcl\blah... to <blah...., do some typecasts since HANDLE wasn't the same anymore and a couple of other changes. The component now compiled and i was able to create a package with it (apparently it is needed now), but it wasn't showing up in the component palette. More than that, the project format had changed and the old one (which used a .mak extension - it was a "simple" makefile) wasn't even recognized. I created a new VCL project, copied the files from the example but -expectedly- the opening it would show an error about the missing TOpenGLViewport component. At the end i didn't manage to make it work. I could probably make it by making a new component and then copying the files over, but at that point i lost interest.

And... hell... what did they do to C++ Builder?

The program is a bloated mess with a very user hostile UI that has a ton of buttons, menus, panels, icons... i suppose they had somehow to explain the ridiculous prices :-/

Btw, you can download the Borland C++ Builder TOpenGLViewport control from here.