I've seen posts saying it's tricky to cross-compile 32/64 bit (Win). is this out-of-date?
I'd consider that comment out of date because, as long as the proper versions of FPC are installed, compiling for 32 bit or 64 bit is just a few clicks away (in Lazarus.)
I have the option of developing on Win64 (which I do now), then copying/sharing the source files with a Win32 machine on which I have a 32bit version or Lazarus, and compiling my 32-bit version there. Is that the most sensoible?
You can easily generate and test both bitnesses (32/64) on a 64 bit installation. For testing, just share the appropriate folder with the 32 bit Windows installation. That way, in most cases, there is no need to copy/paste anything.
It's straightforward to typecast between a pointer/longint on a 32 bit system, or between pointer/I64 on a 64-bit system.
As others have already mentioned, use ptrint and ptruint whenever appropriate. That way you don't need to write typecasting code that is bitness dependent.
So in my source code I need to know whether compiling/running is on 32 or 64bit. There are presumably a conditional code ways of doing this (details please would sabe me some time, not faniliar with cond code macros}, or I could in the compoled code such as SizeOf(Pointer)-4/8.
The number of cases where it is necessary for the program to know if it is a 32 bit or 64 bit exe are not very common (except when using undocumented features/APIs.) In many cases, that testing can be made unnecessary by simply using ptrint and ptruint (whenever appropriate, of course.)
Recommendations would be helpful, thanks.
The one thing to be really careful about because it is quite common when switching bitness is that some APIs are available only in one bitness or another. For instance, GetClassLongPtr is available only as a 64 bit API. In this particular case, FPC comes to the "rescue" by creating a synonym in 32 bit, it defines GetClassLongPtr as GetClassLong. There are other such cases but, there will be times when you'll have to create the appropriate synonym.
The other thing to be careful about is that, very often going from one bitness to another also means going from one version of Windows to another. As we all know, API availability varies from version to version. That's something to always keep track of when writing code. The general recommendation that can be given in that case is, when in doubt, check the minimum Windows version required for an API.
Also related to Windows versions, some things in Windows don't work the same way depending on version. An (occasionally) important difference is that Windows Vista and above handle window painting differently than Windows XP, to make matters worse, the differences can be configured by the user. That difference alone can cause some problems (though rarely for a normal app, more likely to cause a problem for a system type utility.)
Lastly, be aware that cursor management API, e.g, SetCursorPos, often don't work the same way when Windows is installed in a VM because most VM software traps cursor related APIs from Windows to implement convenient switching features and other features that depend on the VM tracking the cursor accurately. This occasionally causes the VM to get in the way of programs that attempt to control the cursor position. Fortunately, not very many programs are impacted by this but, it's a good thing to be aware of.
HTH.