I'll assume this is what you mean.. shell32.dll's CDesktopWatermark::s_GetProductBuildString function (this actually fetches the build to draw for PaintDesktopVersion), uses the following registry key: Code: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\BuildLab This is as close to what you would call the "software build" as it gets. This is the designation of the build artifacts that Microsoft actually compiled. Those (ie. 19041 RTM's build artifacts) happen to be the same for 19041, 19042, 19043 and 19044. Builds 19042, 19043 and 19044 weren't rebuilt from scratch (as any new build's RTM is); they build upon (get it?) the build artifacts of 19041. Edit (about winver): winver uses shell32.dll's ShellAboutW (which is public) and that gets the entire version from: Code: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CurrentBuild HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DisplayVersion HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ReleaseId (for pre xxHx version naming) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\UBR This build has nothing to do with the build artifacts used for it.
@awuctl this is fun these M$ trainees wrecked the PaintDesktopVersion [call it: feature or function or tweak or gadget or whatever] i hope ur not employed by M$ and forced to call it normal i wrote several times that for my use case it: worked until BUiLD 17763 as intended and expected [from w2k to win1809 (maybe later, i do not play on the SAC though)] is still working on BUiLD 20348 as intended and expected [from server2k to server2022] only very few know that or even use that function! i guess not even 1% of those posted here regarding my confirmation request. which btw was solved because a build is not a build anymore! hence the PaintDesktopVersion is rendered useless 'artifacts'; nice description/definition, ty for the additional confirmation
It's confusing but definitely normal. The BuildLab value always meant the actual build ("build" as in: what they compiled, staged and released as RTM) designation (initial version, architecture, build type, branch and build datetime which you can find in BuildLabEx), not the current running build ("build" as in: the current running version/update of the operating system). PrintDesktopVersion's information was never the correct "running build", those just "historically" mostly happened to have been the same number.. Nothing's broken. It is exactly the same thing it always was - it shows you the build lab designation. This is the running build/version, but not in the same sense that the information in winver is. 19042, 19043, 19044 may be called different build numbers, but they're all based on the same build. Hence 19041, 19042, 19043 and 19044 are all version 19041.vb_release.191206-1406. Not really but ok I guess. I personally have an entirely different naming scheme for all those designations and I couldn't give a s**t about the confusion Microsoft causes. Microsoft themselves have no idea what a "build" is and I can agree with that much I can't even imagine the destruction I'd cause if I worked at Microsoft
Thank you dear. there was two packages to use: AIO standalone script Traditional pack which one is better?
It's always been useless, if you really need useful information printed on the desktop use Sysinternals BgInfo instead. Btw, you are confusing BuildLab with CurrentBuild/UBR. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion: BuildLab CurrentBuild UBR
Hi, I've read that MAK keys for LTSC 2019 don't work for 2021. If I have an already activated LTSC 2019 and do an in-place upgrade to 2021, will the OS remain activated or will I have to buy and enter a newer key? Moreover, what if I'll later do a clean install of LTSC 2021, won't the 2019 key work on the same machine?
nice to see u in the 99% i am aware of and use bginfo. if you know what u are writing about please clarify: is bginfo using the same technique to display the info on the desktop? can bginfo cover all scenarios like the regkey? guess what: maybe all skilled coders @ M$ are gone now and no one even knows about this hidden gem: so they screwed it not providing an appropriate replacement
1. Just hope the key still works when reapplied to LTSC 2019 2. Only gVLK is still the same for both 2019 and 2021 LTSC. 3. Stop wasting money on questionable keys, simply use KMS_VL_ALL or KMS38.
I'm not the one who somehow cannot comprehend that absolutely nothing changed about that favorite toy of yours
I bought a fully legal, used LTSC 2019 key. Reselling of keys is legal in Europe. What I wanted to know is whether an in-place upgrade of LTSC 2019 to 2021 will stay activated or not?
It won't. About the legality of selling LTSC keys, considering they only are meant for very specific license holders i doubt that a questionably obtained key and the resulting activation will be considered legal.