First of all: I know that Windows XP is end of life, insanely insecure, a big risk and that everyone still using it will be doomed for ever.
Nonetheless I have to provide an application that can also run on Windows XP and I do so using Go.
In 1.10 it was announced that XP will no longer be supported and 1.11 confirms this in the release notes:
As announced in the Go 1.10 release notes, Go 1.11 now requires
OpenBSD 6.2 or later, macOS 10.10 Yosemite or later, or Windows 7 or
later; support for previous versions of these operating systems has
been removed.
I compiled my application with 1.11 and tried to execute it on a Windows XP SP3 virtual machine. It could be executed successfully !
Then I thought that the revoked support for Windows XP only applies to the development toolchain but even that can still be executed on Windows XP:
As you can see the main go binary still runs on XP too. Is it already known when it will no longer be possible to run golang compiled exes on Windows XP because of technical limitations or if certain methods will fail because they can no longer work because of missing APIs on XP ?
Issue #23380 is the relevant discussion.
In short:
Note that even if 1.10 is the last version to support XP, you'd get bugfix backports until 1.11 is out, and security backports until 1.12 is out. That means until January 2019 <…>
As to supporting Windows XP, there are both technical and non-technical reasons.
Supporting a platform requires:
Someone who has access to it, and an incentive to work on it
(either paid or unpaid).
The most active Go-on-Windows developer, Alex Brainman,
seems to have no interest in XP anymore.
This platform must be supported on autobuilders which are part of the Go release / QA process.
An autobuilder must be supported by someone.
Bugs specific to a platform must be fixed and tested.
For instance, that issue refers to #23375 which happens only on Windows XP (SP3).
But even if a bug was specific to Windows in general—as opposed
to Windows XP, a fix for it would have to be tested on XP anyway.
Hence, unfortunately, if there is no interest in supported Go on Windows XP coming from some "powerful entities"—such as corporations—the best you can do is to actually work towards still supporting this by yourself, FWIW.
Also note that even after the support is officially ended, you still might have success building newer Go releases from the source (which is reasonably simple since Go 1.5 as Go is now built using (an older release of) Go).
Hence a real show-stopper would be the Go team hitting some roadblock which would just require some kernel feature not present in Windows XP.
A good example was some difficulty with SEH handling on Windows 2000 which eventually led to dropping support for that OS.
Related
I want to install some software on a pre-alpha XP build (codename Windows Whistler). However, 90% of the installers fail to run. I guess it is because of the kernel version, which I suppose is somewhere between 5.0 and 5.1 (as I remember even the software that should run under Windsows 2000 did not succeed to install).
How can I most correctly and efficiently change the values in registry so that I have a chance to test some software (I know there can be bugs because of missing features, I'm doing tests in the VM).
The same question about Windows XP x64 with kernel version 5.2 - where to change it so that basic software designed for Win XP x86 does install as it does on regular Win XP (or maybe there is some compatibility option in properties).
Thanks for your help.
UPD: Java Runtime Environment version 5 update xxx should work on Windows 2000 (and even on Windows 98 SE, I tested it). But it somehow refused to install on Whistler... Maybe they cut something important away during development to make builds faster to compile?
You can try Right Click on .exe -> Properties -> Compatibility -> Run this program in compatibilty mode for.. and then specify compatible versions of OS.
tl;dr: Device driver written in NuMega DriverStudio for Win95 to be upgraded to Win10 64-bit. What's the easiest path?
We have a very old product line, which is still selling well. One dll, accessing a UART in a way normal serial handlers can not (to support an even older protocol for another company's products), was made back when the product was first released - for Windows 98! Ever since, it has been working flawless (on 32-bit machines). Therefore, the code has never been touched since it's initial creation!! (This is based on the memory of a few of my colleagues who were around at the time). The only source I have been able to find is from 2001, although one file dates back to 1998.
The driver type is WDM
Now Microsoft have stopped providing 32-bit versions of Windows 10, and customers have started asking for a 64-bit version of our software, so I landed the task of figuring out how easiest to fix it - and support win7 through to Win10, 64-bit.
However the DriverStudio from NuMega was discontinued shortly after the company was purchased by Compuware (and they have lost all knowledge of it!), and even if we were able to find an old version (latest is from 2002), it's unlikely that it's going to help us very much.
I've been searching the web, but haven't found anything giving any suggestions to what the then users of DriverStudio did to upgrade their drivers.
At the time, Jungo WinDriver were an alternative that most people didn't consider to use for 'real' drivers, but perhaps times have changed?
Any advice on how to upgrade this driver code as easy as possible will be highly appreciated.
Is there a way to reboot W2K in a native way?
ExitWindows(Ex)
InitiateSystemShutdown(Ex)
Works starting from Windows XP. May be I can kill a kernel to force the reboot but it's weird. I wasn't able to find anything on MSDN.
For InitiateSystemShutdown, MSDN states that the minimum supported version is XP, but that can easily be misinterpreted. This does not mean that the function was introduced in XP. Sometimes when MSDN documentation is updated, the minimum supported version fields are updated to be at least the minimum supported OS version, even if that version is later than the version in which the function was introduced.
In this case, for this function, you can certainly use it on Windows 2000.
If you are still actively targeting such an old version of Windows, you really should try to find an old MSDN disk and refer to the documentation from that. That will make your life much simpler.
I have Windows 2003 server, with executable built on VC6. I would be needing to check the compatibility of the executable on Windows 2008 server (both servers 32 bit). I know that I need to check for ABI compatibility for these two versions.
How do I confirm that there is ABI compatibility for any two versions of a OS? Or does Windows release the ABI compatibility as part of product document?
Is there any other set of consideration to be taken care apart from ABI compatibility?
Windows maintains binary ABI compatibility between different versions. This means that programs do not need to be re-compiled for different versions.
However, this is not enough to guarantee that a program will run correctly on a version that you have not yet tested. Some examples of possible problems:
You use a deprecated API that has been removed in a later version.
You use an API that exists only on a later version of the OS and so your program fails to run on an older version.
The OS changes functionality that breaks your app. The classic example of this was UAC in Vista. The ABI did not change, but some pre-UAC apps failed to run correctly under UAC.
The bottom line is that you do need to understand the theory behind binary compatibility. But that does not absolve you of the need to test. Make sure that you've tested your program on all supported systems. Or at least as many as you can reasonably manage to find.
See detailed analysis of changes in the Windows API on this page. The reports are generated with the help of the abi-compliance-checker tool.
Starting with Windows 8.1, GetVersionEx no longer returns the "true" version number, but might return a lower value.
There a no service packs for Windows 8 or Windows 8.1 yet, but when they are available, will GetVersionEx lie about them (wServicePackMajor and wServicePackMinor in OSVERSIONINFOEX) as well?
Microsoft forever does battle with well-intended code that a programmer writes to check the Windows version. Which was typically written to deal with older Windows versions. But forgets to do something reasonable with a newer Windows version.
So they spend massive amounts of effort on targeted compatibility shims that intentionally lie about the Windows version when a specific program asks for it. A never-ending battle whenever they release a new Windows version. Certainly a losing battle, the number of programs they need to test is staggering.
So at Windows 8.1 they said "no more", deprecated GetVersionEx() and intentionally lie out of the box, returning version 8.0. You need to add an entry to the manifest to turn off the lie. Which probably will turn off a lie about the service pack as well. Or might require an updated GUID, fairly unlikely. We of course can't be sure until that happens.