Thanks for the update, I really appreciate knowing more on why. I have to say that I was genuinely worried quite a bit about the future of QB64.
QB64 is key to my business...let me explain:
In 1997 I was using a DOS based POS system in my company. While this POS was great for invoicing and inventory control, it lacked pretty much everything else. So I set out to create the missing items via a wrapper (of sorts) for the POS. One great thing about this POS that allowed me to do this was that upon finalizing a transaction, it gave me the ability to write that transaction data to a file and then run an external .EXE. Voila! This was my ticket to making any external accessories functional - I would read this data and then the .EXE written in QB45 would take over . I worked and worked to integrate email into the POS (keep in mind this was late 1990's). I also generated a LOT of automation for this POS that ran tasks like bank and credit statement reconciliation, statements, invoice copy regeneration (the POS did not store these for some reason), and a bunch of other stuff.
There was so much integration of QB45 programs into this POS that I could not run the company without it (at least not as efficiently). When the company that wrote the POS came out with a Windows version, I could not justify having to rewrite all the code...so I stayed with the DOS POS for many, many years. Eventually all good things must come to an end and so it did. I started reaching the limits of the DOS software and it's indexing capabilities. Giving huge credit to the programmers of that DOS POS, it warned me that the limits of the indices were approaching their limits and actually game me a maximum number of transactions left. With the help of tech support they got that reset for me which gave me a year or so, but they warned me that it will be back.
I discovered QB64 and my life changed. Seeing as the new POS Windows version was 64 bit, the existing QB45 code will not run (no more 16 bit in 64 bit Windows). I would move to the new Windows version of the POS and continue where I left off, so to speak, with adapting the current code base that had been written over the years...yay!!!
I purchased the upgrade to the Windows version of the POS and started the massive task of adapting and rewriting the code to work around the new POS. Keep in mind that with 16 bit code and QB45 you were very, VERY limited to the amount of memory that you could use. I was stuck to the amount of memory that the POS software took along with the requirements of the QB45 code because of the way that the software shelled to the command line to allow me to execute my code. There were features that I could not implement because I did not have enough memory space to do so (way less than 640K).
I come to the realization that the sky is the limit when it comes to memory requirements for me to implement additional features. And did I implement soooo much more. About a year and a half later we went live with the new Windows based POS along with the new QB64 code to supplement it. QB64 has given me the ability to do way more with my POS software, and do it in less time with more accuracy. An example: Clients email an order and I used to have to type these orders into the POS by hand, replicating all of the many comments required by the client. I set up an Excel spreadsheet to track my time and an average order took around 10 minutes to enter. I wrote an import routine in QB64 for automating that entry process and it takes less than 30 seconds...and since there is no human interaction to make errors - the order is input exactly as the client requested so if there is an error it is on the client's side.
I am just so happy to see that QB64 is still with us and has not gone away. Once the donation links are up again I will definitely contribute...
Thanks to ALL that make this project a reality for those of us that want to continue using basic...
Dano
QB64 is key to my business...let me explain:
In 1997 I was using a DOS based POS system in my company. While this POS was great for invoicing and inventory control, it lacked pretty much everything else. So I set out to create the missing items via a wrapper (of sorts) for the POS. One great thing about this POS that allowed me to do this was that upon finalizing a transaction, it gave me the ability to write that transaction data to a file and then run an external .EXE. Voila! This was my ticket to making any external accessories functional - I would read this data and then the .EXE written in QB45 would take over . I worked and worked to integrate email into the POS (keep in mind this was late 1990's). I also generated a LOT of automation for this POS that ran tasks like bank and credit statement reconciliation, statements, invoice copy regeneration (the POS did not store these for some reason), and a bunch of other stuff.
There was so much integration of QB45 programs into this POS that I could not run the company without it (at least not as efficiently). When the company that wrote the POS came out with a Windows version, I could not justify having to rewrite all the code...so I stayed with the DOS POS for many, many years. Eventually all good things must come to an end and so it did. I started reaching the limits of the DOS software and it's indexing capabilities. Giving huge credit to the programmers of that DOS POS, it warned me that the limits of the indices were approaching their limits and actually game me a maximum number of transactions left. With the help of tech support they got that reset for me which gave me a year or so, but they warned me that it will be back.
I discovered QB64 and my life changed. Seeing as the new POS Windows version was 64 bit, the existing QB45 code will not run (no more 16 bit in 64 bit Windows). I would move to the new Windows version of the POS and continue where I left off, so to speak, with adapting the current code base that had been written over the years...yay!!!
I purchased the upgrade to the Windows version of the POS and started the massive task of adapting and rewriting the code to work around the new POS. Keep in mind that with 16 bit code and QB45 you were very, VERY limited to the amount of memory that you could use. I was stuck to the amount of memory that the POS software took along with the requirements of the QB45 code because of the way that the software shelled to the command line to allow me to execute my code. There were features that I could not implement because I did not have enough memory space to do so (way less than 640K).
I come to the realization that the sky is the limit when it comes to memory requirements for me to implement additional features. And did I implement soooo much more. About a year and a half later we went live with the new Windows based POS along with the new QB64 code to supplement it. QB64 has given me the ability to do way more with my POS software, and do it in less time with more accuracy. An example: Clients email an order and I used to have to type these orders into the POS by hand, replicating all of the many comments required by the client. I set up an Excel spreadsheet to track my time and an average order took around 10 minutes to enter. I wrote an import routine in QB64 for automating that entry process and it takes less than 30 seconds...and since there is no human interaction to make errors - the order is input exactly as the client requested so if there is an error it is on the client's side.
I am just so happy to see that QB64 is still with us and has not gone away. Once the donation links are up again I will definitely contribute...
Thanks to ALL that make this project a reality for those of us that want to continue using basic...
Dano