QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: FellippeHeitor on December 13, 2018, 08:19:38 am
-
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.
-
Feliz aniversário
-
Contributors, such as yourself are QB (ie Quite Brilliant)
-
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
-
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.
-
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.
-
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.
-
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).
-
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 (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
-
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.
-
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
-
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.
-
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
-
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.
-
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
-
Hi SMcNeill,
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.
Just a question (not a critic):
Why the download pages (stable and dev) don't propose both the 32 bit and 64 bit versions of QB64 for each OS as Fellippe does for InForm but only for Linux?
Question to Fellippe (again not a critic):
Why the InForm download page doesn't propose a 32 bit and a 64 bit version for Windows as you do for Linux?
Kind regards.
Fifi
-
I know the 32bit Windows version works on 64bit Windows. I never bothered to check if the same holds true for Linux, that's why.
-
I know the 32bit Windows version works on 64bit Windows. I never bothered to check if the same holds true for Linux, that's why.
From what I remember, Linux doesn’t package ANY compiler with QB64. You download the one that works for your OS, and it uses that one.
If there’s multiple compilers on a Linux machine, I dunno how it chooses which to use. Default associated with c files, I guess? Luke may have a better idea for how it chooses from multiple compilers on Linux.
-
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.
-
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.
-
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.
-
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.
Supposedly, from what Microsoft has said so far, Windows 10 will be it. But that doesn't really mean it's always the same OS. Microsoft seems to have settled on a schedule of two major updates per year, where by "major," I mean a whole new OS. Version 1809 was particularly big, it seems, as the upgrade required four reboots of the machine. Very much like the original installation of Windows 10.
So who knows. Could be that as the years go by, Windows 10 will look very different from what it was on July 29, 2015.
(My question is, what happens with the enterprise version of Windows 10? Enterprise nets hate to make huge OS updates. No enterprise I know of would put up with two OS changes per year.)
-
Happy Birthday Fellippe
https://www.ricettedigusto.info/wp-content/uploads/2013/11/Torta-di-compleanno-con-pan-di-Spagna-e-crema-chantilly.jpg (https://www.ricettedigusto.info/wp-content/uploads/2013/11/Torta-di-compleanno-con-pan-di-Spagna-e-crema-chantilly.jpg)
Maintenance and develop of QB64 is not just like a walking.
Thanks to you and the other coders that spent time, efforts and enery to this beautiful project.
-
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
-
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.
...
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.
Interesting. Deprecating 32-bit is probably not too surprising, so I agree that at some point, might as well make the main qb64 download the 64-bit variety. Perhaps we should have a survey to see whether anyone still needs a 32-bit version of qb64? Even smartphones are 64-bit these days.
On the Windows with Linux kernel, it's possible that Microsoft would make that one of their Windows 10 big so-called "feature updates"? I mean, these big updates incorporate everything, including new device drivers. Not sure how this could be choreographed with the simultaneous changes in apps. Built-in VMs?
Anyway, how odd it would be, for all Mac and PC OSs to be based on Unix (Mac OS already is). I guess that's how technology evolves, though. Eventually, one winner does tend to emerge.
-
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 like that idea and I would also include a separate download of the samples programs. I just don't extract those anymore when updating.
Pete
-
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.
-
Wow
IMHO this is a very revolution towards Linux world....
many indipendent subsets into one package... so no waste downloading the same files (compiler, examples, source code of Frameworks, fonts etc etc) but you can choose to download only those are updated, and/or what you need to have/adjourn.
Fantastic modular modern downloading....
-
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.
-
QB64 is what re-woke my dusty DOS programming into the new world!
Thank you,
Maybe a history book should be in the works of everyone major behind the effort.
-
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
-
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.
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).
-
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.
-
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.