Hi SMcNeill
Unfortunately, I mostly desaggre with youwhile respecting your point.
Our goal has always been QB45 compatibility/feel, and pushing Inform seems (to me at least) that we’d be pushing more of a Visual Basic type experience.
Just as the 64-bit version of QB64 is an optional product, and all the incredibly nice libraries out there (like Terry Ritchie’s varied assortment) are additional downloads to enhance the “core package”, so should Inform be.
QB (as well as Turbo Basic, a better QB than QB) was a DOS development tool.
As such, it was a non-graphical 16-bit product.
And this time is over for a very long time.
We now have Windows, Linux and OS/X which, to this day, are all 64-bit operating systems, some of which still carry 32-bit codes for a short time.
And I can add: most of the Linux vendors are abandoning their 32-bit version.
Why? Just because 16-bit and now 32-bit computers are "old dogs" not produced anymore (but for very few exceptions dedicated to embeded real time systems).
Even MicroSoft is currently working on an upcoming version of Windows (from what I heard from my internal friends called "lite") that removes support for 32-bit code (like they did for 16-bit code starting from Vista, Windows 8 then Windows 10).
Why? The simple fact of supporting "legacy codes" is today an extremely expensive solution in terms of development, maintenance but also overall performance.
In addition, this new Windows version is mainly dedicated to very cheap computers such as PI and the like.
So, I do not blame you for supporting the original "QB64 spirit", but it could be done in 64 bits.
In addition, the end of Windows 7 support is expected in less than 2 years.
And then, future versions of Windows will definitely give up support for 32-bit code.
So putting all 64-bit development efforts should be the mantra of the QB64 development team.
I know some even use XP again. But without any security for themselves and their "customers". For me, it's a "crime"!
So, my suggestion to create a new development framework including the 64-bit QB64 compiler, InForm, and vWATCH64 that could produce both console-based and GUI applications is just a vision of a very short future, without even saying as long as the supported operating systems will allow it (run console-type applications).
This does not mean giving up the QB64 "style" which, as a single text based program is destined to disappear faster than expected.
Even Visual Studio no longer offers to create console applications.
So, I do not want to hurt you, but should the QB64 project become a dinauzore that will not work on a newer system but only on PCs you can't find anymore repair pieces but in museums?
Just my two cents.
Kind regards.
Fifi