RAD Basic Blog

The technical details: Part 1

Designing it to achieve full compatibility with Visual Basic 6

Posted by Carles Royan on August 16, 2019

Well, lately I got in touch with some people asking me about this prototype. So, I’ve decided to begin a series of post about the technical details of RAD Basic solution. Here we go with the first part: designing it to achieve full compatibility with VB6.

First of all: define the goal

Before programming a big project as this and before designing it, it is very important to define the goal and stay on target. So, the goal of RAD Basic is: to be a true Visual Basic replacement which has to be 100% compatible. Having this goal in mind, sub-goals and main features have to be defined too. Let's enumerate them and explain deeply later:

  • The compiled result has to be native code as Visual Basic do.
  • The main and first target has to be Windows platform.
  • You have to be able to open your visual basic project (vbp file) and continue working in it without conversions and migrations.
  • Design in three layers: IDE, compiler and runtime libraries.
  • Stick with Visual Basic 6 language for the first version. So, no improvements at language level. At the frontend level of the compiler, the effort has to go in compatibility, not in improvements.
  • As the compiler is written from scratch, there could be some improvements on the backend: x64 support, visual styles for common controls, ...

There are controversial ones, so let me explain the reasons behind this decisions.

Goal: Native code

Managed code are popular. Java, .NET and interpreted languages, like javascript or python, are the most popular in development, as they are listed in top of TIOBE index (August 2019): TIOBE Index.

They have advantages as: automatic memory management, platform-Independent, managed execution, ... But this kind of language have a footprint because they need a VM or a interpreter to run, and in some scenarios could be slower than native code. Also, languages which compiled to native won't be disappear (they are needed for developing the VMs or interpreters). And there are young (native compiled) languages which are becoming stronger and stronger in development community, for example: go(lang), rust, ...

So, although it is not the cool way these days, the decision goes to generate native code, as VB6. In other way, it couldn't be named a "true Visual Basic replacement", because it would lack the native code feature.

Goal: Windows as target platform

Sure, in 2019 cross platform support is important. But Visual Basic was designed for Win32 environment (well Visual Basic 1.0-3.0 for Win16, Visual Basic 4 for Win16/Win32 and VB5/VB6 for Win32 only). And the applications developed with it assumed it will run in Windows OS. So, It's really hard a large VB project will not fail compiling for cross platform. For example, problems will arise with: third party OCXs, Win32 dll imports, hard coded path assuming windows machine (C:\WINDOWS, etc).

Former idea don't significate cross platform has to be avoided. In fact, the RAD Basic design has cross platform design in mind (more about it in further posts). RAD Basic future goals have to be more than compile legacy code. So, It should not be confused the efforts for the first version with the long-term goals for the following versions. But, as it is a big project, these first version efforts have to go in Win32 native code, a true VB replacement (as you see, the main idea which is repeated as a mantra).

Lastly, one more idea about cross platform: a project developed in VB6 should be migrate for a new project type (for example "cross platform RAD Basic executable"), for ensuring there is no Windows particularity. So, for a real cross platform development, it is not only necessary to be supported in compiler/library/framework, also the user code has to be developed with cross platform in mind.

Goal: Working natively with VB files

The first question is: why not?

RAD Basic is a new software developed a lot of years later than Visual Basic. And the format of Visual Basic project files are simple. So, why not continue using it? Maybe, it will come up a new format for RAD Basic project files. But, the development environment has to be able to work with both.

And there are advantages too. The greatest is: this allows you to edit the forms/modules with both: the legacy (VB6) and the new environment (RAD Basic). Mode about it in next goal.

Goal: Design in three layers

This design decision may not seem relevant, but it affects in the compatibility and in the interoperability. These three layers are:

  • IDE: The environment for design the forms and write the code.
  • Compiler: The tool for generating the exe file, which could be distributed.
  • Runtime libraries: libraries for GUI design (creating buttons, text boxes, ...), string manipulation, database access, etc.

Why is so important? Because this three layers are independent and they could be interchangeable. Some examples:

  • Use the VB6 (IDE) for design and write code and compile with RAD Basic (compiler + runtime libraries)
  • Use the RAD Basic (IDE) with the RB compiler but the VB6 Runtime Libraries (in fact, part of them: ActiveX components as COMCTL32.ocx).

Below, more examples showed graphically.

RAD Basic design in three layers interchangeable Examples of the three layers interchangeable.

This interchangeable layers allow a peaceful change from Visual Basic and to verify the behaviour of the new code is the expected. So, the previous goal (working natively with VB files) is essential to be able to exchange the layers.

The efforts for the first version are going to compiler and runtime libraries. Let's going deep about the needs:

  • Compiler: Of course is the core of the project. This new compiler brings total control about the platform and brings compatibility with newer Windows versions, x64 platform, etc.
  • Runtime Libraries: Why reimplement something that is working? Why no use VB RT instead (as core ActiveX present in Windows)? Because we need source code control. So, we can fix bugs and develop new features and improvements. When you develop a new compiler, the runtime library have to be developed along. For example, although C++ is a standard language, every compiler have his runtime library: libstdc++ for GCC, Microsoft Visual C++ runtime library for Visual C++, ...
  • IDE: This is a low priority because the two points above will need a lot of effort. But, it is need for releasing a full stack for developers. In further versions will be improved with features presents in modern IDEs.

Goal: No improvements in VB language (frontend)

As said in previous post, Visual Basic platform could be evolved in a different way. It could be remained as VB6 and adding in newer versions modern language structures like Try...Catch, multithreading, etc. This new features could be optional while "old" structures remain for compatibility.

But, as stated in the beginning of this post: stay on target! The goal is not improve Visual Basic 6 language. The goal is create a 100% compatible VB replacement. So, as the project is very big, all the efforts have to gone in compatibility. Future versions could improving the language with exciting features without losing the BASIC identity.

Goal: Some improvements on the backend

Yup! This goal seems to contradict the previous one. Well, not quite. Although with some difficulties, Visual Basic 6 environment continues working in Windows 10, so it is fine offer something attractive to developers. As the backend is developed from scratch, some improvements could be made: x64 support, visual styles for common controls, ...

This improvements will contribute to modernize the Visual Basic platform towards the RAD Basic platform.

End note

Hey! if you got here, thanks! This post got longer than expected. Although it is named technical details, we didn't get very technical yet. This post was all about design decisions, goals, advantages,... Stablish the stage for further technical posts. So, the further posts in these series will be more about the current implementation.