32 bit vs 64 bit

[mtanner]

Tis question has a general and a specific part.
General: I need to probvide bith 32 and 64-bit versions of my application. I've seen posts saying it's tricky to cross-compile 32/64 bit (Win). is this out-of-date? 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?

Specific part. In my applications I use the object fields, say in a TTeeNode, to store an integer to pass between different routines in my application. It's straightforward to typecast between a pointer/longint on a 32 bit system, or between pointer/I64 on a 64-bit system. 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. Recommendations would be helpful, thanks.

[Bart]

Use PtrInt or PtrUInt (not Integer), they are disigned for that.

W.r.t. cross-compiling (win32/64): it is advised to use use a 32-bit fpc as default for the Windos platform.
The FreePascal team does not release a 64-bit windows version of the compiler (and there are reasons for that).
You then crosscompile to win64 (installing the crosscompiler is as easy as running the setup program for that). This works flawless.
If you uses this often (having 32 en 64 bit releases), then make a 32-bit and a 64-bit buildmode (and save that as comppiler default in Lazarus).

Bart

[lucamar]

As for knowing whether you're compiling for 32 or 64 bit (in case you've code that really needs it and cannot do with the bitness-dependent types) you can use compiler defines:

Code: Pascal  [Select][+][-]

1. {$ifdef CPU32}
2.   { code for 32 bit }
3. {$endif}
4. {$ifdef CPU64}
5.   { code for 64 bit }
6. {$endif}

You've to test for both because there is also CPU16, and more might exist in the future.

You can find this and other predefined simbols in the Programmer's Guide, Appendix G: Compiler defines during compilation

[mtanner]

Thanks for that. You mention that the FPC is only 32-bit. Maybe if it's good enough for FPC then I could just provide a 32-bit version of my app. Are there any downsides to distribution a 32-bit app to users on 64-biT.

If not, and I go with 32-bit only (would make developer life simpler just to have one version),then how do I tell Lazarus (2.0.10) to generate 32-bit code?)

[rvk]

General: I need to probvide bith 32 and 64-bit versions of my application.

Why? Why do you need to provide both 32 and 64 bit versions of your application.
32 bit version will run just fine on 64 bit Windows.

Are there any downsides to distribution a 32-bit app to users on 64-biT.

You don't have immediate access to all the memory. But for most applications this won't be a problem.
And even if you needed that memory... you would also need to take into account that there are 2GB 64bit machines out there.
So, distributing an 32bit version is fine for now (until Microsoft decides to dump 32bit, which isn't any time soon).
(You can however test your code with Lazarus 64 bit from time to time)

If not, and I go with 32-bit only (would make developer life simpler just to have one version),then how do I tell Lazarus (2.0.10) to generate 32-bit code?)

If your Lazarus 2.0.10 is 32bit, it will generate a 32bit application. That's the easiest way.
(On the home page you can click on Other (below the Download button) and choose 32 bit Windows)

[Thaddy]

You mention that the FPC is only 32-bit.

That is wrong. FPC is from 8 to 64 bit. I am always running the 64 bit FPC compiler on both Linux and Windows.
Lazarus can be compiled for 32 and 64 bit. I am using 64 bit for both OS's.
(for many years, but I do compile myself)

[mtanner]

In general I don't need 64-bit. I do have some specialised simulation packages which store event logs in memory, so can be very greedy on memory - so memory directly limits the scale of the simulation that can be done. That is why I thought I should just go with 64-bit as standard. But the simulation stuff is more experimental, and the apps I am distributing are non-simulation. So maybe it was a misguided decision to go 64-bit, and I should just go back to 32-bit, and worry about the simulations another time, not very pressing at the moment.

I assume there are no other dis-benefits, apart from memory,  to 32-bit?

Related question, I have heard that MACs can run Windows apps in some kind of emulator mode. Is that right? And in that context does 32/64 bit make any difference?

Thanks for the advice.

[Bart]

Thanks for that. You mention that the FPC is only 32-bit. Maybe if it's good enough for FPC then I could just provide a 32-bit version of my app. Are there any downsides to distribution a 32-bit app to users on 64-biT.

That is NOT what I said.
The FPC team only releases a 32-bit compiler for the Windows platform.
There are legitimate reasons for that (as the fpc devels).
You can build a 64-bit FPC for Windows quite easily.

Nevertheless, it is easy to build 64-bit windows appilications, as I described in my first reply.

You might want toe ask yourself the question: why do I need a 64-bit version of my program?
64-bit is not necessarily faster that 32-bit (on Win64).
If there is no gain (going 64-bit) then just run the 32-bit on the Win64 machine.

Win64 has it's own drawbacks (no 80-bit extended floating point calculations, currency type in Win64 has some bugs IIRC).

Bart

[mtanner]

Sounds like I should just install the Laz32 bit on my 64-bit machines, makes life simpler for me.

[Thaddy]

Sounds like I should just install the Laz32 bit on my 64-bit machines, makes life simpler for me.

If you want float 80 bit precision, yes, otherwise simply use fpcdeluxe to have a 64 bit install on Windows. It is the Windows ABI, not FPC, that limits the precision.

[PascalDragon]

Sounds like I should just install the Laz32 bit on my 64-bit machines, makes life simpler for me.

With Lazarus on Windows you can simply install the 64-bit variant and then the 32-bit addon which installs an additional 32-bit compiler that is not a cross compiler.

You mention that the FPC is only 32-bit.

That is wrong. FPC is from 8 to 64 bit. I am always running the 64 bit FPC compiler on both Linux and Windows.
Lazarus can be compiled for 32 and 64 bit. I am using 64 bit for both OS's.
(for many years, but I do compile myself)

mtanner meant the compiler itself, not what targets it supports. And for that, FPC supports 32- and 64-bit systems.

Related question, I have heard that MACs can run Windows apps in some kind of emulator mode. Is that right? And in that context does 32/64 bit make any difference?

No, macOS can't run Windows applications by itself. You'd need to use WINE for that (just as on Linux). However on the Intel Macs you can install Windows in parallel to macOS and run that (and then it simply depends on the bitness of the OS).

General: I need to probvide bith 32 and 64-bit versions of my application.

Why? Why do you need to provide both 32 and 64 bit versions of your application.
32 bit version will run just fine on 64 bit Windows.

Except if you want it to run on a Windows PE where the Windows-on-Windows64 subsystem is not installed (which is the default).

[Mr.Madguy]

In Delphi I just switch target platform. Each build configuration and each platform can have it's own folder for files and exe is also put to there.

In old versions of Lazarus I simply switched target CPU, recompiled project and then just copied it to separate Bin32/Bin64 folder manually.

As I know newer versions of Lazarus behave more like Delphi, i.e. create separate folders for different build configurations.

I don't use any special conditions for different platforms - I use cross-platform types only.

I also still make 32bit versions of my programs. Just because I can. There are still some computers with 32bit versions of Windows. For example my old P4+WinXP computer is still alive. And, dunno how to explain, I still respect 32bit platform, because I saw that 16bit->32bit transition moment. It's also good for debugging purposes, because sometimes bugs appear on different platforms only. I also provide 32bit launcher, that picks proper exe automatically and design my applications to work with shared data not to copy-paste it for different platforms.

[AlexTP]

>newer versions of Lazarus behave more like Delphi, i.e. create separate folders for different build configurations.

Yes, my app uses N build-modes and each has its own 'binary path' in own sub-dir.

[440bx]

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.