sizeof(HWND) != sizeof(HWND)

Обычно при переносе 32-х разрядного приложения на 64-х битную платформу все исправления касаются только 64-х битного варианта. Однако бывают случаи, когда вполне корректно функционирующий 32-х битный код нуждается в правке только потому, что появился 64-х битный вариант программы.

Предположим, например, что мы разрабатываем простой текстовый редактор - замену notepad.exe. Наш редактор позволяет активировать запущенный ранее экземпляр редактора в случае, если открываемый файл уже открыт в нём. Для передачи данных между двумя экземплярами программы используется секция разделяемой памяти, создаваемая с помощью CreateFileMapping. Передаваемые данные включают описатель окна (HWND) предыдущего экземпляра программы.

Проблема может возникнуть, если установить 32-х и 64-х битную версии программы одновременно. При этом, если пользователь откроет файл в 32-х битной версии редактора, а затем попытается открыть этот же файл в 64-х битной, то при передаче описателя могут возникнуть (и возникают) проблемы с его размером. Замечу, что именно с HWND ничего страшного может и не произойти, поскольку даже в 64-х битном HWND используются только младшие 32 бита. Однако данные, следующие за ним, будут прочитаны начиная с неверного смещения.

Понятно, что исправление подобного бага не займет много времени. Интересно другое - то, что 32-х битный вариант программы тоже нуждается в исправлении. Оговорюсь, что в данном конкретном примере можно обойтись исправлением только лишь 64-х битного варианта. Фактически, это ещё одна иллюстрация тезиса о том, что разделяемая память, как и другие средства IPC, являются “окном во внешний мир” и нуждаются в повышенном внимании со стороны разработчика.