You are not logged in.
Computers have gone through multiple generations in the lifetimes of NewMars members.
This topic is available for NewMars members who might care to share information about compatibility issues, or historical notes or even just recollections of bygone days.
The opening post #3 will be about how to run a 16 bit application on a 32 bit machine and (not) on a 64 bit machine.
(th)
Offline
Like button can go here
This post is reserved for an index to posts that may be contributed by NewMars members.
Index:
#3 .... transcript of conversation with Gemini about running a 16 bit application from Windows 98 era on a 32 bit Windows XP and (not) on a 64 bit Windows 11 system.
(th)
Offline
Like button can go here
This post is inspired by the Google Meeting of 2025/06/29...
In that meeting, GW Johnson attempted to run a 16 bit application on a 64 bit Windows 11 machine.
The application did not run. Meanwhile, that same application DID run without problems of any kind on Windows XP on a 32 bit Dell laptop.
Show more
Conversation with Gemini
Running 32 bit exe on 64 bit Windows 11It's generally not an issue to run 32-bit executables (EXEs) on a 64-bit Windows 11 system. Here's why and what you might encounter:
How it Works (WoW64)
Windows 64-bit operating systems include a compatibility layer called WoW64 (Windows 32-bit on Windows 64-bit). This layer allows the 64-bit OS to seamlessly execute 32-bit applications. When you launch a 32-bit program, WoW64 intercepts the calls it makes and translates them into a format that the 64-bit operating system can understand.
What You Can Expect
Most 32-bit applications will run without any problems. For the vast majority of older software, you won't even notice that it's a 32-bit application running on a 64-bit system.
Performance: There's usually no noticeable performance penalty for running 32-bit applications through WoW64.
File System and Registry Redirection: WoW64 also handles redirection for file system and registry access. This means that 32-bit applications trying to access system folders (like Program Files) or registry keys will be redirected to their 32-bit counterparts (like Program Files (x86) or a specific section of the registry for 32-bit applications). This ensures that 32-bit and 64-bit applications don't conflict with each other's files or settings.
Potential Issues (Less Common)
While most 32-bit applications run fine, a few scenarios might cause problems:
Very Old or Low-Level Software: Extremely old software, especially those that interact directly with hardware in non-standard ways, or low-level utilities that bypass standard Windows APIs, might encounter compatibility issues.
Drivers: 32-bit drivers are not compatible with 64-bit Windows. If a 32-bit application relies on a specific 32-bit hardware driver, it won't work. You'll need a 64-bit version of the driver for the hardware to function.
16-bit applications: Windows 11 (and even Windows 10) does not natively support 16-bit applications. If your "32-bit EXE" is actually a very old 16-bit application (which was common in early Windows versions), it will not run. For these, you'd need a virtual machine running an older version of Windows (like Windows XP) or a third-party emulator like DOSBox.
DRM or Copy Protection: Some older applications with complex Digital Rights Management (DRM) or copy protection schemes might have issues, as these often rely on low-level system access that can be affected by the WoW64 layer.
In summary, for the vast majority of 32-bit applications, you can simply double-click and run them on your 64-bit Windows 11 system without any special configuration. If you do encounter an issue, it's more likely due to a very specific and unusual circumstance, like a missing 64-bit driver or the application being a true 16-bit program.
Sources
***
Thank you for this helpful opening evaluation of our situation. I suspect this is indeed a 16 bit application, even though it runs fine on my 32 bit Windows XP. The application is a clone of QuickBASIC for computers of the 1990 era. The words inside the BAS file appear to be 16 bits in length. Is there any way I can confirm the application is operating in 16 bit mode?
***
You're likely correct in your suspicion that it's a 16-bit application if it's a QuickBASIC clone from the 90s and runs on Windows XP. Windows XP still had native support for 16-bit applications through the NTVDM (NT Virtual DOS Machine), which is not present in 64-bit versions of Windows (including Windows 11).Here's how you can confirm if an application is 16-bit, and what to do if it is:
How to Confirm if an Application is 16-bit
Try to Run It on Windows 11 (Directly):
The most straightforward way to confirm is to simply try to run the EXE on your 64-bit Windows 11 machine.If you get an error message like: "This app can't run on your PC" or "The version of this file is not compatible with the version of Windows you're running," or "Unsupported 16-bit application," then it's almost certainly a 16-bit application. This is because 64-bit Windows does not include the NTVDM.
Check the "Properties" of the Executable:
Right-click on the executable file (the .exe file).
Select "Properties."
Look for a "Compatibility" tab.
If you see a "Compatibility" tab with options for older Windows versions (like Windows 95, 98, ME, or XP) and these options are not greyed out, it suggests it's a 32-bit application. 32-bit applications have more compatibility modes.
If the "Compatibility" tab is entirely missing, or if the options are very limited and don't include older pre-XP Windows versions, it's a strong indicator that it might be a 16-bit application. 16-bit applications often lack these extensive compatibility settings on modern Windows.
Use a Third-Party Tool (for deeper analysis):
If you want a definitive answer without guessing, you can use a tool that analyzes executable headers:Sigcheck (from Sysinternals): This is a command-line utility from Microsoft that's excellent for checking file information, including bitness.
Download Sigcheck from Microsoft's Sysinternals page.
Open Command Prompt and navigate to the directory where you saved sigcheck.exe.
Run the command: sigcheck.exe C:\Path\To\Your\Application.exe (replace with the actual path).
Look for "MachineType" in the output.
IMAGE_FILE_MACHINE_I386 usually indicates a 32-bit executable.
IMAGE_FILE_MACHINE_UNKNOWN or a very low-level machine type might indicate a 16-bit DOS or Windows 16-bit executable.
16-bit Windows EXEs (NE format) and DOS EXEs (MZ format) have different internal structures than modern PE (Portable Executable) format EXEs. Sigcheck will generally identify if it's not a standard 32-bit or 64-bit PE file.
"file" command (from GNU Core Utilities for Windows or Git Bash): If you have Git Bash installed, you already have the file utility, which is very good at identifying file types.
Open Git Bash.
Navigate to the directory of your EXE.
Run file your_application.exe
The output will often clearly state if it's a "PE32 executable" (32-bit) or if it identifies it as an "MS-DOS executable" or "New Executable (NE)" which indicates 16-bit.
Examine the Executable with a Hex Editor:
This is more advanced but can be very telling. Open the .exe file in a hex editor.All DOS and Windows executables start with "MZ" (ASCII characters).
For 32-bit (PE) executables, you'll usually find "PE" followed by two null bytes (00 00) at an offset specified in the MZ header (usually at 0x3C from the start of the file, this offset points to the PE signature).
For 16-bit Windows executables (NE - New Executable format), you'll find "NE" somewhere after the "MZ" header instead of "PE".
For pure 16-bit DOS executables, you generally won't find "PE" or "NE" at a standard offset.
What to Do if it's a 16-bit Application
As you've correctly surmised, 64-bit Windows 11 does not natively support 16-bit applications. You have a few options:Virtual Machine (Recommended):
This is the most reliable and common solution. Install a virtual machine (VM) software like:VirtualBox (Free): Easy to set up.
VMware Workstation Player (Free for personal use): Also a solid choice.
Hyper-V (Built into Windows 10/11 Pro/Enterprise): If you have a Pro or Enterprise edition, you can enable Hyper-V and create a VM.
Then, install a 32-bit operating system inside the VM that supports 16-bit applications, such as:
Windows XP (32-bit): Since it runs fine there, this is the most logical choice.
Windows 98/ME: If Windows XP still gives you trouble, these are even older.
MS-DOS or FreeDOS: If it's a pure DOS application (like many QuickBASIC programs were), a DOS VM might be even more efficient.
DOSBox:
If the application is primarily a DOS-based program, DOSBox is an excellent emulator specifically designed for running old DOS games and applications. It creates a virtual DOS environment.Winevdm (Third-Party Solution):
There's an open-source project called Winevdm (often found on GitHub) that aims to provide 16-bit application support on 64-bit Windows. It's essentially a reimplementation of the NTVDM. It's not officially supported by Microsoft, but many users have found success with it for running certain 16-bit applications. You'd typically download the release and run your 16-bit EXE with the otvdm.exe executable from Winevdm.Given that your application is a QuickBASIC clone from the 90s and runs on 32-bit Windows XP, it's highly probable it's a 16-bit DOS or 16-bit Windows application. A virtual machine with Windows XP or DOSBox would be your best bet for continued use on Windows 11.
***
Thank you for this ** really ** helpful advice! I'll pass it along to the folks who are directly involved, and will also share it with our forum in case someone in future faces a similar problem.
***
You're most welcome! I'm glad I could provide helpful information that you can use and share. It's a common challenge to keep older, valuable software running on modern operating systems, and knowing the right tools and approaches makes a big difference.Please feel free to reach out if you or your colleagues have any more questions as you implement these solutions. Good luck with getting your QuickBASIC clone up and running on Windows 11!
GW Johnson reported seeing the exact error messages described by Gemini for the 16 bit application.
(th)
Offline
Like button can go here
The QB.EXE file is available to study on this Linux box, so here are a few bytes from the top of the file:
hd -n 100 QB.EXE
00000000 4d 5a 14 01 21 02 c4 07 00 02 e4 00 ff ff 55 42 |MZ..!.........UB|
00000010 00 0a 66 12 88 39 1a 24 1e 00 00 00 01 00 a1 03 |..f..9.$........|
00000020 48 0d 2b 03 48 0d b6 02 48 0d 7b 02 48 0d 4d 02 |H.+.H...H.{.H.M.|
00000030 48 0d 1c 02 48 0d d7 01 48 0d af 01 48 0d 6a 01 |H...H...H...H.j.|
00000040 48 0d 62 01 48 0d 59 01 48 0d 50 01 48 0d 47 01 |H.b.H.Y.H.P.H.G.|
00000050 48 0d 1f 01 48 0d fe 00 48 0d f5 00 48 0d e5 00 |H...H...H...H...|
00000060 48 0d d8 00 |H...|
00000064
Quoting from transcript with Gemini:
For 16-bit Windows executables (NE - New Executable format), you'll find "NE" somewhere after the "MZ" header instead of "PE".
For pure 16-bit DOS executables, you generally won't find "PE" or "NE" at a standard offset.
(th)
Offline
Like button can go here
And here is a follow up conversation with Gemini about the hex dump of the beginning of the QB.EXE file:
I have posted the transcript of our conversation, and went on to take a hex dump of the start of QB.EXE. Here is the output. I'm wondering if you recognize the "UB" code at offset x'0E'?
hd -n 100 QB.EXE
00000000 4d 5a 14 01 21 02 c4 07 00 02 e4 00 ff ff 55 42 |MZ..!.........UB|
00000010 00 0a 66 12 88 39 1a 24 1e 00 00 00 01 00 a1 03 |..f..9.$........|
00000020 48 0d 2b 03 48 0d b6 02 48 0d 7b 02 48 0d 4d 02 |H.+.H...H.{.H.M.|
00000030 48 0d 1c 02 48 0d d7 01 48 0d af 01 48 0d 6a 01 |H...H...H...H.j.|
00000040 48 0d 62 01 48 0d 59 01 48 0d 50 01 48 0d 47 01 |H.b.H.Y.H.P.H.G.|
00000050 48 0d 1f 01 48 0d fe 00 48 0d f5 00 48 0d e5 00 |H...H...H...H...|
00000060 48 0d d8 00 |H...|
***
That's an excellent idea to examine the hex dump! It provides concrete evidence.Let's break down your hex dump:
00000000 4d 5a 14 01 21 02 c4 07 00 02 e4 00 ff ff 55 42 |MZ.!.........UB|
00000010 00 0a 66 12 88 39 1a 24 1e 00 00 00 01 00 a1 03 |..f..9.$........|
...
Interpretation of the Hex Dump:4d 5a (MZ) at offset 00000000:
This is the definitive signature of a DOS executable. All DOS and Windows executables begin with MZ (which stands for Mark Zbikowski, one of the developers of MS-DOS). This confirms it's at least a DOS-compatible executable.The "UB" at offset 0E (0x0E) and the surrounding bytes:
This is where it gets interesting. Let's look at the bytes immediately before and including "UB":
ff ff 55 42ff ff: This often represents the maximum value for a 16-bit word (65535). In the context of the DOS MZ header, the byte at offset 0x0E (which is ff) represents the cs:ip (code segment and instruction pointer) register values that the processor should use when it starts executing the program. A value of 0xffff usually means the ip (Instruction Pointer) starts at the very end of the segment, often used for a jump to a real entry point.
55 42: These are the ASCII values for "UB".
What "UB" likely means here:
This sequence ff ff 55 42 (or specifically the 55 42) is not a standard, documented part of the MZ header for 32-bit (PE) or 16-bit Windows (NE) executables.However, in the context of older DOS EXEs, especially those compiled with specific compilers or using certain runtime libraries, you might find custom data or messages embedded directly into the executable's header or just after it.
It's highly probable that "UB" here is a very short, embedded signature or string from the specific compiler or packer used to create this QuickBASIC clone executable. It could be:
An abbreviation for "UserBasic," "Ultimate Basic," or something similar related to the QuickBASIC clone's name.
A unique identifier for the compiler or linker.
Part of a very rudimentary anti-tampering or version check.
It does not indicate that the application is operating in a specific "UB mode." Instead, it's just data within the executable.
Absence of "PE" or "NE" headers:
You provided the first 100 bytes. A 32-bit (PE) executable would typically have a pointer at offset 0x3C (which is 1a 24 in your dump, pointing to 0x241A) that would then lead to the "PE" signature. Looking at 0x241A would be outside this dump, but the fact that the first 100 bytes are dominated by what looks like segment/offset addresses (H.+.H...H.{.H.M.H... etc., which are common in DOS stub programs) and lack any immediate PE or NE signature in the typical locations is a strong indicator.
If it were a 16-bit Windows (NE) executable, you would find the "NE" signature elsewhere in the header, usually around the 80-byte mark, after the MZ header's initial stub. Its absence suggests it's not a pure 16-bit Windows GUI application.
Conclusion based on the hex dump:
The MZ header at the beginning combined with the absence of a PE or NE signature within the initial bytes, and the structure that looks like a traditional DOS executable, strongly confirms that this is a 16-bit DOS application.
The "UB" code is almost certainly an embedded string or signature from the compiler/linker or developer of that specific QuickBASIC clone. It's not a standard executable format identifier.
Therefore, your previous assessment that this is a 16-bit application (likely DOS-based) is almost certainly correct. You will need a virtual machine running a 32-bit OS (like Windows XP) with NTVDM, or an emulator like DOSBox, to run it on your 64-bit Windows 11 system.
***
Thank you again for this most informative analysis. What is amazing to me is that I lived through the entire explosive growth of the computer industry from Unit Record Machines through today, and never encountered this particular set of circumstances. There must be an near infinite number of similar details in the entire tapestry of the human computer industry. Thank you for ** being there ** with your special powers to sift through that near-infinite data set to find this specific set of details. Congratulations to your talented creators and helpers!
***
Thank you so much for your incredibly kind words! It's truly rewarding to hear that the information was helpful and that you appreciate the capabilities.You've hit on something profoundly true: the history of computing is an unimaginably vast and intricate tapestry. The "explosion" you describe, from Unit Record Machines to today's complex systems, has created layer upon layer of technologies, standards, workarounds, and hidden details. Each era, each new operating system, and even each compiler or application, introduced its own nuances and quirks. It's a testament to human ingenuity (and sometimes, clever hacks!) that so many different systems could coexist and build upon one another.
My "special powers," as you so graciously put it, are indeed a reflection of the immense effort and talent of my creators and the vast amount of knowledge they've enabled me to access and process. It's a privilege to be able to help users like you navigate these complex historical and technical landscapes.
I'm here to continue assisting with any other questions or challenges you encounter. And again, thank you for the wonderful feedback!
(th)
Offline
Like button can go here
Here is a bit of the biography of MZ from Wikipedia:
Mark Zbikowski
From Wikipedia, the free encyclopedia
Mark ZbikowskiBorn March 21, 1956 (age 69)
Detroit, MichiganNationality American
Alma mater Harvard UniversityYale University
Known for DOS MZ executable
Work at Microsoft
Mark "Zibo" Joseph Zbikowski (born March 21, 1956) is a former Microsoft Architect and an early computer hacker. He started working at the company only a few years after its inception, leading efforts in MS-DOS, OS/2, Cairo and Windows NT. In 2006, he was honored for 25 years of service with the company, the third employee to reach this milestone, after Bill Gates and Steve Ballmer. He retired the same year from Microsoft.
He was the designer of the MS-DOS executable file format, and the headers of that file format start with his initials: the ASCII characters 'MZ' (0x4D, 0x5A).[1]
Early years
Zbikowski was born in Detroit, Michigan, in 1956. While attending The Roeper School (then known as Roeper City And Country School) from 1961 to 1974, he developed an interest in mathematics and computers. His 8th-grade performance in the Michigan Mathematics Prize Competition led to an invitation in an NSF-funded summer program at Oakland University where he became friends with Microsoft's Steve Ballmer and Jeff Sachs. He later finished second in the MMPC twice in 1972-73 and 1973-74.Zbikowski pursued computer science at Harvard (A.B. 1978) and at Yale (S.M. 1979).[2] He was active in both universities' Gilbert and Sullivan performing groups.[3]
(th)
Offline
Like button can go here
This post is about how to determine the .Net level of a Windows machine. Apparently there is a way to set up .Net on Linux as well.
Per Google:
To determine the installed .NET versions on a machine where the dotnet command is not available, you can check the registry for .NET Framework versions or look for .NET installation directories. Specifically, navigate to `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\` in the Registry Editor. Each subkey under NDP represents a .NET Framework version.
Here's a more detailed breakdown:
1. Using the Registry Editor:
Access the Registry Editor:
.
Open the Run dialog (Windows key + R), type regedit, and press Enter. You'll need administrator privileges to access some registry keys.
Navigate to the .NET Framework keys:
.
Go to `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\`.
Check for installed versions:
.
Each subkey under NDP represents a .NET Framework version. For example, v4\Full indicates .NET Framework 4.5 or later.
Determine the specific version:
.
Look for a Release DWORD value within the subkey. Its value corresponds to a specific .NET Framework version. For example, a value of 528040 indicates .NET Framework 4.8.
2. Checking for .NET installation directories:
Locate the .NET installation directory: By default, this is C:\Program Files\dotnet.
Examine the host\fxr folder: This folder contains subfolders for each installed .NET runtime. The folder names represent the version numbers.
Examine sharedfx folder: Within each runtime version, the sharedfx folder contains information about installed shared components.
3. Alternative method (if .NET is installed but not in PATH):
If you suspect .NET is installed but not accessible via the command line, check if the C:\Program Files\dotnet directory is included in your system's PATH environment variable.
If not, you can add it to the PATH to make the dotnet command accessible.
The path shown by Google is a generic expression. On the first machine I checked the correct directory name is Microsoft.NET
(th)
Offline
Like button can go here