I.e. instead of ASCII and Unicode choice, and XP Theme or no XP Theme, why not change all that so there is only:
Mode: (Legacy, Compatible, Modern)
[ ] Windows 4.x (Win9x/NT4) (x86 only, ASCII and no XP Theme, no Vista usermode)
[ ] Windows 5.x (W2K,XP, 2003, also works on Vista,Win7 etc.) (x86/x64, Unicode and XP Theme on, Vista+ usermode choices available but optional)
[ ] Windows 6.x (Vista,2008,Win7) (x86/x64, Unicode and XP Theme on, Vista usermode choice defaults to user)
I'm only guessing here, but those who make Ascii apps usually wish to target Windows 4.x (Win9x and old NT) and x86,
and those who make Unicode usually wish to target Windows 5.0 or later (as unicode doesn't work on Win9x anyway) and x86 or x64 (or both).
And since Windows 4.x apps still work on Windows 5.x I don't think it's that much of an issue to "split" old and new this way.
I myself have stopped supporting anything older than Windows 5.0 (Windows 2000) so I only do Unicode apps with XP Theme now and also use Vista usermode settings.
And slowly starting to move the older Windows 4.x stuff into Legacy status might help future development.
(a lot of the old APIs are deprecated on Windows 5.0 and later, and it would allow the compiler to use "new" Windows 5.0+ API's where appropriate)
It kinda would make sense too as PureBasic 4.xx could then eventually become the "Legacy" (ASCII, Win9x/old NT) branch and PureBasic 5.xx supporting only Windows 5.0 and later (Unicode, XP Theme, +vista usermode support, and taking advantage of Windows 5.0+ features where available).
I'd be happy to "re-purchase" PureBasic for that indeed
But for now, consolidating ASCII and XP Theme etc. into a Legacy and Compatible toggle should avoid most of the issues currently I think.
To re-iterate:
PureBasic 4.6x could have the following modes:
Mode: (Legacy, Compatible, Modern)
[ ] Windows 4.x (Win9x/NT4) (x86 only, ASCII and no XP Theme, no Vista usermode)
[ ] Windows 5.x (W2K,XP, 2003, also works on Vista,Win7 etc.) (x86/x64, Unicode and XP Theme on, Vista+ usermode choices available but optional)
[ ] Windows 6.x (Vista,2008,Win7) (x86/x64, Unicode and XP Theme on, Vista usermode choice defaults to user)
PureBasic 5.xx could have the following modes:
Mode: (Compatible, Modern)
[ ] Windows 5.x (W2K,XP, 2003, also works on Vista,Win7 etc.) (x86/x64, Unicode and XP Theme on, Vista+ usermode choices available but optional)
[ ] Windows 6.x (Vista,2008,Win7) (x86/x64, Unicode and XP Theme on, Vista usermode choice defaults to user)
PureBasic 6.xx could have the following modes:
Mode: (Compatible, Modern)
[ ] Windows 6.x (Vista,2008,Win7) (x86/x64, Unicode and XP Theme on, Vista usermode choice defaults to user)
[ ] Windows 7.x (Win 8 ?!) (x64 only, Unicode and XP Theme on, Vista usermode choice defaults to user)
As you see any support Windows 4.x is left behind in PureBasic 4.xx
and any Windows 5.x support is left behind in PureBasic 5.xx
The PB site has a selection of older PB versions so the last 4.xx could still be made available for those that wish to make Win9x programs.
There is one annoying little thing though. It's whether Windows 5.0 (Windows 2000) or Windows 5.1 (XP) should be the cutoff point.
Windows 5.0 seems the most logical but there are enough differences between 2000 ans XP and the fact that XP is so popular
that making 2000 also obsolete might be worth it. (most people using 2000 has moved to 2003 or 2008 by now anyway)
XP (Windows 5.1) also supports some nicer looking Window effects and handling (alpha features and more) than 2000 (Windows 5.0) does not support I believe. There are also new threading and timer features, scheduling and a whole lot more than PureBasic could leverage.
So personally I'd have no issue with PureBasic 5.xx only supporting Windows 5.1 (XP) and later myself.
In any case, being able to take full advantage of the Window 5.0 API would really benefit PureBasic I think.
A similar choice will need to be made on Mac as well I believe, like maybe PureBasic 5.xx only supporting the new x86/x64 Mac OS instead?
I'm less familiar with Linux, but I'm sure that a certain cutoff point there too could be used to mark what is supposed to be left as legacy stuff (and retire with PureBasic 4.xx) ass the OS aPI has matured over the years there too.
So if this means I have to use PureBasic 4.xx to make apps for Win9x or later,
and PureBasic 5.xx to make apps for Win XP and later,
and PureBasic 6.xx to make apps for Vista and later.
Then I'll be happy to do so. Considering that XP is considered Legacy already by MicroSoft it seems odd that we still have Win9x support around here.
Question for all you peeps here:
How many here still make software for Win9x ?
And when I mean "for" I actually mean "for" and that you just "prefer" to have unicode unchecked for some reason, as I believe that Win9x coding are only special cases these days.
Most private and corp and official users these days have WinXP (legal or not).
And in the odd case that a developer here has to make something for a old system running Windows 98 or 95,
they can just use PureBasic 4.xx rather than say the latest PureBasic 5.xx or PureBasic 6.xx as I hardly think that a old Win95 system (and an app for it) would need the latest features of PureBasic 5.xx anyway nor ever be able to fully take advantage of it in any case.
I know that Windows folks like to have a generation too far back supported far too long, but on Mac and Linux this is not the case, usually there is only the current gen and last gen ever supported in current gen.
Do people really make Mac OS9 apps any more for the Mac? I doubt it, most are made for one of the "cats", and usually one of the two latest cats (Tiger and Leopard?) in the Mac OS-X line.
As to Linux. Does people still make Linux kernel 1.x programs still? Nah, your lucky if any still make Linux 2.0 at all. Most apps made are either updated to or replaced by ones for kernel um.. 2.3 or 2.4 right?
That doesn't mean that old apps won't work on Mac OS-X, or Linux 2.4.x or Windows 5.x
So again.... (just an example)
PureBasic 5.xx only supporting Windows 5.0 (or 5.1 if W2000 is ditched) and later, x86/x64.
PureBasic 5.xx only supporting Mac OS-X 10.5: "Leopard" and later, x86r.
PureBasic 5.xx only supporting Linux 2.4.x/2.6.x and later, x86/x64.
PureBasic 6.xx only supporting Windows 6.0 (or 6.1 if Vista is ditched) and later, x86/x64.
PureBasic 6.xx only supporting Mac OS-X 10.6 ("Snow Leopard") and later, x86/x64.
PureBasic 6.xx only supporting Linux 2.6.x and later, x86/x64.
PureBasic 7.xx only supporting Windows 7.0 (Win 8 ?!) and later, x64.
PureBasic 7.xx only supporting Mac OS-X 11.0 ?! ("Meow meow kitty?") and later, x64.
PureBasic 7.xx only supporting Linux 2.7.x ?! and later, x64.
Remember, this won't reduce functionality of PureBasic, it just means Fred can get rid of clunky old OS hacks,
take advantage of more recent OS API features and ensure all PureBasic apps look/behave similar on all platforms.
Trying to make a app behave the same on Win7 and Win95 is just silly if you ask me.
I'm not sure why Fred hasn't split things like this yet, maybe because devs still expect to be able to make a app for any Windows versions using the latest PureBasic.
Now if we all made it clear that we don't mind using a older edition of PureBasic to make apps for older Windows editions,
then maybe Fred would be ok with tossing out support for old junk from new editions of PureBasic
PS! For those wondering, it's said that either Windows 8 or the next Windows after that. (Windows 7.x series ?) will be x64 only, you can still run x86 apps, but the OS will be x64 only, so it will be the general end of future x86 apps and start a full drive to really start "moving" all apps over to x64).