Version 2.0.2 compatibility

[krovit]

This is obviously a compatibility problem, MinGW isn't predictable any longer with Windows7. Might have to revise the C++ compiler flags or "make" strategy.

But I ask, if you are so sure it works on an older release of QB64PE, then why do you insist on "upgrading" to v3.4.1?

We might have to start saying that now the minimum is Windows8, rather than Vista. Ouch.

I always update the QB64 version so I don't lag behind with new features and compatibility.
Based on what I have read I would also say that, at this point, compatibility with windows7 is compromised.
I haven't tried compiling on windows 10 yet but I assume everything will work as it should.
However, it will be necessary for you to use 3.4.0 on Windows 7 for a while.

Thank you very much to everyone for your attention...

___
Generally the software that runs on any version of the operating system from Windows 3.1 onwards is a great software!
Sometimes, however, it seems, that if he runs on an old version he is old too... but this is not the case. In fact, it is the opposite: it is eternally young!

[DSMan195276]

I always update the QB64 version so I don't lag behind with new features and compatibility.
Based on what I have read I would also say that, at this point, compatibility with windows7 is compromised.
I haven't tried compiling on windows 10 yet but I assume everything will work as it should.
However, it will be necessary for you to use 3.4.0 on Windows 7 for a while.

Thank you very much to everyone for your attention...

To clarify, we have a QB64-PE developer (RhoSigma) using Windows 7 with the latest 3.4.1 and new MinGW version and it works just fine. I'm not entirely sure what the issue you're experiencing is, but QB64-PE does work on Windows 7.

[RhoSigma]

To be exact:

Windows 7 Home Premium (c) 2009 SP1 64-bit
4GB Ram
Intel Core i5-2430M CPU @ 2.40GHz

The only change I had to make in some of my C-Header files is replacing unsigned int32 into uint32 to work with the new MinGW compiler.

And to be clear, I talk about my own (project related) header files, not the standard header files delivered with MinGW.
(https://staging.qb64phoenix.com/showthre...2#pid10782)

[Stuart]

QB64-PE v3.4.1 (32-bit) is also working on Windows Vista (32 bit) without any problems that I'm aware of.

More details :

OS Name Microsoft® Windows Vista™ Home Premium
Version 6.0.6002 Service Pack 2 Build 6002
OS Manufacturer Microsoft Corporation


System Type X86-based PC
Processor AMD Athlon(tm) 64 X2 Dual Core Processor 5000+, 2600 Mhz, 2 Core(s), 2 Logical Processor(s)

Installed Physical Memory (RAM) 3.00 GB
Total Physical Memory 2.87 GB
Available Physical Memory 1.56 GB
Total Virtual Memory 5.98 GB
Available Virtual Memory 4.76 GB
Page File Space 3.17 GB

[krovit]

I don't know what to think. Someone mentioned the fear of compromise on win 7.
It is also true that the project that I can not compile with 3.4.1 is very large and complex and perhaps only by chance an incompatibility has been discovered. In fact, to say, many other things are compiled without problem.
If the compilation of a project with 3.4.1 fails and the exact same project on the same PC succeeds with 3.4.0 I think we can conclude that the problem is not in the project but in something that has changed between one version and another. I admit, however, that it may not be necessary to know!
The fact remains that 3.4.0 seems to go like a train. Maybe even 3.4.2 .

[mnrvovrfc]

Yes, have faith that it will be fixed because this kind of thing shouldn't happen in a sub-point release. It's tolerable moving to v4, maybe, and less expected moving to v3.5. But we're still on v3.4 here, just a little point.

Have faith. Don't be discouraged by what other people report saying that it's working.

[mnrvovrfc]

It is also true that the project that I can not compile with 3.4.1 is very large and complex and perhaps only by chance an incompatibility has been discovered. In fact, to say, many other things are compiled without problem.

What galls about this is that the original author of QB64, Galleon wrote much of the code so it were possible for QB64 to "compile itself" with an earlier version/release of itself. But this was at least ten years ago, before it reached v1.

The BASIC code was thousands of lines long, a lot of it only for the IDE. If your program is anywhere near that complexity, it has better chances to turn up light in a dark corner. It's not a case of discouragement after working on the source code for years.

On the other hand, before v1 QB64 was less capable than it is now. In its first releases it wrote "stdout" and "stderr" files like ordinary files in the same directory as the executable, which was annoying if the user program were burned to CD or DVD and crashed because of it. It had relied on an external library for music playback which was buggy.(*) The graphics base had to be switched out of a library that wasn't being developed any longer, and different people were in charge of the second version. It caused the move to OpenGL and "freeglut", added the "_MAPTRIANGLE" command which is very important. Many other things happened, such as restructuring the source code so it fell into much more than one BASIC text file, and some "black magic" introduced by the QB64 Team and then by the Phoenix team this year.

Until v3.4 if someone wanted a dialog to get a filename from some directory, which is the one Windows offers, he/she had to resort to Windows API programming harder than BASIC. It had to be done even for a "message box". Alternatively one had to do his/her own graphics for it, and to get filenames, had to borrow certain routines written by the popular guys on this forum. This would become hard to believe next year and after for lurkers going to use this product after having some experience with Microsoft BASIC.

(*) With user programs created by the "SDL" version of QB64, where there was any chance of MP3 playback, on my other laptop which had Windows10 never updated from late-2017, instead I needed to use M$'s media player to get correct playback.

[krovit]

For everyone...

to avoid misunderstandings and misunderstandings I would like to reassure everyone, especially the creator of QB64 and those who have contributed and still contribute today to its improvement with so much commitment and passion, that I do not intend to irritate them or anyone else.

I have been using QB (QB4.5 and then all subsequent variants and before that more archaic  languages, unfortunately without reaching such high skills as I see here and elsewhere) for decades now and I have a huge esteem for QB64.

I'm not enthusiastic about apparently more advanced languages (and sometimes they really are) that are on the net, even open source or even free and I don't want to learn new ones (now I'm a certain age...).  I have always said - and I confirm it - that those communities of programmers are frequently closed to any novelty, do not allow replicas or modest criticism and newbies are arrogant and rude.

Not so with with the community of QB64 that I have always found kind and helpful (apart from maybe a couple of cases... after which QB64 split in two - not because of me, of course!), collaborative and open to dialogue. Even humble! Which is a great moral quality that surpasses all possible competences.

So, guys, good job! And thank you!

[mnrvovrfc]

I'm not enthusiastic about apparently more advanced languages (and sometimes they really are) that are on the net, even open source or even free and I don't want to learn new ones (now I'm a certain age...).

I'm just like you... but I do want to learn Racket. I don't want to go deep into Common LISP and Scheme to be more comfortable with it, though, but they way I defeat myself for it really sucks...

It's not BASIC nor related but it was something that interested me this year. The Dr.Racket program is a really kewl IDE but sometimes I want to develop on my own away from training wheels. I guess it's not really for me because I'm intolerant. (shrugs)