What's missing here is why you need XP to use your SyncMaster CRT. I assume it has a VGA connection. You could use a modern computer and an HDMI to VGA adapter or an inexpensive video card with a VGA out.

Maybe you could compile it yourself? It is open sourced after all.

GloriousCow wrote on 2025-08-15, 17:49:

What's missing here is why you need XP to use your SyncMaster CRT. I assume it has a VGA connection. You could use a modern computer and an HDMI to VGA adapter or an inexpensive video card with a VGA out.

It's just the matter of convenience, although I have indeed thought of that idea myself. I have a very modern PC that is close enough to this old desktop PC, and I can use that.

My issue is the stretching of the image however. No matter which setting I use under 'Full Screen Stretch Mode', (or other settings under the View option menu), the text and images look a bit fuzzy)

C0deHunter wrote on 2025-08-15, 17:58:

It's just the matter of convenience, although I have indeed thought of that idea myself. I have a very modern PC that is close e […]
Show full quote

GloriousCow wrote on 2025-08-15, 17:49:

What's missing here is why you need XP to use your SyncMaster CRT. I assume it has a VGA connection. You could use a modern computer and an HDMI to VGA adapter or an inexpensive video card with a VGA out.

It's just the matter of convenience, although I have indeed thought of that idea myself. I have a very modern PC that is close enough to this old desktop PC, and I can use that.

My issue is the stretching of the image however. No matter which setting I use under 'Full Screen Stretch Mode', (or other settings under the View option menu), the text and images look a bit fuzzy on my CRT)

The strange thing is the initial boot of the system (I am using an AOpen ZX6BC as motherboard) the BIOS text looks very sharp (can see the scanlines on the CRT) but as soon as it loads into the OS or asking for a boot disk, the image resolution changes into a fuzzy one.

Windows XP host support for 86Box was dropped after build 1839. This is because the developers upgraded GCC to version 9.2.0-2 which operates under Windows Vista and later. Later versions of GCC may not support anything before Windows 10 either.

Also, build 6139 was the last version of 86Box to run on PCs running 32-bit operating systems. It's possible to compile 86Box using GCC < 9.2.0-2 up to build 6139, but don't expect it to fully work correctly. 😀

Only a tiny percentage of users still remain on Windows XP as that OS hasn't been supported for over 11 years.

ppgrainbow wrote on 2025-08-15, 22:18:

Windows XP host support for 86Box was dropped after build 1839. This is because the developers upgraded GCC to version 9.2.0-2 which operates under Windows Vista and later. Later versions of GCC may not support anything before Windows 10 either.

Also, build 6139 was the last version of 86Box to run on PCs running 32-bit operating systems. It's possible to compile 86Box using GCC < 9.2.0-2 up to build 6139, but don't expect it to fully work correctly. 😀

Only a tiny percentage of users still remain on Windows XP as that OS hasn't been supported for over 11 years.

Imagine Windows 10 joining it's ranks within 2 months... Hopefully they leave it as bug-free as possible. So without any critical bugs it sometimes gets.

Imagine Windows 10 joining it's ranks within 2 months... Hopefully they leave it as bug-free as possible. So without any critical bugs it sometimes gets.

I did boycott Windows 10 and won't shed a single tear about it soon going six feet under.
Windows XP is a totally different matter, it was such a relief to most Windows 98 users at the time.

C0deHunter wrote on 2025-08-15, 15:51:

There seems to be a discontinue on the XP binaries (as confirmed by the 86Box admin over at the Github) and I have asked him to kindly provide the XP binaries.

https://github.com/86Box/86Box/issues/412

Many thanks!

MinGW GCC v10.3 from 2021 can build Windows XP binaries just fine. I find that If you one uses it as a compiler on Windows XP; it will not add NT6 API calls, when linking to the common stock runtime libraries. Just that one needs to use an older libwinpthread-1.dll.
QT 5.6.3 is the last version to work on Windows XP. Any other dependencies will have their own compatibility situation....

PCem v17, from december 2020, runs on Windows XP.

Jo22 wrote on Yesterday, 16:10:

Imagine Windows 10 joining it's ranks within 2 months... Hopefully they leave it as bug-free as possible. So without any critical bugs it sometimes gets.

I did boycott Windows 10 and won't shed a single tear about it soon going six feet under.
Windows XP is a totally different matter, it was such a relief to most Windows 98 users at the time.

I've been using Windows 10 for nearly four years now and it works well without any problems with the amount of RAM maxed out at 32 GB.

Windows 10 is still being used by over 40% of customers worldwide and Microsoft won't be providing free security updates, technical support or assistance after October 14, 2025. To make matters worse, a angered customer down in southern California is even suing Microsoft for ending Windows 10 support as more than 250 million PCs will end up becoming e-waste, because they can't upgrade to Windows 11 due to its system requirements.

I've been using Windows 10 for nearly four years now and it works well without any problems with the amount of RAM maxed out at 32 GB.

Hi there! I'm not having technical problems with Windows 10, but it's about principles.
Windows 7 was the last Windows to respect the users.

Windows 10 did things like removing user applications without permission.
It did nag the Windows 7 users with upgrade notifications in taskbar and even tricked them into upgrading without them wanting to.
Microsoft went to a little bit to far here, I think.

That's why I was on a Raspberry Pi from 2017 to 2023 or so.

Unfortunately, time had moved on and nowadays new Windows applications merely support Windows 10 or 11.
That's why I've installed a Windows 11 VM on a Mac, in case I have to use a recent Windows application.
It's more about experimentation and not loosing contact to society, though.
Windows nolonger is my daily driver.

That rather used to be my Windows XP SP3 machine, an old Macintosh Pro 2.1 with Xeon processors.
It also has my VMs and most emulators installed.
Unfortunately, the Xeon processors installed don't support SSE4 instructions, so newer OSes in VMs nolonger worked.

Once I can upgrade to a slightly newer model, I'll use my XP installation again.
Because a lot of work went into it and it even has One Core API installed,
so it can run Windows Vista/7 applications and certain DirectX 10/11 applications.

Provided applications are available as traditional Win32 x86 programs, rather than Win64.

Edit:

as more than 250 million PCs will end up becoming e-waste, because they can't upgrade to Windows 11 due to its system requirements.

I heard this a lot of times and it made wonder what's the big deal about replacing a CPU or motherboard.
I mean, I basically grew up in the 90s when computers were being literally obsolete after 6 months.

On other hand, I'm a little bit out of touch with society.
Perhaps changing components nolonger is a thing or the current generation of users is unable to perform a motherboard swap.

Maybe not those people suing Microsoft, but a lot of people are angry because in the 90s, you really had to hate yourself if you wanted to run the new and fancy OS on your current but dated PC, but now PCs that will run the core functionality just fine, you are still forced to throw it away and buy something new. I myself have an i4790K system that runs Windows 11 just fine if you use an installation method that some consider unnatural.
I am not saying that there is no valid reason why Microsoft decided to imposes the rules that they did, but I can understand the consumer frustration.

Jo22 wrote on Today, 03:00:

I've been using Windows 10 for nearly four years now and it works well without any problems with the amount of RAM maxed out at 32 GB.

Hi there! I'm not having technical problems with Windows 10, but it's about principles.
Windows 7 was the last Windows to respect the users.

Yes, I still have Windows 7 installed on my PC and use it often, every version of Windows after that one has been terrible. I use Windows 10 as well, but I have done everything to disable telemetry and make it behave and function like Windows 7 but even then the UI is far less snappy than 7 is. I am using a version of 10 called LTSC IoT which has extended support until 2032, I also have Manjaro installed on my PC in the event that programs and games drop support for Windows 10. I used 11 on a laptop and it is the worst OS experience I've ever had honestly, and my PC thankfully doesn't have TPM which 11 requires so I am not eligible anyway. My PC also runs fine without issue even with newer games (except RTX games), so I don't see the point in upgrading.

All,
This thread is about 86box on Windows XP, not yet another Windows 10 rant thread.

DosFreak wrote on Today, 10:25:

All,
This thread is about 86box on Windows XP, not yet another Windows 10 rant thread.

You're right. Sorry to get the discussion a bit side-tracked there.

Anyways, tried recompiling the latest 86box with XP settings yet? It should either support some kind of automatic build configuration that you can adjust or maybe some legacy stuff (like SDL 1.x or the like)?
Am not that familiar with 86box compilation. Perhaps look into the git repositories if you can find anything (configure scripts, autobuild and the like)?

Looking into the codebase (https://github.com/86Box/86Box/blob/master/CMakeLists.txt) it looks to be CMake-based, so if you've got your development environment setup (gcc+CMake, try MSYS2 for example. Then editing the CMakeLists.txt and add required flags for XP compilation.

Perhaps add (based on https://stackoverflow.com/questions/46724267/ … -march-hardware):

1CHECK_CXX_COMPILER_FLAG("-march=i586  -mfpmath=387" COMPILER_SUPPORTS_MARCH_XP)
2if(COMPILER_SUPPORTS_MARCH_XP)
3    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=i586 -mfpmath=387")
4endif()

To build for Pentium CPUs with 387-compatible FPU (to prevent Pentium FDIV bug).
Or try "-mno-80387" instead of "-mfpmatch=387" for a software-based FPU solution.

No idea if it has any code depending on a specific OS though, you'd have to check that yourself.