• Please review our updated Terms and Rules here

RUNNING PROGRAMS WRITTEN IN GWBASIC 32 BIT SOFTWARE ON A 64 BIT HP ENVY RUNNING WINDOWS 11 HOME VERSION.

gadams24

New Member
Joined
Apr 14, 2026
Messages
5
Back in the late 80's and early 90's, I was writing and running programs I wrote in 32 bit, GWBASIC. Suddenly, we got new PCs at work and I bought a new PC at home and I discovered these programs wouldn't run any more because the GWBASIC software was 32 bit and my hardware was all 64 bit. Being a rank amateur I had no idea what this meant and I'm still not sure but I have a need to try and run and maybe improve my programs but I have no way to do this simply. Can anyone in this forum offer me possible solutions to my problem? Please keep in mind I am a rank amateur in this world and would appreciate you dumbing down your explanations as low as you can as I am 75 years old and on the verge of senility, so please KISS for me.

Thank you,
Playboy Hop "93
 
Back in the late 80's and early 90's, I was writing and running programs I wrote in 32 bit, GWBASIC. Suddenly, we got new PCs at work and I bought a new PC at home and I discovered these programs wouldn't run any more because the GWBASIC software was 32 bit and my hardware was all 64 bit. Being a rank amateur I had no idea what this meant and I'm still not sure but I have a need to try and run and maybe improve my programs but I have no way to do this simply. Can anyone in this forum offer me possible solutions to my problem? Please keep in mind I am a rank amateur in this world and would appreciate you dumbing down your explanations as low as you can as I am 75 years old and on the verge of senility, so please KISS for me.

Thank you,
Playboy Hop "93
O.K. I've downloaded PC BASIC 2.0 application but doesn't do anything. None of the keyboard buttons work. Nothing happens. I get the feeling I'm missing something. Can you help, please?
 
You can also consider running the exact OS, interpreter and tools you are used to under some virtualization software like for example VirtualBox
 
I was writing and running programs I wrote in 32 bit, GWBASIC. Suddenly, we got new PCs at work and I bought a new PC at home and I discovered these programs wouldn't run any more because the GWBASIC software was 32 bit and my hardware was all 64 bit.

No, you were writing and running 16 bit programs as GWBASIC is a 16 bit interpreter. The trick is that your 32 bit PC has all the compatibility it needed to run old 16 bit stuff, but modern 64 bit PCs don't. The CPUs don't support 16-bit mode of execution and operating systems do not have the compatibility layers anymore.

Just install Dosbox and run your stuff in there.
 
https://robhagemans.github.io/pcbasic/ will run most GW-BASIC programs under 64-bit Windows. BASIC programs involving PEEK/POKE or other direct hardware access are unlikely to work.
PC-BASIC is probably the best solution for OP. Dead simple to install and run.

PEEK/POKE does work to some extent; some of the BDA is there, along with video memory and the BASIC segment. The main feature missing is CALL, so all your code has to be BASIC.
 
No, you were writing and running 16 bit programs as GWBASIC is a 16 bit interpreter. The trick is that your 32 bit PC has all the compatibility it needed to run old 16 bit stuff, but modern 64 bit PCs don't. The CPUs don't support 16-bit mode of execution and operating systems do not have the compatibility layers anymore.

Just install Dosbox and run your stuff in there.
Thanks. What is Dosbox and where can I get it? I think I may have DOS on my computer but I don't remember how to get to it. If I do have DOS, should I be able to run PC- BASIC since I've installed it? Also, I can only find it in my downloads file. I don't think this is right. Where should the software have been installed?
 
Thanks. What is Dosbox and where can I get it? I think I may have DOS on my computer but I don't remember how to get to it. If I do have DOS, should I be able to run PC- BASIC since I've installed it? Also, I can only find it in my downloads file. I don't think this is right. Where should the software have been installed?
You don't need DOS or DOSBox for PC-BASIC. Once you've installed it, it will be in the Start menu. Click the Windows icon and type "pcbasic" and it will come up.

Once PC-BASIC is started, the default directory is your Documents folder. If your .BAS files are somewhere else, you can use CHDIR to change to that directory. For example:
CHDIR "C:\BASIC"

DOSBox/DOSBox-X are full DOS emulators. If you have other DOS programs you want to run, it could be useful. But it is more complex than PC-BASIC.
 
O.K. I've downloaded PC BASIC 2.0 application but doesn't do anything. None of the keyboard buttons work. Nothing happens. I get the feeling I'm missing something. Can you help, please?
Are you seeing the black screen that says PC-BASIC at the top? You may need to click on the window to get it in focus before you can type.

I also see you have a laptop. Many newer laptops repurpose the function keys by default. You may need to hold the Fn key (lower left) while pressing F1-F12.
 
Are you seeing the black screen that says PC-BASIC at the top? You may need to click on the window to get it in focus before you can type.

I also see you have a laptop. Many newer laptops repurpose the function keys by default. You may need to hold the Fn key (lower left) while pressing F1-F12.
Thank you so much for all of your assistance. You are so cool! You're absolutely GREAT!!! Now my keyboard works and I did run into that function key issue but I figured it out before I read your comment. Now, I have some old GWBASIC programs on an external drive that I would like to transfer to my laptop. I was going to try to use my file explorer and drag pcbasic to a new folder I'm going to create on my C drive where I plan to store all of my basic programs but I can't seem to find anything called pcbasic on the file explorer. Not in the documents folder or anywhere else. Am I going about this correctly or not?
 
By default it installs to your user AppData folder which is hidden. Instead of moving the files, it would be better to uninstall it and reinstall to the location you want.
  • Run the installer that you downloaded (PC-BASIC-2.0.7).
  • Select "remove" and it will uninstall.
  • Run the installer again.
  • Select "install for all users"
  • When it asks for destination directory, select or type where you want it to go (e.g. "c:\basic")
 
You might be able to run the original GWBASIC.EXE using OTVDM.
By default it installs to your user AppData folder which is hidden. Instead of moving the files, it would be better to uninstall it and reinstall to the location you want.
  • Run the installer that you downloaded (PC-BASIC-2.0.7).
  • Select "remove" and it will uninstall.
  • Run the installer again.
  • Select "install for all users"
  • When it asks for destination directory, select or type where you want it to go (e.g. "c:\basic")
Thank you so much for your help. I'll try and do this right away and let you know if I have any issues.
 
No, you were writing and running 16 bit programs as GWBASIC is a 16 bit interpreter. The trick is that your 32 bit PC has all the compatibility it needed to run old 16 bit stuff, but modern 64 bit PCs don't. The CPUs don't support 16-bit mode of execution and operating systems do not have the compatibility layers anymore.

Just install Dosbox and run your stuff in there.

Not really related, but as far as I know you can most certainly run 16-bit code directly on most 64-bit Intel CPUs.

Without a full compatibility layer, you would need the CPU to be in 32-bit mode for access to Virtual 8086 mode or in 16-bit mode. And in either situation you would have to run a 32/16-bit operating system.

I don't fully understand, but the newer chips primarily have "legacy mode" and "long mode", where the former protected mode and real mode are sub-modes of the former.
 
You're correct, of course.
What I was referring to, is "I was writing and running programs I wrote in 32 bit, GWBASIC. Suddenly, we got new PCs at work and I bought a new PC at home and I discovered these programs wouldn't run any more because the GWBASIC software was 32 bit and my hardware was all 64 bit".

In that context I was clarifying that GWBASIC and the code were always 16-bit but the 32-bit PC and the OS provided compatibility. 64-bit PC and the OS cannot.

The OP probably moved from standard Windows XP to a 64-bit successor and lost ability to run his 16-bit stuff unknowingly.
 
In that context I was clarifying that GWBASIC and the code were always 16-bit but the 32-bit PC and the OS provided compatibility. 64-bit PC and the OS cannot.

The OP probably moved from standard Windows XP to a 64-bit successor and lost ability to run his 16-bit stuff unknowingly.

I think you're right on. This means that the OP was "correct" figuratively, but incorrect technically.

Good concise explanation of the situation.
 
Maybe it's worth adding that point of amd64 and long mode is to get rid of segmentation and introduce far better paging structures. They said they would really need to slap on extra interfacing circuitry, increase the die size and power usage to enable vm86 to run. So OS vendors have nothing to do with not having 16-bit support in long mode.
 
I don't think that prevents any OS developer from writing a compatibility/emulation layer in software to handle 16-bit software.

It might have been painful, but Microsoft could have made a separate WOW64-like layer for 16-bit applications or possibly added on top of WOW64 to pass the 16-bit stuff through an additional 16 bit --> 32 bit step.

The bigger problem here is dealing with software that expects to directly access the hardware. Most 32-bit software that anyone cates about probably relies on drivers to access hardware. So if you have a 64-bit driver for the hardware I would guess that Windows can make things work.
 
I don't think that prevents any OS developer from writing a compatibility/emulation layer in software to handle 16-bit software.

One of the reasons to migrate to amd64 is to drop all the compromises gathered along the way, sourced from the lineage of first PC being a really really simple and cheap machine. The protected mode builds on 8086 because it has to, Intel tried a more "pure" mode with 286 and failed hard. It doesn't include VM86 because it's a worthwhile feature, it is a baseline thing coming from the primary requirement of being fully compatible with 8086 from the get go. 20 years ahead, that stuff became an impediment for the evolution of the platform and it was dropped. The new platform architecture was created, that can accomodate the old way, the new way, but cannot mix them, so the new way isn't hampered by compatibility burden, not only in realization but in CPU design.

"Native" software that does not directly access the hardware does not exist, that's the point of it. A memory operation is direct hardware access. In x86 we have segment : offset. In amd64 long mode memory is flat and segment registers are not used for the same purpose. In protected mode, opcodes that set up <1MB memory r/w hit a segmentation fault. In long mode, the same opcodes cannot set up the <1MB access through seg : off. No instructions can. Therefore the code is not able to perform one of its primary functions.

Addressing is only one problem there are still paging and cache coherency issues which are much more complex.

The bottom line is CPU in long mode cannot run 8086 code directly. In protected mode it runs directly, but hits fences. VM86 is a trip through those fences.

So, that is my opinon why it is impossible to create a purely software compatibility layer. Maybe I'm wrong and not looking into depth enough.

Emulation (not compatibility layer)...there were many dynamic recompilers and JIT available at the age of transition, even in late 90s there was a PC-on-PC emulator Bosch already in decent state, and people were expected to run 32 bit OS for some time to come. So yeah there was actually always an option to somehow run 16 bit code on 64 bit OS through emulation, I guess even Microsoft's "Virtual PC" could run DOS, so users still had a way.
 
There are bugs in the implementation of 16-bit modes on some of the more recent 64-bit CPUs. I imagine there are so many edge cases and unexpected behaviors that completely testing all the CPU operations would be nearly impossible. It is probably a good thing that users need to reboot out of 64-bit modes to encounter those problems.

I do miss the loss of XP mode. Easily being able to run 16-bit and incompatible 32-bit software on a 64-bit system was nice. I know about the other tools to do it but those can take a lot of work if something goes wrong.
 
Back
Top