Author Topic: My QB64 debut anniversary  (Read 11267 times)

0 Members and 1 Guest are viewing this topic.

Offline pagetelegram

  • Newbie
  • Posts: 24
  • "werd" - meaning mutual consensus or understanding
    • View Profile
    • Page Telegram
Re: My QB64 debut anniversary
« Reply #30 on: December 17, 2018, 06:23:53 pm »
  • Best Answer
  • 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.
    Page Telegram
    <PageTelegram.com>
    Document Writing
    Author and Philanthropist
    BBM: PT0433
    Books at https://www.amazon.com/Jason-S-Page/e/B071RS8C2F/

    Offline Fifi

    • Forum Regular
    • Posts: 181
      • View Profile
      • My small QB64 contribution
    Re: My QB64 debut anniversary
    « Reply #31 on: December 18, 2018, 02:29:48 pm »
  • Best Answer
  • 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
    It's better to look like an idiot for a short time while asking something obvious to an expert than pretending to be smart all your life. (C) Me.

    Offline luke

    • Administrator
    • Seasoned Forum Regular
    • Posts: 324
      • View Profile
    Re: My QB64 debut anniversary
    « Reply #32 on: December 23, 2018, 01:53:08 am »
  • Best Answer
  • 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).

    Offline EricR

    • Newbie
    • Posts: 13
    • Loading humor.sys should be mandatory at boot
      • View Profile
    Re: My QB64 debut anniversary
    « Reply #33 on: January 01, 2019, 07:37:40 pm »
  • Best Answer

  • 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. 

    Offline EricR

    • Newbie
    • Posts: 13
    • Loading humor.sys should be mandatory at boot
      • View Profile
    Re: My QB64 debut anniversary
    « Reply #34 on: January 01, 2019, 07:42:57 pm »
  • Best Answer
  • 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.