Closed Bug 1094013 Opened 10 years ago Closed 9 years ago

Bump the minimum subsystem version to 6.01 on Win64

Categories

(Firefox Build System :: General, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla36

People

(Reporter: emk, Assigned: emk)

References

Details

Attachments

(2 files)

Because we only support Win7 or later.
Blocks: 1094012
Comment on attachment 8517409 [details] [diff] [review]
Bump subsytem version to 6.1 (Win7) for Win64 builds

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

::: js/src/configure.in
@@ +1764,5 @@
>          dnl Set subsystem version 5 for Windows XP.
>          if test "$CPU_ARCH" = "x86"; then
>              WIN32_SUBSYSTEM_VERSION=5.01
>          else
> +            WIN32_SUBSYSTEM_VERSION=6.01

We may or may not want to keep compatibility with older systems for standalone js builds, but that's something for some js peer to say.
Attachment #8517409 - Flags: review?(mh+mozilla)
Attachment #8517409 - Flags: review?(luke)
Attachment #8517409 - Flags: review+
Comment on attachment 8517409 [details] [diff] [review]
Bump subsytem version to 6.1 (Win7) for Win64 builds

I haven't the foggiest.  Redirecting to module owner.
Attachment #8517409 - Flags: review?(luke) → review?(jorendorff)
Note that this is a prerequisite for bug 1094012 and js uses WindowsVersion.h. Once bug 1094012 landed, RandomizeIsBroken() will not return the expected result on WinXP/2003.
Comment on attachment 8517409 [details] [diff] [review]
Bump subsytem version to 6.1 (Win7) for Win64 builds

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

We definitely want to follow Gecko on this. If an embedder complains, we can revisit, but I would be shocked if any did.
Attachment #8517409 - Flags: review?(jorendorff) → review+
Keywords: checkin-needed
This was bug 862655 and hidden by bug 1001332.
Depends on: 862655
Minimized testcase (paste it into ScratchPad and click "Display" in the Browser context):
panel = document.createElement("panel");
panel.setAttribute("noautohide", true);
panel.setAttribute("titlebar", "normal");
button = document.createElement("button");
panel.appendChild(button);
button.label = "OK";
button.width = 120;
button.height = 40;
button.setAttribute("style", "-moz-appearance: none; border: 0; margin: 0;");
panel.setAttribute("style", "-moz-appearance: none; border: 0; margin: 0;");
document.documentElement.appendChild(panel);
panel.openPopupAtScreen(200, 210); panelrect = panel.getBoundingClientRect();
JSON.stringify({left:panelrect.left,top:panelrect.top,mozInnerScreenX:mozInnerScreenX,mozInnerScreenY:mozInnerScreenY})

With subsystem version 6.01:
/*
{"left":196.8000030517578,"top":234.8000030517578,"mozInnerScreenX":9.600000381469727,"mozInnerScreenY":4}
*/
With subsystem version 5.01:
/*
{"left":191.60000610351562,"top":229.60000610351562,"mozInnerScreenX":9.600000381469727,"mozInnerScreenY":4}
*/

|panelrect.top <= 210 - mozInnerScreenY + 30| still holds for me, but the popup is actually shifted. So this is a real bug.
Also the 6.01 popup has a shadow even on Win8.1.
https://hg.mozilla.org/integration/mozilla-inbound/rev/bc265b6fc1ad
Assignee: nobody → VYV03354
Status: NEW → ASSIGNED
Flags: in-testsuite-
https://hg.mozilla.org/mozilla-central/rev/bc265b6fc1ad
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Please update here: http://dxr.mozilla.org/mozilla-central/source/browser/installer/windows/nsis/stub.nsi#313

Otherwise Vista x64 users will succeed the install but just get a cryptic message about "firefox.exe is not a valid Win32 application"
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
And what about Vista x64 nightly users when the update runs tomorrow?
It would have been nice to give people some warning, at least...
That's bug 1093741. This bug is fixed.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Depends on: 1105566
(In reply to David Major [:dmajor] (UTC+13) from comment #14)
> And what about Vista x64 nightly users when the update runs tomorrow?

Filed bug 1105566.
Jeez.
The nightly x64 build silently stopped working after the update today on my 2003 x64 after 3 years of uninterrupted work, tests, and feedback by telemetry, health report, crash reporter.
I never lost my profile nor my session with  a hundred of tabs nor had to reinstall.
In a word: PERFECT. Now this :

2 bytes in a PE header and no more awesome x64 firefox, thank you guys ;-( ;-( ;-(
> 2 bytes in a PE header

Not at all. I made some optimizations assuming x64 binaries will never run on pre-Win7 (bug 1094012 and bug 1094016). So I had to block executing on those versions.
For example, this Firefox can't play WebGL. It will not detect switching IME correctly. It will create Internet Shortcuts with a broken icon, etc. I can't enumerate all possible breakage, hence blocking execution.
 noowayy by design? I finally get Windows XP Pro 64bit (I dislike Win7 and find Win8 Garbage UI)

plus this PC is 2006-2007 Mobo with new HDDs and a Nvidia GTX 750 Ti SC 2GB
CPUz report:  http://valid.x86.fr/fakxfs
so Mobo drivers are not available for Win7 for me... nor the $$$$ to build a new system yet....
Windows XP is no longer supported by Microsoft. You can nevertheless continue to use the officially supported 32-bit Firefox builds (64-bit builds are not officially supported yet).
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #23)
> Windows XP is no longer supported by Microsoft. You can nevertheless
> continue to use the officially supported 32-bit Firefox builds (64-bit
> builds are not officially supported yet).

yah yah loi.... still I prefer Windows XP Pro over anything newer...
I will continue to use 32bit version till the 64bit version gets released

any how I tried the manual hack using "CFF Explorer" some one recomended
so I changed the:
- Major Operating System Version (6 --> 5)
- Minor Operating System Version (1 --> 2)
- Major Subsystem        Version (6 --> 5)
- Minor Subsystem        Version (1 --> 2)

C:\Program Files\Mozilla Firefox_64bit__Nightly\
- Firefox.exe
- plugin-container.exe
- plugin-hang-ui.exe
- crashreporter.exe
- updater.exe

Is there any other exe/dll I should change?

I hope some day soon Mozilla will again offer basic support again at least compiling it so it can be run without hacking it every time...
because between the cost of new High quality hardware (like Asus and Nvidia things that can run a new OS slick like lightning...  and the cost of M$ OSs...
Please read comment #19. 64-bit Firefox will attempt to use functionality that is only available on Windows 7 and up, and will crash. If it doesn't crash right away that's just because it doesn't depend on this functionality to start up, but it may crash at any time.

You're better off just continuing to use the 32-bit version, which still supports Windows XP. Your hacks will never work right unless you create a local build with bug 1094012 backed out.
great.... :(  except the 32bit version is sluggish on XP 64bit.... and my system is too old for Win7.... and I don't have the $$ to build newer...

(In reply to Masatoshi Kimura [:emk] from comment #19)
> > 2 bytes in a PE header
> 
> Not at all. I made some optimizations assuming x64 binaries will never run
> on pre-Win7 (bug 1094012 and bug 1094016). So I had to block executing on
> those versions.
is there any other way you can optimize Firefox so WinXP-Pro-64bit can  use 64bit Firefox?

"assuming x64 binaries will never run"
now now I am doing just that, please read my other comments above for what I have to say Masatoshi..

ooh so this is about D3DCompiler yah I saw those files..

my Firefox 32bit install has both of these... 
D3DCompiler_43.dll (v9.29.952.3111)
D3DCompiler_46.dll (v9.30.9200.20789)
is 43 left over from an older install? safe to delete?

Firefox64bit
D3DCompiler_47.dll (v6.3.9600.16384)
(In reply to Joseph DeVore from comment #26)
> is there any other way you can optimize Firefox so WinXP-Pro-64bit can  use
> 64bit Firefox?

It is impossible by definition. Some optimizations involve removing XP-only code-path.

> my Firefox 32bit install has both of these... 
> D3DCompiler_43.dll (v9.29.952.3111)
> D3DCompiler_46.dll (v9.30.9200.20789)
> is 43 left over from an older install? safe to delete?

_43 is left for WinXP. Firefox 32-bit still supports WinXP. You can't remove it as long as you are running Firefox on WinXP. Otherwise WebGL will not work.
well if 43 is used for WebGL... what about 46? and are both necessary?

which in short will force people to upgrade to windows 7 ($$$) or newer or be left behind.... ;_; :(
Our installer won't change installed files based on the OS version. So _46 is installed on WinXP despite that it will not be used. Conversely, _43 will be installed even on Vista+.
This is off-topic for this bug. Please take this discussion elsewhere.
Depends on: 1113912
FYI, most Vista drivers should run in Win7 and Win8, and this includes 64-bit Vista drivers when run on 64-bit Win7.
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.