My QB64 debut anniversary

[FellippeHeitor]

I had been using QB64 for a good while even before I considered joining the forum back at [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there] and after I finally did it still took me another good while to become involved with QB64 itself.

Today is the third anniversary of my first contribution to the QB64 repository on GitHub (even though back then I still relied on Luke to apply the changes for me... it still took a while for me to be granted access to it).

Here's my first tidbit that got added: https://github.com/Galleondragon/qb64/commit/86acbbbcddeb999ebac90f06d2163bb726aaeead

It has been a really fun ride so far. Thanks to all involved for the continuous support.

Fellippe.

[Qwerkey]

Feliz aniversário

[Dimster]

Contributors, such as yourself are QB (ie Quite Brilliant)

[Pete]

Happy anniversary! I like the "Quite Brilliant" quote from Dimster, but I always thought QB stood for, "Quit bitching!" I mean when QuickBasic was deprecated by Microsoft I tried C, C++, Pascal, FB, Ruby, and a couple of other BASICs but I never QB again until QB64 came along. There is just something about it that feels native. Easy to remember, easy to write routines. You can customize everything, and now it is easier than ever to incorporate libraries if needed. The memory limit removal is another thing I QB about when 64 came along. I just wish I could QB about Android, but that's about the only thing left on my wish list to QB about.

The QB forever mantra, from the QBasic days seems to have held up. I've heard FB is fading. Our QB64 developer decided to take a break, I have a weird feeling he may get sucked back in someday, but the project lives on. Fell took the reins, and Fell, Luke and Bill put this .org site on the map... with a little prodding to keep it up permanently from some nagging third party who won't be named. Bill was also so kind to donate his registered .org name, to the project, as well.

If I had a vote for Most Improved Player, I give it to Steve. He was a late bloomer to the language, but has dabbled in all of it, even though I keep telling him SCREEN 0 is all anyone needs, has got under the hood to desert how the translator (compiler) works, and had to learn some C/C++ along the way. He gives oodles of help to people asking questions and provides some very in-depth tutorials to explain things.

I'm coming up on my 30 year anniversary of Using QB/QB64 in 2020. I know we have mostly older users here, too. I'm glad to seem some young fresh faces. Ashish certainly comes to mind. I think he may have a bright future in programming or any other interests he may wish to pursue. It would be neat if another generation of hobbyist "Fell" into this project. I know a few schools have teachers who use it, so that's a possibility. I don't think there will ever be too many who will see the worth in business applications, as I have. I wish more would see the worth in utilities. I run high and hard on my SCREEN 0 bit, by I give you graphics guys a ton of credit for attracting younger talent to the project. Gaming seems to be #1 among attracting hobbyists to any programming language and wen you guys post screen shots of your games, well, I think that's the neon sign for this project.

Well, time for me to QB so I can get back to QB64. Actually I have a little HTML work to get done first but I have a few utilities I threw together to help me with that work, too.

Again, happy year three and many thanks for keeping the project alive and well!

Pete

[robpugh0829]

I completely agree wit Pete that this can have business application uses that people don't even consider. I started out on DOS 6.22 with qbasic, then got my hands on QB 4.5 and was bummed when Windows eventually shut it down, so when I accidentally found QB64 several years ago, I was extremely happy. I'm still not perfect with everything, but I appreciate the things that have been added to make things easier. The mouse comes to mind for me. No more Assembly for the mouse. I work as a web developer/programmer and the other day my bosses needed something done quick and it needed to be small and just a graphical interface that could launch 4 videos and then come back to the interface after they closed the window. Quick and small, hmm...I thought QB64 sounds like the tool to use and ever since I was a teenager programming in QB 4.5 I wanted to use it somehow in a professional sense. So I threw that UI together and it worked great! They were very happy and it was less than 2MB in size which made them even happier. I'm a QB64 guy for sure. Thanks for keeping it alive all those who contribute.

[Bert22306]

Fellippe,

Sou o mais agradecido pelo seu trabalho difícil. I'm always amazed at how fast bugs get fixed, and how much better the IDS has become.

Don't know the rest of you, but I'm definitely one who uses QB64 for work (and for play). When I use it for work, it's because almost anyone can understand the code. What I do in QB64 is usually implemented in C, before it is embedded in our products, but in the meantime, it is reviewed and tested by others, just so everyone is "on the same page," so to speak. No ambiguities, no need for sloppy pseudo-code. When the algorithm is defined in QB64, it's going to work right.

So, many thanks to Fellippe and the other developers, for keeping this language alive and well.

[Fifi]

Happy third QB64 birthday Fellippe.

With the other members of the QB64 dev team, you are doing a great and invaluable job.

Thank you very much for your time and involvement in this project, including your excellent and amazing work with InForm and vWATCCH64.

Now, just a question:

How difficult would it be to create a complete open source project including the QB64 IDE, the InForm GDE and the vWATCH64 debugger into a single and unique tool 'à la' Deamweaver or PHP Studio?

I'm sure such a product would make a rocket flyer development tool with the ease of the QB64 language, the ease to create GUI apps and the ease to debug and fix the results within a single development cross platform environment.

Just my two cents.

[STxAxTIC]

I'm sure such a product would make a rocket flyer development tool with the ease of the QB64 language, the ease to create GUI apps and the ease to debug and fix the results within a single development cross platform environment.

I agree with this line of inquiry, and suggest we take the easy route in that InForm, or at least the installation EXE, should ship standard with QB64 to benchmark this special day (even if it was yesterday by now).

[Fifi]

Hi STxAxTIC

I agree with this line of inquiry, and suggest we take the easy route in that InForm, or at least the installation EXE, should ship standard with QB64 to benchmark this special day (even if it was yesterday by now).

This is why my multi lingual installation script for Linux (http://www.as2.com) installs (and uninstalls) the three tools altogether.

However, creating such a single tool would be a big step forward in providing a complete development environment framework "à la" Dreamwaever that coud produce both console and graphical apps.

Cheers.
Fifi

[SMcNeill]

Inform is nice and all, but I don’t think it needs to be part of the standard QB64 package.  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.

[Fifi]

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

[SMcNeill]

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.

I’m just curious — what makes you think this? 

Win 10 supports 32-bit code.  Linux supports 32-bit code.  Neither seems like they’re going to drop that support anytime soon.

What possible benefit would Windows have to drop support for 32-bit programs at this point?  WOW is a well tested and functional emulation layer for 32-bit programs in their 64-bit OSes, and I don’t foresee technology needing to move up to 128-bit memory addresses any time soon, as it did for the jump from 32-bit to 64-bit.

I just can’t see any real reason why they’d drop 32-bit support, and even if they do, there’ll quickly be a replacement like DosBox/Wine to emulate it.   Honestly, I just can’t imagine myself loosing any sleep worrying over the possibility.

[Pete]

128 in 2100 is what I read this afternoon. Systems can't use the whole 64-bit ability yet, anyway.  It's closer to 40, although I really don't understand this stuff very well.

It was like the rug being pulled out when 16-bit was deprecated. Some xp's were 32-bit, but many were still 16. QBASIC ran on some XP's but not XP-Professional. DOS-BOX was a workaround but I never really made use of it. Very clumsy. DOS-BOX actually has an Android version but again, not much fun to run QB apps in it. You really need to more modern stuff for mobile apps.

What is the QB64-64 bit compiler, anyway? It isn't part of the download package, right?

Pete

[SMcNeill]

What is the QB64-64 bit compiler, anyway? It isn't part of the download package, right?

Pete

QB64 only packages the 32-bit compiler for Windows.  If you want QB64x64, you can download a copy from my site: http://qb64.freeforums.net/thread/100/qb64-x64-10-17-2018

It’s not quite as up to date as the development build at github, but it’s newer than the current stable build.  (The current 64-bit version was compiled last on 10-17-2018.)

64-bit Windows runs 32-bit programs in an emulation layer (a built in version similar to DosBox that runs automatically behind the scenes), so if you want programs which run “truly natively” on your 64-bit Windows, you’ll want the QB64x64 from the link above. 

64-bit programs don’t suffer from the 2GB memory limit, usually run faster, and usually have a smaller compiled size, so I usually code in QB64x64 exclusively, for my personal needs.

[Pete]

I just downloaded it. I'll give it a whirl tomorrow. You'd have to hope whomever came up with that saying did so before the marvel of modern plumbing was invented.

Anyways, thanks!!!

Pete