Closed Bug 838279 Opened 10 years ago Closed 10 years ago

Report stats on whether Windows users have a 64-bit OS

Categories

(Toolkit :: Telemetry, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla21
Tracking Status
firefox20 --- verified
firefox21 --- verified

People

(Reporter: benjamin, Assigned: bugzilla)

Details

Attachments

(1 file)

Some people are again talking about doing Windows 64-bit builds to solve "the PGO issue". But as far as I know, we don't actually know how many of our current users are using 64-bit versus 32-bit versions of Windows. We should at least solve that problem by reporting via telemetry what kind of OS people have.

bbondy, can you paste what Windows API we'd use (from a 32-bit build) to figure this out?
OS: Mac OS X → Windows 7
Flags: needinfo?(netzen)
I think we might already have this info. I've noticed the 32-bit nightly reports "x86" in the Telemetry info.arch field while the 64-bit nightly reports "x86-64" on the same machine (64-bit CPU, 64-bit OS). 

We should add this info to FHR as well, as FHR covers a much wider population of Firefox users (unlike Telemetry, FHR is enabled by default on all channels).
^^ Actually, ignore that.. I thought the question was asking about the number of 64-bit Nightly users
nsUpdateService.js#345 doesn't actually tell me the information I exactly want to know, because it gives me the processor architecture but not whether the OS is win64. I really don't know whether it's likely that there are 64-bit machines out there running win32, but nothing would surprise me.

Apparently what I really want is IsWow64Process: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684139%28v=vs.85%29.aspx
That will only return true if you are using win32 on win64 emulation. So only true when x86 process on x64 OS. I think you want IsWow64Process OR size of int pointer is 8
Flags: needinfo?(netzen)
Since we don't actually ship 64-bit anything except nightlies, I'm not that worried about that case...
Sure if this is only for non-Nightly but one day we probably will ship x64 so if you are checking wow64, name that wow64 and not x64 windows.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #5)
> nsUpdateService.js#345 doesn't actually tell me the information I exactly
> want to know, because it gives me the processor architecture but not whether
> the OS is win64. I really don't know whether it's likely that there are
> 64-bit machines out there running win32, but nothing would surprise me.
> 
> Apparently what I really want is IsWow64Process:
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms684139%28v=vs.
> 85%29.aspx

We need to stick this somewhere in mozilla for telemetry js. Adding a 'isWow64' to @mozilla.org/system-info;1  sound ok?
Yeah, that's fine.
Assignee: nobody → aklotz
Comment on attachment 711516 [details] [diff] [review]
Adds isWow64 to system-info and to the telemetry ping

Review of attachment 711516 [details] [diff] [review]:
-----------------------------------------------------------------

::: xpcom/base/nsSystemInfo.cpp
@@ +107,5 @@
>      }
>  
> +#ifdef XP_WIN
> +    BOOL isWow64;
> +    BOOL gotWow64Value = IsWow64Process(GetCurrentProcess(), &isWow64);

Just wanted to mention that this API meets our minimum requirement for client OS but not for server OS.  At least this page (http://www.mozilla.org/en-US/firefox/system-requirements.html) lists Windows 2003 but this API requires Windows Server 2003 with SP1.  We should either update that page or load this API dynamically similar to the code example given in http://msdn.microsoft.com/en-us/library/windows/desktop/ms684139%28v=vs.85%29.aspx
Actually we already use it in netwerk so that support page is already invalid.
Looks like that has already been filed under bug 790228 but nobody's updated it.
Attachment #711516 - Flags: review?(benjamin)
Attachment #711516 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/63acc1f62049
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
Comment on attachment 711516 [details] [diff] [review]
Adds isWow64 to system-info and to the telemetry ping

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Intention is to gather telemetry data about WOW64 to make better informed decisions about PGO issues and 64-bit builds
User impact if declined: Telemetry won't be able to tell us about the prevalence of WOW64
Testing completed (on m-c, etc.): On m-c, manually queried isWow64 value from system-info
Risk to taking this patch (and alternatives if risky): Minimal, very simple and easy to test
String or UUID changes made by this patch: None
Attachment #711516 - Flags: approval-mozilla-beta?
Attachment #711516 - Flags: approval-mozilla-aurora?
Comment on attachment 711516 [details] [diff] [review]
Adds isWow64 to system-info and to the telemetry ping

This is not a release-blocker, but it low risk enough that we can take it on Aurora.  We're already past the point of taking any more landings that are not critical on Beta.
Attachment #711516 - Flags: approval-mozilla-beta?
Attachment #711516 - Flags: approval-mozilla-beta-
Attachment #711516 - Flags: approval-mozilla-aurora?
Attachment #711516 - Flags: approval-mozilla-aurora+
Please checkin to Aurora.
Keywords: checkin-needed
Whiteboard: [needs-checkin-aurora]
I confirm the fix is verified on Windows 7 x64 using FF 20.0.1 and FF 21 RC2.

21RC User Agent+Build ID:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0 (20130507220413)

All the following fields are implemented and exist in about:telemetry, showing info as expected:

 >    let fields = ["cpucount", "memsize", "arch", "version", "kernel_version",
 >                  "device", "manufacturer", "hardware",
 >                  "hasMMX", "hasSSE", "hasSSE2", "hasSSE3",
 >                  "hasSSSE3", "hasSSE4A", "hasSSE4_1", "hasSSE4_2",
 >                  "hasEDSP", "hasARMv6", "hasARMv7", "hasNEON"];
 >                  "hasEDSP", "hasARMv6", "hasARMv7", "hasNEON", "isWow64"];
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.