5 ms·

I have not really written much of Windows code, so forgive my ignorance but: What is actually so hard about porting 32-bit -> 64-bit applications on Windows com

by sannee 9y ago

I have not really written much of Windows code, so forgive my ignorance but: What is actually so hard about porting 32-bit -> 64-bit applications on Windows compared to Linux?

jdlyga 9y ago
Windows is kludgy code built on top of klundgy code. From personal experience, there's different ways Visual Studio handles 32 vs 64 bit applications. A lot of memory issues tend to come up that don't appear in the 32 bit version. Plus there's different directories that are typically used, and potentially a lot of other issues.
- rrdharan 9y ago
  From personal experience porting fairly large and complicated multiplatform userspace application codebase from 32-bit to 64-bit on both Windows and Linux, I think the required effort is about the same. Linux also uses different directories and has "potentially a lot of other issues". Windows uses LLP64 rather than LP64[1] but IMO that's just different not clearly/necessarily better or worse. [1] https://blogs.msdn.microsoft.com/oldnewthing/20050131-00/?p=36563 https://blogs.msdn.microsoft.com/oldnewthing/20050131-00/?p=...
TOM9099 9y ago
The OS doesn't really matter here. If the original developers made assumptions about the size of the pointers (4 vs 8 bytes) then it's a bit tricky but certainly not impossible.
- Phrodo_00 9y ago
  This doesn't hold up, though, because 64-bit firefox has been the default in 64-bit linux for like 10 years, and it's probably existed in windows for about the same amount of time.
  - cesarb 9y ago
    There's an important difference between Linux and Windows, however: on Linux, "long" is always as wide as a pointer, while on 64-bit Windows, a pointer won't fit in a "long" or "LONG" or "DWORD". But the real reason 64-bit Firefox is the default on 64-bit Linux, is that 64-bit Linux usually doesn't have the 32-bit compatibility libraries installed by default. On Windows, on the other hand, 32-bit compatibility libraries are always available.
    - anonymfus 9y ago
      Server Windows versions can have WOW64 disabled.
      - deleted 9y ago
        [deleted]
conductor 9y ago
Here's is a good summary of possible issues porting 32-bit C++ code to 64-bit from PVS-Studio developers. https://www.viva64.com/en/a/0004/ https://www.viva64.com/en/a/0004/
jaas 9y ago
IIRC, in the case of Firefox the problem was not porting Firefox itself to 64-bit. That was done a long time ago. The problem was all of the 32-bit dependencies people had installed. For example - if a user only had 32-bit Flash installed and they updated or installed 64-bit Firefox, they'd be annoyed that Flash "broke". That might not be the best or most current example, but it's that kind of thing that held up 64-bit default on Windows.
nikic 9y ago
Windows is an LLP64 platform, meaning that the "long" type on Windows stays at 32bit even when you're compiling 64bit binaries. Getting 64bit integer support for PHP on Windows took a major port of all basic type usage to move away from longs to custom types with a higher degree of control. I don't know whether or not this was a problem for Firefox or not.
- khuey 9y ago
  This particular problem was never really an issue for Mozilla, because the codebase has used fixed width types (first the NSPR types and later the stdint.h types) for 20 years.
- user5994461 9y ago
  To clarify: When compiling in 64 bits mode, the "long" type is 64 bits on gcc and 32 bits on msvc. The other compilers vary. The C standard only specifies that int has to be at least 32 bits. That's one of the many issues of porting from 32 to 64 bits.
  - syncsynchalt 9y ago
    Sorry to nitpick, but the C standard specifies that int must be at least 16 bits, and that long is at least 32 bits. (Actually, it just specifies the minimum range, and tries not to be specific as to the bit representation). https://en.wikipedia.org/wiki/C_data_types https://en.wikipedia.org/wiki/C_data_types
    - user5994461 9y ago
      Typo. I meant to write long, not int ^^
  - deleted 9y ago
    [deleted]
  - cygx 9y ago
    When compiling in 64 bits mode, the "long" type is 64 bits on gcc and 32 bits on msvc. That's not true for MinGW, and for good reasons (deviating from the ABI followed by the OS and all libraries would be stupid).
jcranmer 9y ago
The biggest issue is Flash. You can't run 32-bit plugins in a 64-bit process (well, there are some potential workarounds, but nothing I'd want to do for production work). A lesser issue is that the x86-64 JIT for JS was generally worse in performance than the 32-bit x86 JIT, although this has been fixed for a few years now. It's not that Firefox couldn't be 64-bit on Windows, it's that the developers didn't feel it was ready to ship it to a large userbase.
- kalleboo 9y ago
  > The biggest issue is Flash. You can't run 32-bit plugins in a 64-bit process (well, there are some potential workarounds, but nothing I'd want to do for production work). On Mac I believe both Firefox and Safari used a separate broker process to go between 32-bit plugins and the 64-bit browser. Is it that much messier to do on Windows?
  - jaas 9y ago
    This is a bit long, but I know the answer in detail because I'm the one who originally wrote to code to make 32-bit plugins work in 64-bit Firefox on OS X :) I'll never forget the moment I first got a YouTube video to play properly in 64-bit Firefox with 32-bit Flash. It was much easier to do on OS X than on Windows. That's primarily because on OS X, at least at the time, Firefox was a Universal Binary, meaning there were complete 32-bit and 64-bit binaries for OS X in the same application package. We had been doing this for reasons I won't get into here, but they were unrelated to running plugins with mismatched bit-ness. That being the case though, we "just" (devil is in the details) started a 32-bit child process, which had all the same functionality (e.g. plugin code implementation) as the 64-bit process, and made sure that plugin API data going between the processes was always fixed length (e.g. int32 vs plain int) so there was no misinterpretation. Mozilla could probably have done something very similar on Windows, but they weren't already installing both 32-bit and 64-bit binaries on every Windows machine. Doing that just for the sake of plugins would, at a minimum, have been a big bullet to bite. And there was/is no nice Universal Binary package equivalent on Windows. Also, and this gets more nitty-gritty, the NPAPI plugin API on OS X was much easier to get working across two processes of different bit-ness. This was mainly because we had recently revised the OS X NPAPI (we called it Cocoa NPAPI or something like that) and got Adobe and many others to switch. The revised API was much easier to work with. The ancient Windows NPAPI was, and is, a total f*ing mess.
josteink 9y ago
> I have not really written much of Windows code, so forgive my ignorance but: What is actually so hard about porting 32-bit -> 64-bit applications on Windows Speaking strictly about things surrounding your code, as opposed to the code itself, there's stuff you just don't have on Linux. On Linux pretty much everything is open source and provided by your distro, built for your architecture. The need for compatibility layers are absolutely minimal. This has a resounding positive effect in that quite a lot of things can be assumed fixed and in place. On Windows, not so much. Most applications are pre-built by others. Most are 32-bit. So Microsoft tries to maintain backwards compatible execution environments for both 32-bit code and 64-bit code in Windows. This means that 32-bit processes trying to access system DLLs, will need to find 32-bit system DLLs somewhere. Same for 64-bit. So you have duplication of system-DLLs, in different folders. You can't just assume a standard, fixed path will lead you to the right place. For the COM subsystem, all the available components an application can access is stored in the registry, alongside their physical path on disk. You may need different DLL-files for these COM components in 32-bit processes and 64-bit processes. So now you need the registry to point to different locations based on the bitness of the application running. So yeah. Portions (but not all parts!) of the registry is also duplicated with different references for different processes. That means that when going from a 32-bit process to 64-bit process, all things you've previously written to the registry... May not be there for you to read in your 64-bit process. And you better make sure your installer is the same bitness as your process... Or you know what? That 32-bit installer wont be allowed to prime the 64-bit registry your application needs! This may mean that all COM components you've registered in your installer, now is inaccessible to your (and other) applications because they are 64-bit. And I'm sure the list goes on. These are just the most obvious non-pointer based things I can think of which complicates matters. In short: On Windows... Keeping everything 32-bit and closing your eyes to all terrible things mentioned above will ensure your application keeps working, because Microsoft put in the effort to guarantee that. The second you step into 64-bit, you need to have all these things solved. There's no going half-way. So most people who has little to benefit from 64-bit executables simply don't.

by sannee 9y ago

I have not really written much of Windows code, so forgive my ignorance but: What is actually so hard about porting 32-bit -> 64-bit applications on Windows compared to Linux?

jdlyga 9y ago

Windows is kludgy code built on top of klundgy code. From personal experience, there's different ways Visual Studio handles 32 vs 64 bit applications. A lot of memory issues tend to come up that don't appear in the 32 bit version. Plus there's different directories that are typically used, and potentially a lot of other issues.

rrdharan 9y ago
From personal experience porting fairly large and complicated multiplatform userspace application codebase from 32-bit to 64-bit on both Windows and Linux, I think the required effort is about the same. Linux also uses different directories and has "potentially a lot of other issues". Windows uses LLP64 rather than LP64[1] but IMO that's just different not clearly/necessarily better or worse. [1] https://blogs.msdn.microsoft.com/oldnewthing/20050131-00/?p=36563 https://blogs.msdn.microsoft.com/oldnewthing/20050131-00/?p=...

TOM9099 9y ago

The OS doesn't really matter here. If the original developers made assumptions about the size of the pointers (4 vs 8 bytes) then it's a bit tricky but certainly not impossible.

Phrodo_00 9y ago
This doesn't hold up, though, because 64-bit firefox has been the default in 64-bit linux for like 10 years, and it's probably existed in windows for about the same amount of time.
- cesarb 9y ago
  There's an important difference between Linux and Windows, however: on Linux, "long" is always as wide as a pointer, while on 64-bit Windows, a pointer won't fit in a "long" or "LONG" or "DWORD". But the real reason 64-bit Firefox is the default on 64-bit Linux, is that 64-bit Linux usually doesn't have the 32-bit compatibility libraries installed by default. On Windows, on the other hand, 32-bit compatibility libraries are always available.
  - anonymfus 9y ago
    Server Windows versions can have WOW64 disabled.
    - deleted 9y ago
      [deleted]

conductor 9y ago

Here's is a good summary of possible issues porting 32-bit C++ code to 64-bit from PVS-Studio developers. https://www.viva64.com/en/a/0004/ https://www.viva64.com/en/a/0004/

jaas 9y ago

IIRC, in the case of Firefox the problem was not porting Firefox itself to 64-bit. That was done a long time ago. The problem was all of the 32-bit dependencies people had installed. For example - if a user only had 32-bit Flash installed and they updated or installed 64-bit Firefox, they'd be annoyed that Flash "broke". That might not be the best or most current example, but it's that kind of thing that held up 64-bit default on Windows.

nikic 9y ago

Windows is an LLP64 platform, meaning that the "long" type on Windows stays at 32bit even when you're compiling 64bit binaries. Getting 64bit integer support for PHP on Windows took a major port of all basic type usage to move away from longs to custom types with a higher degree of control. I don't know whether or not this was a problem for Firefox or not.

khuey 9y ago
This particular problem was never really an issue for Mozilla, because the codebase has used fixed width types (first the NSPR types and later the stdint.h types) for 20 years.
user5994461 9y ago
To clarify: When compiling in 64 bits mode, the "long" type is 64 bits on gcc and 32 bits on msvc. The other compilers vary. The C standard only specifies that int has to be at least 32 bits. That's one of the many issues of porting from 32 to 64 bits.
- syncsynchalt 9y ago
  Sorry to nitpick, but the C standard specifies that int must be at least 16 bits, and that long is at least 32 bits. (Actually, it just specifies the minimum range, and tries not to be specific as to the bit representation). https://en.wikipedia.org/wiki/C_data_types https://en.wikipedia.org/wiki/C_data_types
  - user5994461 9y ago
    Typo. I meant to write long, not int ^^
- deleted 9y ago
  [deleted]
- cygx 9y ago
  When compiling in 64 bits mode, the "long" type is 64 bits on gcc and 32 bits on msvc. That's not true for MinGW, and for good reasons (deviating from the ABI followed by the OS and all libraries would be stupid).

jcranmer 9y ago

The biggest issue is Flash. You can't run 32-bit plugins in a 64-bit process (well, there are some potential workarounds, but nothing I'd want to do for production work). A lesser issue is that the x86-64 JIT for JS was generally worse in performance than the 32-bit x86 JIT, although this has been fixed for a few years now. It's not that Firefox couldn't be 64-bit on Windows, it's that the developers didn't feel it was ready to ship it to a large userbase.

kalleboo 9y ago
> The biggest issue is Flash. You can't run 32-bit plugins in a 64-bit process (well, there are some potential workarounds, but nothing I'd want to do for production work). On Mac I believe both Firefox and Safari used a separate broker process to go between 32-bit plugins and the 64-bit browser. Is it that much messier to do on Windows?
- jaas 9y ago
  This is a bit long, but I know the answer in detail because I'm the one who originally wrote to code to make 32-bit plugins work in 64-bit Firefox on OS X :) I'll never forget the moment I first got a YouTube video to play properly in 64-bit Firefox with 32-bit Flash. It was much easier to do on OS X than on Windows. That's primarily because on OS X, at least at the time, Firefox was a Universal Binary, meaning there were complete 32-bit and 64-bit binaries for OS X in the same application package. We had been doing this for reasons I won't get into here, but they were unrelated to running plugins with mismatched bit-ness. That being the case though, we "just" (devil is in the details) started a 32-bit child process, which had all the same functionality (e.g. plugin code implementation) as the 64-bit process, and made sure that plugin API data going between the processes was always fixed length (e.g. int32 vs plain int) so there was no misinterpretation. Mozilla could probably have done something very similar on Windows, but they weren't already installing both 32-bit and 64-bit binaries on every Windows machine. Doing that just for the sake of plugins would, at a minimum, have been a big bullet to bite. And there was/is no nice Universal Binary package equivalent on Windows. Also, and this gets more nitty-gritty, the NPAPI plugin API on OS X was much easier to get working across two processes of different bit-ness. This was mainly because we had recently revised the OS X NPAPI (we called it Cocoa NPAPI or something like that) and got Adobe and many others to switch. The revised API was much easier to work with. The ancient Windows NPAPI was, and is, a total f*ing mess.

josteink 9y ago

> I have not really written much of Windows code, so forgive my ignorance but: What is actually so hard about porting 32-bit -> 64-bit applications on Windows Speaking strictly about things surrounding your code, as opposed to the code itself, there's stuff you just don't have on Linux. On Linux pretty much everything is open source and provided by your distro, built for your architecture. The need for compatibility layers are absolutely minimal. This has a resounding positive effect in that quite a lot of things can be assumed fixed and in place. On Windows, not so much. Most applications are pre-built by others. Most are 32-bit. So Microsoft tries to maintain backwards compatible execution environments for both 32-bit code and 64-bit code in Windows. This means that 32-bit processes trying to access system DLLs, will need to find 32-bit system DLLs somewhere. Same for 64-bit. So you have duplication of system-DLLs, in different folders. You can't just assume a standard, fixed path will lead you to the right place. For the COM subsystem, all the available components an application can access is stored in the registry, alongside their physical path on disk. You may need different DLL-files for these COM components in 32-bit processes and 64-bit processes. So now you need the registry to point to different locations based on the bitness of the application running. So yeah. Portions (but not all parts!) of the registry is also duplicated with different references for different processes. That means that when going from a 32-bit process to 64-bit process, all things you've previously written to the registry... May not be there for you to read in your 64-bit process. And you better make sure your installer is the same bitness as your process... Or you know what? That 32-bit installer wont be allowed to prime the 64-bit registry your application needs! This may mean that all COM components you've registered in your installer, now is inaccessible to your (and other) applications because they are 64-bit. And I'm sure the list goes on. These are just the most obvious non-pointer based things I can think of which complicates matters. In short: On Windows... Keeping everything 32-bit and closing your eyes to all terrible things mentioned above will ensure your application keeps working, because Microsoft put in the effort to guarantee that. The second you step into 64-bit, you need to have all these things solved. There's no going half-way. So most people who has little to benefit from 64-bit executables simply don't.