From what I have read, for software which wasn't originally developed for Windows, especially if the code base is old enough, porting to 64-bit is harder on Windows than on other systems.
The problem is that, while the Unix-based world went the LP64 way (int is 32-bit, long and pointers are 64-bit), Windows went the LLP64 way (int and long are 32-bit, pointers are 64-bit). A lot of Unix programmers tended to behave as if "long" was the largest native type ("long long" on 32-bit uses a pair of registers). They have to scrub their whole code base for things like assuming an object's size or array index will always fit on a "long".
----
For Firefox, there's the additional problem of plugins. For a long time, plugins on Windows have been 32-bit, and also for a long time, plugins for Firefox on Windows (and other operating systems) were in-process, so it wasn't possible to use a 32-bit plugin with a 64-bit browser.
Nowadays, not only can Firefox use a separate process for plugins, but also the whole idea of browser plugins seems to be dying, so it's less of a problem.
the whole LP64 vs LLP64 'issue' is a massive red herring.
even in the most despicable code bases this is relatively quick and easy to 'fix', its just one of those things that on the face of it looks like a lot of work, and is genuinely a brainless chore of find and replace with care.
its worth doing right anyway for plenty of reasons beyond portability, like readability and maintainability.
using long on its own imo is a code smell. except for android (and maybe linux, i can't remember otoh) long long is 64-bit and int is 32. but more generally you can macro it away or use some standard size type header and do the replacements to fix it.
the real problems i've seen with 64-bit portability are from bad serialisation code, where struct padding breaks things, and hacks that rely on pointer casts to ints etc. those are less easy because you can't find/replace them and so it requires thought, not just care, to remove those issues safely.
