I experienced that after 1.12.17 increased the minimum supported Windows Version. Both the go binary itself and binaries created by it ceased working and Windows only reports “xyz.exe is not a valid win32 application”
I guess this is related to this note in the changelog:
The Windows version specified by internally-linked Windows binaries is **now Windows 7 rather than NT 4.0**. This was already the minimum required version for Go, but can affect the behavior of system calls that have a backwards-compatibility mode. These will now behave as documented. Externally-linked binaries (any program using cgo) have always specified a more recent Windows version.
Can someone explain to me what “internally-linked” means AND which information in the binary contains the version relevant parts (is it a PE Header Information) ?
Now for the usual disclaimer
I know that Windows 8.1 is on Extended support and Windows 7 is EOL and that everyone using it and its predecessors Vista and XP should burn in hell. But I need to update software that stills runs on hardware that can’t be easily updated/replaced
I do not know what it means, exactly, in this context, but I presume this is referring to changes in how the operating system loads and/or executes executables and/or DLLs.
Based on this description, it looks like Go binaries were reporting compatibility with Windows NT 4.0 even though they were not (or might not be) compatible with Windows NT 4.0.
Back up a minute and tell us what you’re trying to do. Based on how I’m reading your post, it sounds like you’re trying to compile code for platforms older than Windows 7 which was released in 2009, nearly 11 years ago.
If you do, indeed, want to compile and run your Go programs on older platforms, what this changelog tells me is that compiled executables were incorrectly reporting compatibility with Windows NT 4.0 from 1996. That is, they were reporting to the operating system that they followed the Windows NT 4.0 API but might actually call an invalid Windows API function that could end up either:
Crashing the application (this is the best case)
Calling an unexpected function at some point (because the Go compiler might emit a call to the Windows OS API that it shouldn’t have because it’s expecting the API to work like Windows NT 4.0 but the API doesn’t actually follow that API).
If you want a stable program that works with Windows NT 4.0, I suggest you contact the Go team to have them confirm the latest release of Go that works with the platform you’re targeting.
If you’re really looking for Windows NT 4.0 compatibility from 23+ years ago, I suggest upgrading your code to work with a newer platform. You mention hardware compatibility which is different from operating system compatibility. I cannot think of a good reason (admittedly, I’m not a computer science expert) to try to keep your Go code compatible with Windows NT 4.0. If you’re constrained to older hardware, you can still switch your operating system to a Linux-based OS that still runs on i386-compatible hardware.
If this post doesn’t answer your question, please give us the backstory to determine why reporting Windows 7+ compatibility is a problem.
Thank you for your feedback and the information you gave.
It is less worse than you think I “only” need to run the binary on Windows XP. If the binary could signal “I need XP” instead of “I need NT 4.0” would also be ok.
Here’s the backstory you’ve been asking for:
I sell a software that gets information from a POS software. That POS software is old, only runs on Windows and only supports Windows XP or earlier. Btw: the POS software was built and sold by a totally different company.
The people using that POS software are mostly very nice persons but they absolutely don’t care about the implications that using outdated insecure OSes creates. Some are even still using Windows 2000.
Currently my software is delivered on a stick, the user plugs it in, clicks on the exe and the exe installs itself. Even that process is difficult for most of the users and I can’t travel through the whole country just for installing the software.
I thought about putting the program on a Raspberry Pi and giving it access to the files on the Windows XP machine over the local network (yes, that XP machines are networked, some even connected to the Internet …). This would work technically but people who are technically challenged when having to install software from a stick definitely will have a hard time installing that Raspi properly … (I consider it unfeasible)
