StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Yes, you'll need to make sure you have 64-bit versions of all DLLs that you reference. And no, it is absolutely not safe to rely on your 32-bit testing! (You knew that already, right?)</p> <p>We ported our system to 64-bit a few years ago and were surprised by a few things:</p> <ul> <li>in general the port was far easier than we had expected</li> <li>the most difficult problems arose in the strangest of places, places we had supposed would be straightforward</li> <li>subsequent builds have been trouble-free</li> </ul> <p>Some examples of the unexpected and tricky problems...</p> <p>Our system includes a Visual Studio project wizard. Visual Studio is 32-bit only, but our customers might still want to target 64-bit machines. So our x86 installer had to include our x64 assemblies. Normally that's OK - the installer spots that we're including x64 files in an x86 project, issues a warning, but continues. But one of these assemblies contains mixed managed/unmanaged code, and our installer couldn't handle that. (We were using the Visual Studio installer at the time, but we've grown up since then.) So we wrote a tool that hex-encodes the 64-bit DLL and writes it to a text file, include that file in the installer project, then have a custom installer step that reverses the encoding and restores the DLL.</p> <p>Our project wizard relies on some COM DLLs, which must be registered in the 32-bit registry because Visual Studio is 32-bit. But on x64 our installer runs as 64-bit and so invokes the 64-bit regsvr32.exe, which registers the DLLs in the wrong place. So we wrote a 64-bit tool that registers the DLLs in the 32-bit registry.</p> <p>It happens that our wizard needs to know where our product is installed. So our installer writes that info to the registry. But on x64 the installer runs as 64-bits and writes that info to the 64-bit registry, but our wizard runs in Visual Studio in 32-bits and so it can't read that part of the registry. So once again we had to write a special tool to let the installer write the info to both sides of the registry.</p> <p>These issues may not sound so bad. After all, the solutions are quite tidy and very small. But consider this: Our system is mixed managed/unmanaged COM/C++ and C#, with third-party libraries such as Boost, Apache HTTPd and OpenSSL, all of which had to be recompiled. I had expected this to be the hard part, but it took only two days to port the relevant bits of code and get the project to compile. Then it took another whole week to understand and fix the problems I've described above. Having said that, I was still very pleasantly surprised that the entire port took only a week and a half.</p> <p>A parting thought... You say you want to take advantage of the power of your 64-bit machines. What does that mean? In very rough terms, unless you need to access more than 2GB of RAM you won't realize any great benefit from running in 64-bits.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload