The Nasville ain't real
Did a build of what you have here as Nashville 4.10.999
In actual fact, the version number returned by a call to the Windows API GetVersion returns 4.0.999 (the zero implies Chicago, not Nashville).
Ether someone pounced on the 999 build number and thought "hey, Nashville!"
Or someone with a very strange mind has hacked a build to report 999 in order to pass it off as Nashville.
Either way, I'm suggesting that it ain't Nashville.
Please do go ahead and correct me if I've got that wrong.
In actual fact, the version number returned by a call to the Windows API GetVersion returns 4.0.999 (the zero implies Chicago, not Nashville).
Ether someone pounced on the 999 build number and thought "hey, Nashville!"
Or someone with a very strange mind has hacked a build to report 999 in order to pass it off as Nashville.
Either way, I'm suggesting that it ain't Nashville.
Please do go ahead and correct me if I've got that wrong.
Comments
The GetVersion function returning a version number of "4.0" instead of "4.1" is most likely just a bug that was later corrected.
This version of Windows 95 also included an early version of what later became known as Internet Mail and News and eventually even Outlook Express, which at that time was known as "Athena PIM" ("Athena" was the codename for those projects). Obviously you don't know your Microsoft codenames very well at all, or you wouldn't have disputed this.
The GetVersion routine is a Kernel32.DLL function. Whilst the Kernel32.DLL file in the system folder has a version stamp of 4.10.99 (like all other files in this OS) it also has a MODIFIED date and no CREATION date. The modified date is September 2001.
The NW16.DLL has a creation date of when I installed the OS (2017), but also a modification date of September 2001.
All the other system files are "correctly" dated as November 1995, unless they were modified by the intall process: which gives them 2017.
All the files are marked with version 4.10.999 though.
But I find it peculiar that a system kernel function used by Microsoft since Windows 3.11 through to Windows 10 to report the version and build should not only be buggy but also reside in a file that is mysteriously date stamped about five years later than the OS build was leaked from Microsoft. Don't you?
I can't imagine why, but it almost looks as though someone has injected a modified Kernel32.DLL (and possibly NW16.DLL) into this build, back in September 2001.
It appears I'm not the only one who has noticed this:
https://www.betaarchive.com/forum/viewtopic.php?t=20847
However, in that post, no-one picked up on the fact that an OS created as a build in late 1995 and leaked in 1996 has files dated in 2001.
Given the functions in these DLLs are kernel and networking, you can guess where my thinking is going...
I extracted the Kernel32.DLL from a couple of the CAB files on the ISO (which are correctly dated, but of a different size and date to the installed one). I used these to ensure that they are byte identical to each other, but different to the 2001-dated one that lies outside of the CAB files on the ISO (ha! that's where it got its date from: when the ISO was made).
I WinImaged this November-1995 Kernel32.DLL to a VFD and booted "Nashville" into safe mode with command prompt.
I overwrote the Kernel32.DLL with the CAB-sourced one one the floppy.
Rebooted fine: checked date and size. All ok.
Ran my code to call GetVersion which (still) returned 4.0.999.
So I'm satisfied as far as I can be that Nashville's GetVersion has a bug.
I shall amend my version-tester code accordingly: it will henceforth identify both 4.10.999 and 4.0.999 as being Nashville ...and my Nashville installation has thus fulfilled it purpose and can be deleted
This is courtesy of the GetVersion and GetVersionEx documentation within Visual Studio 6.0.
It turns out that the build number for Win9X duplicates the major and minor version numbers in its upper two bytes (which is why it has always been customary to mask the build with $FFFF if the major version is less than 5).
What the documentation does not tell you is that there's no guarantee that the minor version number field will match the minor version in the unmasked build number.
It turns out that if you receive a zero minor number in its designated field and yet the build number's third most significant byte is not zero, then basically you have to update the minor field yourself by appropriately shifting and masking the build number that GetVersion returns. Doing that then makes Nashville appear as version 4.10.999. Whether this is a code bug or a documentation bug is hard to tell. It will be interesting to see whether this strange "algorithm" is needed for (say) Windows 95 OSR2 - which is another one that gave a strange result (minor=0 instead of minor=3, if I remember correctly). It was that anomaly that started me down the path of verifying what people say build numbers should be and what that routine reports.
Either way, with the 1995 version of Kernel32.DLL in place, I can get 4.10.999 after all. I haven't bothered checking if that is still the case with the slightly larger 2001 Kernel32.DLL that actually gets installed initially. The whole intent of the exercise was to test and, if necessary, correct, the GetVersion post-processing code, not Nashville.