Approaches to Porting CB to multi-platform wxWidgets.

[DLLarson]

We need to develop a strategy to port CB to the multiplatform GUI framework wxWidgets.

Why wxWidgets?

Because its design lines up nicely with how Microsoft's MFC framework is implemented. Plus it has a decent license that doesn't force GPL burdens on the developers.

This port was underway some years back but it went stale when all development on CB stopped. We need to rescope out the approach.

-Dale

[DLLarson]

From PR #112:

My current thinking is: ..... The wxWidgets suggest it can co-exist with MFC, so try to splice it into 4. The reason for the previous from-scratch port was that I didn't have the extra GUI toolkit that CB3 used.

This sounds promising but I don't fully understand how this co-existence is provided. Do you have a link?

-Dale

https://github.com/wxWidgets/wxWidgets/blob/master/samples/mfc/mfctest.cpp

[DLLarson]

https://github.com/wxWidgets/wxWidgets/blob/master/samples/mfc/mfctest.cpp

I had a chance to look at the proof of concept sample and it looks like it requires that the application dynamically links to MFC's DLL's. This is something I avoided even with the pure MFC version of CB. It's much nicer to have everything baked into the executables to keep installs simple. It also makes debugging easier.

I don't see how we can avoid a full sweep through the code to map wxWidget's definitions to equivalent MFC definitions. Perhaps a tool could be created to translate all the the one-to-one items to reduce overall manual labor. I believe that's what we did last time. The good news is that all the work Bill Su did to enhance type safety and find additional bugs should make it somewhat easier.

It's a big job but there are some tangible positives once complete:

• Listboxes could use wxWidget's virtual list box class to eliminate CB's limitation of 255 heights in owner draw list boxes. This problem is even worse for MFC's DPI awareness support making tall items even less visible for DPI scaled environments. I would love to see this PITA go away.
• wxWidgets appears to support full DPI awareness. This is something that MFC doesn't fully support. If fact try to find a single call to the Win32 API DPI awareness functions in MFC's source code. You won't find any.
• wxWidgets supports GDI+ classes for more capable graphics than what MFC's CDC class provides should we want to use them.
• In general, wxWidgets has more extensive capabilities than what MFC offers. For the most part it seems like Microsoft only minimally maintains MFC for each release of its tools. The features are not being expanded or even brought to parity with the current technologies provided with newer Windows releases. Lack of full DPI awareness being a great example of this. The last big enhancement was the MFC Feature Pack from the Visual Studio 2008 release and that was done licensing source code from a third party package of MFC enhancements and having them integrate them using MS approved class names.

-Dale

[cholmcc]

Hi,

I had a chance to look at the proof of concept sample and it looks like it requires that the application dynamically links to MFC's DLL's.

Most likely, wxWindows cannot link MFC statically due to license issues, but it may be possible for you to link both wxWindows and MFC into one. On the other hand, those that do not use Windoze can use wxWindows shared libraries seamlessly.

Perhaps a tool could be created to translate all the the one-to-one items to reduce overall manual labor.

Perhaps something like this or the attached convert.txt (rename to convert.py).

My 2¢

[DLLarson]

Most likely, wxWindows cannot link MFC statically due to license issues, but it may be possible for you to link both wxWindows and MFC into one.

I don't think we'd really want to run MFC code inside the app since that would kill platform independence--i.e., we'd still be locked on Windows so it has no point. We'll go for a clean port that leaves the Win32 API behind.

Perhaps something like this or the attached convert.txt (rename to convert.py).

We brewed up something similar last time we did the work to bootstrap the port. But I can't seem to locate it anymore--it's been many years. This saves us some time recreating it.

Thanks! It's appreciated.

-Dale

[cholmcc]

I don't think we'd really want to run MFC code inside the app since that would kill platform independence--i.e., we'd still be locked on Windows so it has no point. We'll go for a clean port that leaves the Win32 API behind.

I guess you know this, but you cannot link MFC on any other platform than Windoze since it is not available elsewhere.

You will anyway need builds for each platform you want to support - e.g., Windoze, MuhOS, and GNU/Linux. You can probably set up GitHub CI/CD jobs to build these for you when ever you tag a release (I have little experience with GitHub CI, but I know GitLab can do it for you at least for GNU/Linux).

Actually, looking a bit closer at wxWidgets sample code - e.g., Event sample I see in the VC-Project file

		<Tool
			Name="VCLinkerTool"
			AdditionalOptions=""
			AdditionalDependencies="wxmsw30u_core.lib  wxbase30u.lib    wxtiff.lib wxjpeg.lib wxpng.lib   wxzlib.lib wxregexu.lib wxexpat.lib    kernel32.lib user32.lib gdi32.lib comdlg32.lib winspool.lib winmm.lib shell32.lib comctl32.lib ole32.lib oleaut32.lib uuid.lib rpcrt4.lib advapi32.lib wsock32.lib wininet.lib"
			OutputFile="vc_mswu_x64\event.exe"
			LinkIncremental="1"
			SuppressStartupBanner="true"
			AdditionalLibraryDirectories=".\..\..\lib\vc_x64_lib"
			GenerateManifest="true"
			GenerateDebugInformation="true"
			ProgramDatabaseFile="vc_mswu_x64\event.pdb"
			SubSystem="2"
			TargetMachine="17"
			OptimizeReferences="2"
			EnableCOMDATFolding="2"
		/>

which indicate that the needed (static) system libraries linked against are

• kernel32.lib
• user32.lib
• gdi32.lib
• comdlg32.lib
• winspool.lib
• winmm.lib
• shell32.lib
• comctl32.lib
• ole32.lib
• oleaut32.lib
• uuid.lib
• rpcrt4.lib
• advapi32.lib
• wsock32.lib
• wininet.lib

which seems fairly standard.

On my system (Debian GNU/Linux) wxWidgets depend upon GTK 3 which are automatically linked in via shared libraries.

My 2¢

Yours,
Christian