Normally I wouldn't have time to write another post. But what just happened?
Why is my Thinkpad suddenly just crashing again?
Explorer freezing for no reason when everything was just perfectly fine yesterday and I had not installed anything that might break the OS between yesterday and now.
WTF. Just WTF. I feel like punching my computer screen, but I know it would just do more harm.
What happened to the hours minutes that I was supposed to be productive?
What new crap has Windows 10 automatically downloaded for me?
I fear the day when Windows 7 will no longer be supported and we all have to accept this crappy broken auto updates Microsoft force feeding us if we want to keep the latest OS.
Soon Macrium Reflect will be finished restoring the disk back to Windows 7.
Thankfully I have a Thinkpad that supports two hard drives and I have all my work on the second drive. I still need to make the dormant Windows 7 OS catch up with all the updates. Thankfully there's WSUS offline to take care of that.
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
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.
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.
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.
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.
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++.
I was interested to know what other free modern successors of past popular RAD programming environements are there
- Delphi -> Lazarus
- Visual Basc -> nothing similar at the moment, but FBEdit or one of the things made by Paul Squires might be viable alternatives.
- 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.
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.
- Getting the source code to load without errors.
- Getting to compile the source code without errors.
- Getting to run the compiled programg without errors.
 |
| 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:- Purge custom components and comment out source code refering to these components.
- 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.
- Convert a copy of the code collection in Lazarus.
- Visually remove the component from the form designer
- Maintain the variable attached to the removed component by declaring it as a field in the form's class.
- Check it still compiles
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.
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.
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.
Visual Studio 2015 Update 3 Shenanigans
Day 3 of what the hell happenned to my productivity.
After my little victory of disposing Windows 10 into the pits of hell where it came from, it seemed that yet another Microsoft update-to-break scheme was just waiting to destroy my peace of mind.
As much as I praise Visual Studio's intellisense, the dot Net framework, C sharp, dolphins and a lot more coding conveiniences in its very capable IDE (perhaps the best IDE in this part of the galaxy, at least the best free IDE), it is unfortunate that this too have to suffer with if it's-fixed-break-it mantra of recent updates coming from Microsoft.
As it turns out, the reason it is taking centuries to re-install Visual Studio from my offline installer is because it is being online behind your back. And deploying bazillion gigabytes of stuff beyond what you thought was just the offline installer.
Out of frustration, I had to violently kill the sluggish installation, because suddenly I had the urge to kill something, if not someone. Forunately I'm not the first one who have to suffer this madness and there have been documented ways to avoid or fix this.
After my little victory of disposing Windows 10 into the pits of hell where it came from, it seemed that yet another Microsoft update-to-break scheme was just waiting to destroy my peace of mind.
As much as I praise Visual Studio's intellisense, the dot Net framework, C sharp, dolphins and a lot more coding conveiniences in its very capable IDE (perhaps the best IDE in this part of the galaxy, at least the best free IDE), it is unfortunate that this too have to suffer with if it's-fixed-break-it mantra of recent updates coming from Microsoft.
As it turns out, the reason it is taking centuries to re-install Visual Studio from my offline installer is because it is being online behind your back. And deploying bazillion gigabytes of stuff beyond what you thought was just the offline installer.
Out of frustration, I had to violently kill the sluggish installation, because suddenly I had the urge to kill something, if not someone. Forunately I'm not the first one who have to suffer this madness and there have been documented ways to avoid or fix this.
- The aborted installation I killed with blissful pleasure can be somehow cleaned up by re-running the installer with "/unisntall /force" options. To get the most satisfying feeling run it in an admin command line.
- There is a tool called the Visual Studio Uninstaller that futrhter can clean up this mess https://github.com/Microsoft/VisualStudioUninstaller/releases. This indeed appears to remove more stuff beyond what the forced uninstall can do.
- The "/noweb" option should prevent the visual studio installer from installing more stuff out of thin air. But as this magic fix looks to be good to be true, and since violence is more satisfying and appropriate for moments like this, it would be better to totally disable your network connection (via ncpa.cpl, or phyiscally). What was the point of having an offline installer in the first place anyway?
- In case you're wondering where or what is this so-called offline installer, visual studio can be instructed to just fetch the files and dump them on a specifed foler using the "/layout" option.
- For maximum satisfaction reboot Windows in every possible opportunity while doing these magic tricks.
- In the same, spirit, automatic broken updates can be disabled via "Options > Environment > Extensions and Updates".
RSS feed