The technical details – Part 1: Designing it to achieve full compatibility with Visual Basic 6
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 designing and programming such a big project as this, it is very important to define the project goals and stay on target. So, the primary goal of RAD Basic is this: to be a true Visual Basic replacement which has to be 100% compatible. Having this goal in mind, other targets and important features have to be defined too. Let’s enumerate them and explain in more depth later:
- The compiled result has to be native code as per Visual Basic 6.
- The main and first target has to be the Windows platform.
- You have to be able to open your visual basic project (vbp file) and continue working in it without the need for conversion and migration.
- A design with three layers those being the IDE, compiler and runtime libraries.
- Full compatibility with Visual Basic 6 language for the first version. This means that initially there will be no improvements at the language level. At the front-end level of the compiler, the effort has to go into achieving compatibility and not attempt enhancements at this early stage.
- As the compiler is being written from scratch there could be some room for improvements on the backend, for example: x64 support, visual styles for common controls &c.
Some of these targets are controversial ones, so let me explain the reasons behind these decisions.
Goal: Native code
They have advantages such as: automatic memory management, platform-Independent, managed execution but this kind of language has an enlarged footprint because they also need a VM or an interpreter in order to run. In some scenarios they will be slower than native code. Also, languages which compile to native won’t disappear as they are needed for developing the VMs or interpreters. In addition, there are young (native compiled) languages which are becoming stronger and more popular within the development community, for example: go(lang), rust &c.
So, although it is not the cool direction these days, the decision has been taken to generate native code, just as per VB6. If any other method was chosen, the result couldn’t be named a “true Visual Basic 6 replacement” because it would lack the essential native code feature.
Goal: Windows as target platform
Of course, in 2019 cross-platform support is important. But Visual Basic was originally designed for the Win32 environment (Visual Basic 1.0-3.0 for Win16, Visual Basic 4 for Win16/Win32 and VB5/VB6 for Win32 only). Every application developed with it assumes it will run in within a Windows compatible OS. It is more or less impossible to make a large VB project compatible with multiple platforms, for example, problems will arise with: third party OCXs, Win32 dll imports and hard-coded paths assuming windows as the platform (C:\WINDOWS, etc).
This inevitable conclusion does not prevent us from achieving cross platform compatibility in the future. In fact, the RAD Basic design has had cross-platform design in mind from the very outset (more about it in further posts). RAD Basic’s future goals have to be more than just compiling legacy code. Do not confuse our goals for building the first version as being the same as our long-term goals for the subsequent versions yet to follow. As RAD Basic is a big project, the efforts for building the first version have to go into a Win32 native code version, this being a true replacement for VB6 (this concept has become our mantra).
Lastly, one more idea about cross platform: a project developed in VB6 should be able to migrate to a new project type (for example “cross platform RAD Basic executable”) that requires no specific Windows functionality. For a real cross platform development, it is not only necessary to be supported within the compiler/library/framework, but in addition the user code has to be developed with cross platform functionality in mind.
Goal: Working natively with VB files
The first question is: why not?
RAD Basic is new software developed many years after Visual Basic. The format of Visual Basic project files are simple, so it makes sense to continue using the format. We may in time come up a new format for RAD Basic project files. But, the development environment will be able to work with both.
And there are advantages too. The greatest is that this allows you to edit the forms/modules with both the legacy (VB6) and the new environment (RAD Basic). More about this feature in the next goal.
Goal: Design in three layers
This design decision may not seem particularly relevant but it affects both the compatibility and 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 &c), string manipulation, database access &c.
Why is so important? Because these three layers are independent but they could be interchangeable. Some examples:
- Use the VB6 (IDE) for design and writing code whilst compiling with the RAD Basic (compiler + runtime libraries)
- Use the RAD Basic (IDE) with the RAD Basic compiler whilst using the VB6 Runtime Libraries (in fact, just a part of them: ActiveX components as COMCTL32.ocx).
Below, more examples showed graphically.
These interchangeable layers allow a peaceful transition from Visual Basic to RAD Basic. As it works natively with VB files, you could switch between environments easy.
The development efforts for the first version are going into compiler and runtime libraries. Let’s go deeper about the requirements:
- Compiler: Of course this is the core of the project. This new compiler brings total control over the platform and brings compatibility with newer Windows versions, x64 platform, etc.
- Runtime Libraries: Why re-implement something that is working well? Why not use VB runtime instead (as core ActiveX is already present in Windows)? The reason is because we need source code control. With this we can fix bugs and develop new features and improvements. When you develop a new compiler, the runtime library has to be developed alongside. For example, although C++ is a standard language, every compiler have his its own runtime library, libstdc++ exists solely for the GCC compiler whilst Microsoft Visual C++ has its own 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 needed for releasing a full stack for developers. In further versions the IDE will be improved with all the features present in modern IDEs.
Goal: No improvements in VB language (frontend)
As stated in a previous post, the Visual Basic platform could be evolved in different directions. It could remain as VB6 whilst adding newer and more modern language structures like Try…Catch, multithreading, etc. These new features could be optional while “old” structures remain for compatibility.
The most important thing for us, as stated in the beginning of this post – is to stay on target! The current goal is not yet to improve Visual Basic 6 as a language. The goal is create a 100% compatible VB6 replacement. As the project is very large, all the efforts have to go into compatibility. Future versions could improve 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. The Visual Basic 6 environment (despite some minor difficulties) continues to operate in current Windows 10 so we need to offer something attractive to VB developers. As the backend is being developed from scratch, some improvements could be made: x64 support, visual styles for common controls &c.
This improvements will contribute to modernise the Visual Basic platform towards the new RAD Basic platform.
Hey! if you got here, thanks! This post was longer than expected. Although this blog post is named “technical details”, we didn’t get particularly technical. This post was all about design decisions, goals, advantages to establish the stage for further technical posts. The further posts in these series will be more about the current implementation.