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.
Related
I recently had an issue where I was able to add an icon to a (VB6) form on one PC where it worked fine, but they was unable to run/compile it on a second PC.
It turned out that the icon file was 32-bit (including an alpha channel) and this was the problem. But I was surprised that this was a system-dependent feature.
(In this specific example it was Win10 x64 which allowed the 32-bit icon, and Win7 x32 which did not).
So now it seems quite unclear what icons are permissible to use in VB6 in which versions of Windows?
I have seen examples such as this question which have a similar issue, and this other question outlines what may have been the original VB6 features when it was new (?) but I can't yet find information that comprehensively breaks down what has changed based on Windows version.
This is important because we don't need to necessarily live within the limitations of (say) Windows XP if we know we are deploying to Windows 8 / 10 only. But nor do I want to risk that a fraction of users will have some dire problem because of this.
I've dug into this a little more - it appears that the Windows API function OleLoadPicturePath() behaves differently in the two Windows versions I mentioned above. On Win7, it will error out with a 32-bit icon; but on Win10 it does not. I'm not sure if there are other API functions which differ also, or not.
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.
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 was wondering about the distribution rights of esent.dll (Extensible Storage Engine).
I know that it's included in Windows but, depending on the version of Windows, it's not the same.
For example, in Windows 2000, the initialisation is different and in Windows Vista+, there are some interesting parameters that were added.
So, instead of programming our software differently depending on the client OS, could we just take the latest version of esent.dll and distribute it with our software ?
In case you would get the permission ... how would you distribute it without problems to W2K, XP and so on ...
I doubt that you will be allowed to do that. Looking at Microsoft and its Windows OS you can see what an aweful burden legacy support can be. In a similar situation with ESENT I decided to just support Windows XP and for one part of my app only Windows Vista and newer, knowing that my customers are usually up to date. You could take a look into skipping support for at least Windows 2000. The ESENT API delivered with Windows XP is really powerful and you will hardly need the novelties of the newer versions.