The bitter sweet fate of WxDevC++

Recently, I've been enjoying programming with the Lazarus IDE which reminded me of the good old days when GUI programs can be quickly made without relying on the Dot Net framework. Visual Basic is what I had back then and Borland Delphi was something I wish I had. These days, my past childhood software-acquisition dreams are now easily within reach, thanks to the magic of abandonware archiving sites.

 I was interested to know what other free modern successors of past popular RAD programming environements are there

1. Delphi -> Lazarus
2. Visual Basc -> nothing similar at the moment, but FBEdit or one of the things made by Paul Squires might be viable alternatives.
3. C++ Builder -> I have no experience with this but wxDevC++ fits the description while RAD C++ seems to be not as developed or maintained. And no, there is nothing visual about Visual C++ in this context.

Lazarus is mostly compatible with Delphi 7, and by extension, Delphi versions 1 to 6. And if it weren't for Lazarus being free, I wouldn't have bothered about learning the Object Pascal programming language whose main implementation, Delphi, remains to be out of reach for the generally poor public. To be fair, Delphi Starter edition can be obtained for free, but in comparisson to what you get from Visual Studio Community edition, Embarcadero's starter edition products look rather limited. It is no wonder C Sharp is so popular these days. And it's even more interesting that C Sharp was made by the guy who made Delphi who happens to come from the same country as the guys who made C++ and Php.

So back on track, I was fooling around with the source code of WxDevCpp, which is an extension of DevCpp. DevCpp and wxDevCpp are somewhat funny as though they are IDEs for the C++ programming language, they themselves were written in Delphi. In retrospect, this also shows how amazing Delphi is as a RAD IDE to be used for such an application.

With my bit of experience in Lazarus and usng Delphi 7 through the magic of abandonware, I was eventually able to get the wxDevCpp main IDE to load in Lazarus.

wx-Dev-C++ loaded in Lazarus

But before that, I have to go through some pain. Based on what I experienced, I think there are 3 stages on tinkering with someone else's code.

1. Getting the source code to load without errors.
2. Getting to compile the source code without errors.
3. Getting to run the compiled programg without errors.

I only achieved upto the second stage. The first stage had to with retrieving all the third party dependencies (i.e. custom VCL components) that wxDevCpp uses. This was probably made more complicated by the fact that wxDevCpp was programmed in Delphi 6 while I was using Delphi 7 and there were some issues with themes.

wx-Dev-C++ loaded in Delphi 7

Finding my way through the slightly dated Delphi 7 environment was made a bit easier with some modernizing extensions such as the CnPack CnWizards extension that added line numbers to Delphi's text editor and GExperts that allowed me to investigate unit dependencies. Even without a few recent typical IDE features like line numbers and other editor enhancements, Delphi 7 is still quite sophistiacated, and given the maintained compatibility through Delphi's lineage, it is understandable why recent IDE extensions are still being made for the 15 year old Delphi 7 (I have acquaintances who are younger than that).

wxDevCpp was relying on the JEDI/JCL/JVCL extensions, SynEdit, MadExcept, other stuff that can be found on their sourceforge page and some custom components that the DevCpp developers made themselves.

Loading wxDevCpp in Lazarus

Custom components, i.e. those not available in a vanilla Delphi installation, will not be convertible to Lazarus. I had to repeatedly go through this process:

1. Purge custom components and comment out source code refering to these components.
2. See that the code still compiles. Don't bother to see if it will run properly, it likely won't after all the missing body parts.
3. Convert a copy of the code collection in Lazarus.

For custom components whose source was available and that are not a visual part of the form, I used the following trick (in the order I remember)

1. Visually remove the component from the form designer
2. Maintain the variable attached to the removed component by declaring it as a field in the form's class.
3. Check it still compiles

This way I ddn't have to modify where its other instances in the source code.

What appears to be the major technical hurdle of porting wxDevCpp to Lazarus or any other language is its reliance on third party components, particularly the JVCL/Jedi stuff. The designer part of wxDevCpp uses a lot of these. wxDevCpp also had extra components that only had to do with aesthetics (themes) and made it tied up to a particular compiler (Delphi 6). It was easy to purge the XPMenu component though.

And then there was wxDevIDE (aka wxDevC++ 8.0)

As it turns out, and thankfully, I'm not the only one who thinks that it is weird to have an IDE for a fully featured capable such as C++ to be programmed in a differnt language. True, this is necessary to get things started, but eventually there should be a stage, i.e. the singularity, when the same language is used to program future versions of itself. And indeed that seems to have be the vision. Since the Delphi-made-wxDevCpp can now make GUI applications, a feat that is not as simple with plain C++, maybe the next wxDevCPP, which is also a GUI application should now be made with Delphi-made-wxDevCpp.

wxDevIDE that was made with wxDevC++ that was made with Delphi

Compared to wxDevC++, it was refreshing to compile wxDevIDE as it didn't had the same dependency nightmare as its parent, and don't forget, wxDevC++ is much much easier to acquire than Delphi. I still had to modify the code a bit to successfully compile wxDevIDE in wxDevC++. It was something related to an xpm resource not being defined, then being redefined after the defining.

Sadly wxDevIDE is incomplete and relatively unknown. Despite the GUI being there, there's a lot of missing functionality. Especially the form designer, which is probably due to its past reliance on JEDI. Its no surprise I don't like Start Wars.

It has/had potential though, to be the next RAD for  C++ that produces natively compiled executables. There are other C++ IDEs like Code Lite and Code Blocks, but I had difficulty getting the wxWidgets extensions to work on these. They also don't have the established RAD look and feel that wxDevC++ manage to emulate (in fact there are more options I'm ignoring because of this). It is just so nice that wxDevC++ works out of the box, with a single download, and looks like a typical RAD IDE.

Maybe the RAD C++ code can be used to fill in where wxDevIDE is missing? Interestingly, it looks like it is made with DevC++.

Directly Running 16 bit Windows program on 64 bit Windows without Virtual Machines or DOSBOX

Well, I technically, there is still a virtual machine because that is what "VM" stands for. But it is not the popular virtual machines as we know that runs an isolated OS within an OS (e.g. VMWare, VirtualBox). Everyone already knows you can run anything on those stuff.

So here is what you get when you run a Win16 program on Win64:

 
In the awesome country of everything awesome (Japan), comes yet another awesome piece of technology.

WOWOW/OTDVM

So far, anthing I can find about running nostalgic 16 bit Windows on modern 64 bit Windows will explain how this is impossible. But maybe I've been searching wrong. Maybe I should have been searching in Japansese.
I knew that wine does a good job of runing Win 16. I even occasionally contemplate that Linux with Wine is a better alternative than the current auto-breakingWindows loaded with spying bloatware.

FYI: Wine can run 16bit Windows programs even in 64bit Linux

Searching how Wine runs Win 16, I learned about a thing called winedvm.exe. (And at the moment, I couldn't find where I read that fact from winehq.org and all I can see are how winedvm.exe crashes. I'm lucky to have found such an obscure tidbit of knowledge, but it doesn't help that this blog is even more obscure.)

And at the moment of writing this, I just had to check out NTDVM, what winedvm is simualting at Windows, and guess what, another interesting piece of emulation heaven.
https://sourceforge.net/projects/nxvdm/
https://github.com/cshaxu/nxvm
This might be geared towards DOS 16bit programs though (I only looked at the screenshots and assumed that if Win16 is also possible, then it must be too cool not to showcase).

At the moment, OTDVM is still underdevelopment, and it might be crashing your beloved 16bit program instead of running it. But that is still far humane than how Win64 flat out rejecting its Win16 software grand parents. I tried loading the back-then-popular Calmira shell and I got the spash screen and some error messages.

I also tried with some of my past Visual Basic programs, and they loaded and OTDM seems to also have loaded the necessary vbrun300.dll which is on the same folder as the program. Textboxes do not display proper fonts yet and the menu doesn't look properly renderd.

As can be seen, the program is running on top of Windows 7 64 bit. (although this screenshot really doesn't prove that the program is 16 bit or that I did not photoshop all of it).

Conclusion:
Seeing that the project is active, and seeing that Wine can actually manage to load Win16 stuff and that this is from the awesome land of Japan, I think that this project has potential. It would be nice though if more people might accelearte this project. Unfortunately, programming windows API internals is beyond me. Seeing that this is based on Wine (which is a Linux program), it might also be intersting to investigate how Cygwin handles Linux programs under Windows.

And now I have made 2 blog posts for the year 2018, so I already exceeded my quota. If nothing else gets posted within the year, it doesn't necessarily mean that I have crossed the river styx.

Why programming languages were invented

This historic 1950s video from IBM introducing Fortran, the first programming language, tells us why programming languages were invented.