Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"dart info" reports Windows 11 as Windows 10 #55351

Closed
DanTup opened this issue Apr 2, 2024 · 13 comments
Closed

"dart info" reports Windows 11 as Windows 10 #55351

DanTup opened this issue Apr 2, 2024 · 13 comments
Labels
area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends. library-io P4 triaged Issue has been triaged by sub team type-enhancement A request for a change that isn't a bug

Comments

@DanTup
Copy link
Collaborator

DanTup commented Apr 2, 2024

The output of dart info for me includes this:

#### General info

- Dart 3.3.0 (stable) (Tue Feb 13 10:25:19 2024 +0000) on "windows_x64"
- on windows / "Windows 10 Pro" 10.0 (Build 22631)
- locale is en-GB

Here's what my system information looks like:

image

While it's true that Windows 11 still uses 10.x for its version, the name is Windows 11 Pro but Dart reports Windows 10 Pro. This can be confusing to users filing bug reports. I'm not sure where the string "Windows 10 Pro" is coming from, as I only see "Windows 11 Pro" in Windows, and 10 is only in the version number.

@lrhn
Copy link
Member

lrhn commented Apr 2, 2024

That line comes from:

    print('- on ${Platform.operatingSystem} / '
        '${Platform.operatingSystemVersion}');

so it's a dart:io issue.

That code ends up asking the registry for keys from HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\,
either CurrentMajorVersionNumber/CurrentMinorVersionNumber DWords or a CurrentVersion string. (In platform_win.cc.)

Would you be able to check what your registry reports for those keys?
(Or don't, because they will say 10: https://learn.microsoft.com/en-us/answers/questions/555857/windows-11-product-name-in-registry)

@lrhn lrhn added area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends. library-io labels Apr 2, 2024
@DanTup
Copy link
Collaborator Author

DanTup commented Apr 2, 2024

image

cry

I understand the version number is still 10, but Windows makes it seem like the name is "Windows 11 Pro". However, the ProductName key here also says "Windows 10 Pro". This seems like a bit of a mess.. why is Windows showing one thing in the system info but the ProductName in the registry is something different? :(

@DanTup
Copy link
Collaborator Author

DanTup commented Apr 2, 2024

In the linked post above, it says:

Microsoft recommendation is that applications should use the relevant APIs to retrieve such information from the system (WMI, GetVersionEx, etc) rather than querying the registry

I confirmed that this does return the "expected" value:

PS C:\Dev> Get-WmiObject -Class Win32_OperatingSystem | Format-List -Property Caption

Caption : Microsoft Windows 11 Pro

@lrhn
Copy link
Member

lrhn commented Apr 2, 2024

Agree, the "Caption" entry seems to be the one key that everyone agrees will say "11".
(Which means users have to parse that string to get the information.)
The other alternative is to use the build number, where >=20000.x is Windows 11. (Well, until Windows 12, so we'll have to keep updating special cases, instead of just getting usfeul information from the registry.)

@DanTup
Copy link
Collaborator Author

DanTup commented Apr 2, 2024

Which means users have to parse that string to get the information

Not sure what "users" means here. I was thinking that Platform.operatingSystem would return "Windows 11 Pro" (eg. the "marketing name" of the OS), but the version numbers would remain as-is (since those really are the version numbers).

Yes it's a little odd to get "Windows 11 Pro" as the name and "10" as the major version, but that's what Windows itself is showing (so I guess is "correct"). Hopefully this is only being used as an informational string and code isn't being written to behave differently based on the 10 vs 11 difference.

I think that also wouldn't require any special cases if/when Windows 12 comes along?

@lrhn
Copy link
Member

lrhn commented Apr 2, 2024

"Users" here means people reading the registry to get information. If you want to know the major version of the Windows you're running on, there is no field that directly gives you 11, as a number or as a string. You'll have to parse something. If using the Caption string, it's embedded in the middle of a bigger string, but not exposed directly.
(Quoting Josh Bloch, Effective Java:

Whether or not you specify the format, it is always a good idea to provide programmatic
access to all of the information contained in the value returned by toString
. ...
If you fail to do this, you force programmers who need this information to parse
the string. Besides reducing performance and making unnecessary work for programmers, this
process is error prone and results in fragile systems that break if you change the format. By
failing to provide accessors, you turn the string format into a de facto API, even if you've
specified that it's subject to change.

Still true.)

Dart could choose to make Platform.operatingSystemVersion return the Windows Caption text. That would be a change from the format today, which risks it being breaking ... even if we never promised any specific format, because we didn't provide any other way to access the same information.

@DanTup
Copy link
Collaborator Author

DanTup commented Apr 2, 2024

Ah sorry, I see what you mean. I didn't realise Dart lumped these two things into one string (I misunderstood your operatingSystem and operatingSystemVersion above and thought the first was where "Windows 10 Pro" came from).

How about:

  • Platform.operatingSystem - windows (already does today)
  • Platform.operatingSystemVersionNumber - new, returns OS version number only
  • Platform.operatingSystemName - new, returns "Windows 11 Pro" (caption from the above)
  • Platform.operatingSystemVersion - keep as is, but deprecate and tell users to use Platform.operatingSystemName (and not parse it) and Platform.operatingSystemVersionNumber

This doesn't break anyone and we have access to both "good" values (name and version). People using the "bad" version are prompted to migrate away and can choose whether to display the marketing name or the version (or both, as dart info should).

Edit: original suggestion was wrong - I realised version is the Dart version, not Windows version :( That does complicate things, but we probably should have a real version from the OS anyway. If breaking Platform.operatingSystemVersion is not an option, maybe there needs to be a Platform.operatingSystemVersion2 or Platform.operatingSystemVersionNumber or similar 🙃

@a-siva
Copy link
Contributor

a-siva commented Apr 2, 2024

//cc @brianquinlan

@lrhn
Copy link
Member

lrhn commented Apr 3, 2024

Adding more getters means supporting them on all platforms, so what should the new operatingSystemName and operatingSystemVersionNumber return on MacOS, iOS, Android, Linux and Fuchsia?

If operatingSystemVersion is, say, "Linux 5.15.0-78-generic #85-Ubuntu SMP Fri Jul 7 15:25:09 UTC 2023", how much of 5.15.0-79-generic #85 is the operatingSystemVersionNumber? Anything we don't include may be significant to someone.

There might be something we can return, but it's not clear that there is always a simple and obviously correct answer.

@a-siva a-siva added type-enhancement A request for a change that isn't a bug P4 triaged Issue has been triaged by sub team labels Apr 3, 2024
@DanTup
Copy link
Collaborator Author

DanTup commented Apr 4, 2024

That's fair, but it seems like these fields are all fairly arbitrary anyway. If the idea is to join these things together into a single string because it's difficult to separate them similarly on different platforms, then I think just updating operatingSystemVersion to use caption from above is probably the better fix.

The docs say not to parse it, and it's already clear that it might return different values in future versions (or even different editions) of Windows. I think anyone making assumptions about it having "Windows 10" in it now (and not handling Windows 11) is probably expecting to have to periodically update their code.

@bkonyi
Copy link
Contributor

bkonyi commented Apr 4, 2024

This also appears to impact our analytics reporting as it's also relying on Platform.operatingSystem, so Windows 11 users are being reported as running Windows 10. This might be something we want to resolve or recommend a workaround for (FYI @eliasyishak @mit-mit).

@rekire
Copy link
Contributor

rekire commented Nov 1, 2024

I think I have a solution for this issue with the WMI API

@mraleph
Copy link
Member

mraleph commented Nov 4, 2024

@rekire contributed a WMI based code in fb173b8

Thanks!

@mraleph mraleph closed this as completed Nov 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends. library-io P4 triaged Issue has been triaged by sub team type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants