64 bit apps. Worth it?

that’s what i mean… :slight_smile: isn’t 32bit producing the build with an own compiler-backend, but 64bit using the LLVM backend?
That certainly accounts for a (big) difference…

[quote=376957:@Jürg Otter]that’s what i mean… :slight_smile: isn’t 32bit producing the build with an own compiler-backend, but 64bit using the LLVM backend?
That certainly accounts for a (big) difference…[/quote]
not like we have a choice is there?

and why all this talk about 32+64 combined… that isn’t a “choice” either.

again not worth arguing about

A 64bit app isn’t (necessarily or in my experience) smaller than a 32bit app.
Moving to 64bit only means OSX itself can be ‘half the size’ (although let’s be realistic… ‘smaller’)
And that assumes that (as an upgrade) at some point the OSX installer does a trawl and deletes all the 32bit libraries.
The question is about Windows, however. If you ship only 64bit, there may be some folk you cannot supply.
If you ship 32bit, it works for everyone.

[quote]

Apple probably have a plan to move to different hardware in a few years so they are getting everyone migrated ahead of time.[/quote]
But… doesn’t that mean replacing everything all over again (eg for ARM code)?

the “shame”ing you are referencing to is to get the “mass crowd” will help convince you of what you are doing is wrong or against of what they want from you. I don’t agree with using this method of trying to get people to make changes. But with the massive use of social media and people living/dyeing by it makes this method more and more popular.

I try to no adhere to either side of that methodology….

—sb

Smaller binaries: on Mac, 32 and 64 bit code is hosted in the same executable, so if you build a “universal” app you will have roughly twice the executable code size. Of course other resources like images, movies, UI layout files can be shared.

Smaller test footprint: you have to test a 32-bit and 64-bit app separately since they are effectively two apps that just happen to live in the same application bundle. If you ship a universal app and you never test your 32-bit app, you are probably missing some bugs.

The final issue is on macOS, loading just one 32-bit app will cause the OS to load all its 32-bit libraries, just for the benefit of that one app, taking ram and disk space away from 64-bit processes.

[quote=376959:@Dave S]and why all this talk about 32+64 combined… that isn’t a “choice” either.
[/quote]

It may not be a UI choice in Xojo, but you can build your own universal app on macOS using the lipo tool and combining your 32-bit and 64-bit executables.

And I get that a 64-bit Xojo app may be larger than a 32-bit Xojo app, of course. But as Christian pointed out, different compilers. If you use the same compiler (like llvm) you get roughly the same size on 32 and 64 bits.

And it seems that entire VS2017 IDE and tools are still 32-bit.

https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/2255687-make-vs-scalable-by-switching-to-64-bit?page=1&per_page=20

Microsoft has been working on the Windows 10 on ARM which currently would only be running x86 applications so 32 Bit is still going to be relevant in the new Microsoft Paradigm .

https://www.theverge.com/2018/2/19/17027026/microsoft-windows-10-on-arm-apps-games-limitations-support

Personally I would compile both 32 Bit and 64 Bit.

That’s like comparing lemons and oranges (purposely stayed away from using the fruit company). I think we can all agree that the 64bit binaries are not necessarily smaller than the 32bit binaries. But in some deployment choices (where combined binaries are deployed) 64 bit only binaries make a significant difference. I think we can also agree that for Mac and Linux the expectation is 64 bit. And for Windows the expectation (at least for the foreseeable future) is 32 bit, maybe augmented with it’s 64 bit counterpart.

MS will wait the ecosystem kill the OS for them, and it’s already occurring. https://www.engadget.com/2017/12/24/nvidia-is-gearing-up-to-end-32-bit-os-support/

Sure, but that is the OS. You’d be a fool to buy a 32-bit version of Windows, because of the memory size limitation. I can’t remember the last time we sold a 32-bit system.

Love that.
The first version of the app I mostly sell now, was written on a blue iMac with 32Mb memory. (OK… yes… I admit that ran out of memory now and then)
And that was a joy compared to the Windows machines I had had before that , say around 1996, with 4Mb.
Strangely, I don’t recall Word, Excel or any other app that I needed on a daily basis , taking 4 hours to do a job or 10 minutes to start.
Almost as if the steady move to Gigabyte memory and Gigahertz processors hadn’t made much difference to how long it takes to perform a task.

[quote=376909:@Stephen Dodd]Given the extra effort to build, support and manage installation of both 32 bit and 64 bit Windows apps, is it worth supporting 64 bit apps?

Apple will soon be chastising developers with shame messages on every 32 bit Mac app launch. Is there any indication of Windows limiting 32 bit apps in the near-ish future?

What are the clear 64 bit advantages?[/quote]

Microsoft and Apple have very different approaches. Windows comes in two flavors, 32 and 64 bits, unlike Apple which has had 64 bit only since mountain Lion if I am not mistaken.

Windows will probably remain able to run 32 bits for a very, very long time.

The main advantage of 64 bit is memory addressing, which for Windows is limited to some 3.5 GB in 32 bits.

Note that in the Windows Store, most applications are 32 bits ; 64 bits is the exception, and it is not encouraged by Microsoft for compatibility reasons.

I bought Scrivener for Windows, a 32bit application in Augustus 2017, just answering the “Do you still buy 32bit applications?”.

I am also beta testing the Scrivener 3 for Windows and it is also 32bit. As long as the application does what I want it to do, it is fine for me.

Better a good working 32bit application than a bad working 64bit application. I can’t be bothered as long as I can finish the job.

I do prefer build for 64bits, and if someone asks, think if I want to support the old and dying 32bit too or focus on the current modern platforms with bigger market share . But that’s me, Apple, Linux Distros, NVidia, Adobe, etc.

The technical level of Windows users is nothing like Linux users. The market is quite different as well. Most are probably incapable of telling if their system is 32 or 64 bit.

FWIW I don’t think the actual park is anywhere near the Steam survey. What really distinguishes Windows from other platforms is a huge installed base, which somehow I doubt extremely much it be overwhelmingly 64 bit.

Also, low end laptops and desktop machines are usually fit with 32 bits version of Windows. Which encompasses almost all windows tablets.

The best approach for consumer software (custom development is something else) if one likes better 64 bit, or has good reasons to use the larger memory, would be to use a conditional branching in the installer to detect the type of system, and install accordingly.

Takes me a few minutes to make a single installer for both 32 and 64 bit using Inno Setup.

Add two folders to the Inno folder for my 32 and 64 bit builds.
Tell the setup to copy the whole contents of each folder to the program files folder relevant to the OS.

[code];Use this to put 64 bit in ‘Program Files’ instead of ‘Program Files (x86)’
ArchitecturesInstallIn64BitMode=x64

[Files]
;x64
Source: “64bit\"; DestDir: “{app}”; Flags: ignoreversion recursesubdirs createallsubdirs; Check: Is64BitInstallMode
;x86
Source: "32bit\
”; DestDir: “{app}”; Flags: ignoreversion recursesubdirs createallsubdirs; Check: not Is64BitInstallMode
[/code]
All other parts of the installer are identical so they don’t include Is64BitInstallMode check.

Each new version just compile, copy to folders, then hit build. Done.

Craig, how do you you deal with the Start menu shortcuts ?

Nice. But I assume this doubles the size of the installer?