Gullible Travels (MFC review part 2)
The cathedral and third-party bazaar. How Microsoft extinguished MFC and the MFC third-party.
Delphi critic meets old friends and ask how’s it going?
Under the mantra - convert your MFC project to the next new shining framework - WinForms then WPF then Silverlight then MAUI then UWP, then WinUI3 or whatever Microsoft thinks best.
This leads to Windows getting fat, bloated, supporting different NET mini platforms (NET 2, NET 3.5, NET 4, NET/WPF, NET Standard, NET Portable and so on), having to support Win32 APIs, … and all the new features (unless forcefully marked as depreciated by removing functions from DLL).
This is a continuation of Microsoft's MFC - Mostly Failed Code.
Third-wheel MFC vendors
Finding third-party components for MFC, is like finding needles in a decaying haystack.
Grid control? There are only BCGSoft1 and CodeJock2. If you’re willing to fork out for ObjectiveGrid3. There’s the open-source grid4. ProfUIS5 is no longer maintained.
There is excellent support for Microsoft Access - until the frequent data-corruption and constant ODBC errors drive you to tears6.
ORM? If you can deal with DOA (Dead-on-Arrival Access), ADO or whatever framework Microsoft think it’s best to transfer data. Not minding that an error will bring down the whole ODBC32/ODBC64 stack and require constant reboots7.
Edit controls? Hahahahaha…
Most MFC C++ code in Windows are object wrappers to DLLs8.
Web-based browser? If your app is tied to IExplorer or it’s interfaces - good luck as they are deprecated and removed in newer Windows versions.
Using NET? Which NET version?
There are dozens of articles on MFC on CodeProject9, mostly broken as they modernize the website.
Older Dundas MFC toolkits - Ultimate Toolkit, Ultimate Grid are on CodeProject10.
Good luck if you can find Sheridan Controls MFC sources, ProtoView MFC sources.
There’s Desaware COM sources11 and venerable resize libs12, as resizing MFC dialogs and controls was nearly impossible.
There are more - sadly lost to time - bitrot, businesses closing down.
Trouble in ABI Land
The trouble with MFC - is it is a framework around an ABI (Application Binary Interface).
The Windows ABI is a series of libraries encapsulating an underlying concept - a series of callback routines which an application hooks into, to run on Windows. They stay the same from Windows NT 2000 to Windows 11.
In the 1980’s - doing DOS or CP/M apps meant direct hardware control - writing to Int 10h and to video-memory, hooking the MOUSE ISR (Interrupt service routine) for feedback, hooking Int16 for keyboard, and so on.
Applications were developed - dBase apps were created to easily create, edit and remove database files, as it was a chore to manually create file formats.
A unified way to edit documents instead of huge word-processor computers led to word-processors and spreadsheets were developed.
When Windows came - instead of hooks, complex ISRs, monitoring memory locations - Windows passes a message queue (Delphi’s Application.Messages).
The problem with MFC - is it is a wrapper around an unknown internal Windows concept. You can create all kinds of objects to encapsulate low-level Windows objects. On-top of…?
The Windows API exposes functions and procedures an application can call.
The Windows API documentation does not discuss about underlying concepts, underlying object libraries that comprise of the Windows operating system.
As Microsoft tries to create new frameworks - from OLE - new shiny things - COM, COM Automation, ActiveX, Internet Explorer Browser Objects, NET, DCOM (Distributed COM objects), COM+ as an alternative to SOAP, RPC/XMLs.
Trouble in Mobile ABI Land
PocketPC13, Windows CE, and ill-fated Windows Mobile Phone have something in common - every new device contains a newly introduced framework, which was depreciated on the next new year’s device14.
I’m a fish driving a motorized fish-tank, sitting in an airplane
Breaking changes to Windows mobile APIs and non-existent APIs, forced depreciations meant the only stable API was running on Windows CE - were oddware - embedded ASP server, serving ASP-pages in-app, eVB (Embedded Visual Basic) and OpenGL buttons, OpenGL rendered texts, OpenGL rendered UIs, connecting to dBase III written on embedded SD cards.
It was only when Microsoft implemented XBOX-compatible APIs to Windows CE, that XBOX games started to appear on Windows Mobile. By then it was too late - Windows Phone market share had fallen to less than 1%.
The latest Windows framework - WinUI3 is not dependent on MFC. They suggest you port your code to use WinUI315 while the thread Is WinUI3 dead?16 casts doubt as the viability of porting to yet another framework are worthwhile efforts.
Should I target Android and iOS, while constantly porting my desktop apps?
Steamin’ using Proton and WINE
As the Windows API becomes standardized - Proton17 used by SteamOS, Wine, CrossOver and BOX8618 allow Windows apps to be run without Windows. Instead of porting, create a Windows EXE and ask customers to run WinLator19 or WINE on MacOS or on Steam Machines.
Visual Basic 6 in terminal decline
The beloved Visual Basic community got terminal shock, when, instead of VB7 x64, it got VB.NET, a variant of C# language simplified for Visual Basic.
Visual Basic NET won’t get new features that the NET CLR exposes in C#20.
As VB6 ages, the vendors go out of business. Unlike Delphi developers who ship with sources, the OCX, VB6 run-time dependent DLLs become a nightmare.
Next up: Criticisms of NET and basic-language vendors (including an aptly named B4A).
After hearing sad stories, Delphi Critic’s friend asks - can I borrow some money for next year’s subscription to CodeJock, BCGSoft or ObjectiveSuite? Delphi Critic said no thanks and left.
Let us know your comments below.