Migrating from 64 bit to 32 bit

Question

I have a project working on 64 bit architecture.
Now I wish to migrate it to a 32 bit system. It makes use of INT64 pointer manipulations. What changes should I make to the current system ? Some examples explaining possible general changes required will be helpful.
PS: While running the code it throws an error "Invalid address specified to RtlValidateHeap( 004F0000, 02A90EB8 )" and sometimes "Critical error detected c0000374".
I googled both the errors but couldn't find a workaround.

Answer 1

Some things to keep in mind when migrating a x64 application from one bitness to another one (Windows platform)

• check every sizeof() assuming the pointer size is 8

  pointer = (INT64) (other_pointer + sizeof(val));
  

• If you use GUI toolkits directly manipulating windows handles (e.g. MFC) keep in mind that HWND and other internal pointers use a smaller size when running on a 32 bit system (or emulation sysWoW - Windows on Windows)

• Watch out for #ifdef _WIN64 macro spots

• Inline assembly is BAD for portability, also intrinsics are usually platform-specific

• 32 bit apps link against 32 bit libraries only of course, check the dependencies

Finally if the target environment is x86_64 keep in mind that on Windows there might be something different regarding how 32-bit apps are virtualized regarding filesystem and registry writing (they have dedicated subplaces).

Good luck.

Answer 2

In general, using "too large" a storage for pointers should not be an issue in itself. That's like having a 18-digit calculator and only using 9 digits - nothing bad comes from that [and I'm sure that your 64-bit code is not "overflowing" their 64-bit values, even in the lower 48 bits, since that isn't allowed in x86-64 architecture (the code has to distinguish high addresses from low and ensure sign extension is maintained of the lower 48 bits - if this is not done, the processor will throw an exception)].

Of course, to save space, you probably should use intptr_t or uintptr_t rather than INT64, but aside from space, there should REALLY not be a problem with using INT64 to store and manipulate pointers in a 32-bit system [I've worked on code that does exactly that, because the code itself doesn't "know" the underlying bitness]

I suspect that your problem comes from some sort of invalid calculation, but without actually inspecting the code, it's really not possible to say what exactly the problem is.

The heap error sounds like either heap corruption (writing beyond the end of the storage) - one guess would be that the code is making assumptions that INT64 and pointers are the same size. Can be quite hard to say, but if you can catch the error as a breakpoint, then you can PROBABLY look back at the stack to see where the data came from and try to determine what actually happened.

Whilst I said it generally works in the first paragraph, I would also say that using any form of convert pointer to integer, do math, convert integer back to pointer, is a bad thing. Not because it doesn't technically work, but because it is hard to maintain and there are typically other ways of achieving this with proper definitions of the relevant data structures. "Smells bad" as the "smells of code" types would say.