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.
Join the live talk at Discord.
Be part of the conversation at
http://discord.qb64.org.
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.
Maybe we need a Rube Goldberg programing challenge!
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?
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
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).
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
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 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.