Hi, Kyle -
I've previously looked into this issue, and here's what I know:
The following PFC-level objects need to be refactored: pfc_n_cst_environment, pfc_n_cst_filesrv, pfc_n_cst_filesrvunicode, pfc_n_cst_numerical, pfc_n_cst_platform, & pfc_n_cst_platformunicode. Some of these have internal object structures that also need refactoring, to replace certain Long/ULong members with the LongPtr datatype.
If any API calls used by the PFC set the length of a structure argument in the structure itself or as a separate argument, the length will probably increase in 64-bit due to various reasons.
The PFC-level objects reference the following Windows system DLL's: user32,dll, kernel32.dll, gdi32.dll, winmm.dll, & shell32.dll. The DLL names do NOT change in a 64-bit executable (there is no user64.dll, for example).
Of course, any WinAPI functions invoked by PFE-layer objects (local extension objects inherited from the PFC-layer objects, for those not familiar with PFC architecture) will also need to be refactored.
Hope this helps you a little.
I suspect that the MS-Windows API's will need to the refactored from ANSI to Unicode as well.
For example: FindWindowA => FindWindowW
Regards ... Chris