Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - EricR

Pages: [1]
1
QB64 Discussion / Re: DAV's IDE will not run EXE
« on: March 27, 2020, 02:19:51 am »

I agree that Dav's IDE is nice. Hopefully, Dav gets a new release out sooner than later.

2
QB64 Discussion / Re: QB64 1.3
« on: April 10, 2019, 12:57:43 am »

While I am not an official QB64 team member, my assumption is no.  Setup_win.bat was used to build QB64 when you downloaded it from the Github repository.  If this new format is here to stay, my guess is that manual build will not be done anymore. 

3
Programs / Re: NumType -- The Overengineered 'Is it a number' FUNCTION.
« on: January 26, 2019, 07:20:15 pm »
Maybe we need a Rube Goldberg programing challenge!

I am not sure Steve would like that.  He might go and try to out Rube Rube.  Then again, he may find a way to out complex something useful.   For me the query is a simple one, will anyone besides Steve step up for the challenge?  I am not sure anyone would. 

4
QB64 Discussion / Re: 64bit Windows Dev build now officially available
« on: January 09, 2019, 03:04:02 pm »
I never actually tried to run the downloads, so it's good to hear they're working as intended. Just curious, is there anyone who will be using the 32 bit version?

I will be having it around.  I have potential users for some of my RPGWare apps that need 32bit.



RPGWare = RPG Software Tools ; Circa 95% of my QB64 work is still on or about various RPG oriented tools. RPG = Role Playing Games    I do not use the other 2 common definitions for RPG and probably never will thankfully. 

5
QB64 Discussion / Re: My QB64 debut anniversary
« on: January 01, 2019, 07:42:57 pm »
Hi EricR,

Fifi,
If Microsoft thinks that it can change the kernel that much and force it upon all of its Win10 users without complications, I think there will be a reckoning.  Unless Microsoft somehow makes it so all current and future 64bit Windows exe can run on that Linux kernel without error, they may force people to do something drastic like stop upgrading and use potentially not so clean methods to block mandatory updates.  The not so clean updates block could happen lest a pure Windows be replaced by this Lindows without user consent and then all those exe's that are not compatible cease running.  That will surely make people real angry at Microsoft.  Just take a walk through any decent competent tech forum after a botched update and you will get the gist if you do not now.

I'm sorry to not be a perfect English speaking guy but I don't think I said (or wrote) MSFT is currently trying to "exchange" its own kernel with (by) a Linux Kernel.

From what I heard from my friend (as a matter of fact, a very top ranking MSFT manager I used to deal with for over 30  years, so we still are very dear friends especialy since I'm retired), what he said to me that MSFT is currently working on 2 other OSes, the "lite" I already talk about that will be a "pure" 64 bit OS withoit any 32 bit code support, and the other internaly called Lindows, using a Linux 4.xx kernel and on the top of which they "port" their UI (with all its API's calls).

So, any "clean" program running on Windows 10 "should" run on this "next" OS unless they wrongly use undocumented APIs or very specific system calls.

Just to sustain such an approach: remember that the IBM Vancouver Lab "ported" the OS/2 Presentation Manager Workplace Shell from the OS/2 kernel to the DOS-Windows kernel within less than a year.

BTW, MSFT will ask more time than a year to do so because they just don't know how to code with small and efficient dev teams, the main "reason" being the place of "politics", what IBM used to call the "barons" defending their own little chapel.

Happy new year season.
Fifi

Fifi,
You did not.  It was my direct interpretation of your statement.  For me, if someone says "I will be using Lindows" then I see a Windows like OS based on Linux in my head.  Right or wrong, that is how I see it.  Bottom line for me on this is simple. If Microsoft changes its Windows platform too much, there will be a reckoning from its user base imo.  I can not see Microsoft having any other result.  The change from 32bit to 64bit will happen without significant feedback imo.  If a future Windows OS release makes it so all prior Windows compatible code is now worthless, oh boy.  The people in Redmond, State of  Washington will hear about it.

6
QB64 Discussion / Re: My QB64 debut anniversary
« on: January 01, 2019, 07:37:40 pm »

Unless the linux kernel has gotten really weird, it should run just fine.  As far as I know, all operating systems can handle programs that are byte compiled less than the current size as long as the run time files and required OS support for that size ( 32bit in this case ) exist.  Luke will probably come around soon and correct me if I am wrong.

I'm here to correct you :)
As a general rule you can't run 32 bit programs on a 64 bit installation because it won't load dynamic libraries correctly. You can install 32 bit compatibility libraries but no-one does that unless they're stuck with 32 bit binaries they need to run (basically you need to install a 32bit version of every library the program needs).

Ok    Thank you     It does seem odd yet I do not want argue otherwise.    IMO  Windows gets something right concerning this "less than current DWord byte size" thing. 

7
QB64 Discussion / Re: My QB64 debut anniversary
« on: December 17, 2018, 02:28:38 pm »
Hi EricR and Bert22306,

From what I know from a very serious insider (a very old friend in the Redmond labs), MSFT is currently working, beside "enhancing" Windows 10, on two different OS projects.

One is currently called "Windows Lite" and is only 64 bit without any support of 32 bit code. The goal of this version is to reach tiny computers such as Pi or Ebook.

The second doesn't have a real name yet but is internaly called "Lindows". This project is also a full 64 bit product but is based on a Linux kernel and will provide a brand new interface. It's currently managed by a part of the Azure team.

Still from my contact, none of these two projects would come public even as alpha release for MSFT partners before 2020.

Nevertheless, the "reign" of 32 bit for Windows and Linux will end sooner than later and I think that the QB64 dev team should definitly focus on the 64 bit version.

Just my two cents.

Kind regards.
Fifi

Fifi,
If Microsoft thinks that it can change the kernel that much and force it upon all of its Win10 users without complications, I think there will be a reckoning.  Unless Microsoft somehow makes it so all current and future 64bit Windows exe can run on that Linux kernel without error, they may force people to do something drastic like stop upgrading and use potentially not so clean methods to block mandatory updates.  The not so clean updates block could happen lest a pure Windows be replaced by this Lindows without user consent and then all those exe's that are not compatible cease running.  That will surely make people real angry at Microsoft.  Just take a walk through any decent competent tech forum after a botched update and you will get the gist if you do not now.


8
QB64 Discussion / Re: My QB64 debut anniversary
« on: December 17, 2018, 02:09:56 pm »
What I think would work nicely, would be to strip the compiler completely out from the Windows versions.  The way I’d envision it working would be:

1)Let folks download QB64 as a zip/7z fileand extract it to a folder of their choosing.
2)Let folks download the compiler they want to use (if they need one), with an install script included.
3)Folks then click the installer we package with that compiler, point to the QB64 folder without a compiler installed, and it finishes the setup by extracting itself in the proper folder and building QB64.

The advantages to this is a great reduction of download size for folks on limited bandwidth.  Grab one compiler/installer, save it in somewhere on your hard drive, and you never have to download it again. 

We change QB64.bas.  We change libqb.cpp.  We swap in and out various libraries as time goes by...  But we haven’t changed the version of the compiler packaged with QB64 since...  EVER.

I would like to see this happening.  In addition to the limited bandwidth folk who use QB64, there is the perceived need by myself and who knows how many others to make *this* a reality.

A) QB64 IDE alone    No compiler
B) 32bit compiler by OS
   1) 7zip / Zip archive format ; DIY format
   2) Installer / Install script with bin / exe
   3) SI SFX compiler bin / exe with official IDE
C) 64bit compiler by OS
   1) 7zip / Zip archive format ; DIY format
   2) Installer / Install script with bin / exe
   3) SI SFX compiler bin / exe with official IDE

I do admit that this desired setup scheme would require space on the web host and a willing QB64 team.   Still, I think this would be best long term. 
I am aware that #3 for compilers is a "Wish for the moon" type desire.  I know freeware and open sourcee SI SFX installers for Windows exist.   
I am not sure if such SI-SFX exists in Linux / Mac based on Linux right now or not.   It has been too long since I had a fully operational Linux distro
on any hard drive. 

For those like myself who appreciate third party IDE's, we are normally capable enough to install those ourselves imo. 
I do wish to point out the super obvious.   We have had this idea of separating the IDE and compiler before.   It came up at least twice on the now defunct QB64 dot net site.  Call me what
ever you wish, I do personally believe this full separation of compiler and IDE must, absolutely must, happen for the long term benefit of QB64.   

And if we are going to continue this, we need our own new thread.  This is supposed to be all about Fellippe's QB64 anniversary.   We are getting seriously off topic. 


Edit 02:
1) I had one more comment.
2) I had a grammar error that needed squishing bad.   I had 32bit twice when I meant 32 bit and 64bit.




9
QB64 Discussion / Re: QB64 Offline Wiki
« on: December 17, 2018, 01:51:05 pm »

Fellippe:
Thank You   

I will rebuild the offline wiki after I see the "for now" missing commands show up in the online wiki. 

10
QB64 Discussion / Re: How do you guys keep track of your files?
« on: December 17, 2018, 01:49:19 pm »

Projects:
I have one folder per programming language and then have separate folders for each project as a general rule.  Sometimes I break this rule though.   

QB64 itself:
I have QB64 in three folders.   
A) QB64  32bit  Official IDE & compiler plus minor off shoot projects and cutting edge source code
B) QB64  64bit  Official IDE & compiler plus minor off shoot projects and cutting edge source code
C) QB64  Common        Mixed QB64 files that are common to all QB64 projects and QB64 itself
D) Compressed QB64, Compressed QB64 Tools, posts, MinGW, and many older QB64 zip/7zip archieves 
I will keep the most modern source code and 2 maybe 3 earlier incarnations of it.   Older source code can and does get wiped. 
I do not bother with anything other than the most modern compiled code. I will seldom backup that exe as I can always recompile the source code.

I had it virtually beat into my head the importance of folders, sub folders, and sub sub folders back in my DOS days. 


11
QB64 Discussion / Re: My QB64 debut anniversary
« on: December 16, 2018, 01:49:57 pm »
Fifi,
01) I do agree most vendors are removing 32bit support.   It is not IF all 32 support is removed from mainstream software and OS vendors, it is When does it happen. 
02) On Microsoft creating the next version of Windows, I thought it would be Windows 10 name until Windows OS ceased to exist. I may have that wrong. 
03) Windows 10 will probably cease offering 32bit support sometime after mid 2021 for the 64bit editions.  Given Windows 10 does still exist in pure 32bit form,  I am not sure what will happen to 32bit editions.  More likely than not, final end-of-life support will occur.  Those who have a 32bit edition of Windows 10 should start thinking about what they are going to do shortly.
04) I do not know what Visual Studio you are using.  I have Visual Studio 2017 Community which does allow console apps for now.  Visual Studio 2019 Community Preview does allow console
programs to be created.   I am on Windows.

12
QB64 Discussion / Re: My QB64 debut anniversary
« on: December 16, 2018, 01:29:52 pm »
I mean for compiled binaries. I ship both the 32bit and 64bit compiled versions of InForm's Linux installer because, unlike Windows, I don't know if the 32bit version will run on a 64bit Linux system.

Unless the linux kernel has gotten really weird, it should run just fine.  As far as I know, all operating systems can handle programs that are byte compiled less than the current size as long as the run time files and required OS support for that size ( 32bit in this case ) exist.  Luke will probably come around soon and correct me if I am wrong. 

13
QB64 Discussion / QB64 Offline Wiki
« on: December 16, 2018, 01:00:37 pm »
Hello all,
When I use QB64, I want a copy of the wiki handy.  Between everything in my personal life going on,  working on my master's degree, and others I can not remember all the QB64 commands.  So I created an offline copy of QB64 wiki.   I am either not looking in the right spot or there is no offline QB64 wiki.  I do not know which. 

This is a copy of the QB64 Wiki I made via HTTrack.  I will leave this 7zip copy of offline wiki until I create a new one.
Compressed Size      @36 MB
Uncompressed Size           @235 MB
https://www.dropbox.com/s/xgwsvswlwmabqz5/QB64%20Wiki%2012152018.7z?dl=0

You will need a uncompressor that undertands 7zip.  As I remember a core QB64 team member, there is a copy inside the Ming GW compiler. 
An easier way is go get a file archiever like 7Zip or Peazip with both free to download and use.  The choice is yours. 

I will create periodic updated versions of this offline wiki and post them. 


PS: QB64 Team:
Who is working on the wiki?    There is at least one command that has worked for weeks that I know of and it is not present in this wiki.  I am not trying to
step on anyone's toes here.  I am curious if anyone is working on the wiki for maintenance and update purposes.  Clippy really did a good job on the wiki even if he was a pain other times. 

Pages: [1]