64 bit apps. Worth it?

Hi,
still did not switch to 64 bits for build due to currency type.

[quote]Another issue for 64-bit builds is the Currency data type. According to long time Xojo developer Kem Tekinay using Currency is not recommended in 64-bit builds due to comparison issues.
[/quote]
From this article https://www.bkeeneybriefs.com/2017/12/xojo-2017-r3/ But I don’t know if it’s applicable or not

While they don’t fix, you may try this: https://forum.xojo.com/45817-money-class-currency-alternative

Until MS stops 32-bit apps from running I would still build a 32-bit for Windows as, unless your app requires more RAM than a 32-bit app can use, there is no reason to build a 64-bit app. There will be a time just like when MS ditched the 16-bit compatibility layer. Windows user shouldn’t complain about the bit-ness of an app as the 64-bit versions of Windows XP, Vista, 7, 8, 8.1 and 10 all support running 32-bit code.

On macOS there is no choice, you need to build a 64-bit if you want to submit it to the App Store as Apple will stop accepting 32-bit apps (if it hasn’t already). Maybe not the macOS 10.14 but 10.15 will almost certainly completely drop 32-bit support just as iOS 11 did.

My main OS is Mac and out of curiosity I checked how many 32-bit apps I have installed and even Adobe is still releasing 32-bit apps such as their installers. Even Apple’s own DVD Player (on 10.13.3 btw) is 32-bits. Even Roxio’s Toast 16 Pro is still 32-bit.

FWIW, Adobe is also, very slowly, ditching 32bit. As you can see in some products like Lightroom: https://forums.adobe.com/thread/1834104

It is all a matter of market opportunity. There is no one size fit all. Sure, eventually 32 bit will go the way of Windows 98, but it may still be premature for some markets.

Everything else is the same for both. Inno Setup will create the same Start menu for either system.

Yes from 7mb to 16mb. Not a worry.
Having a universal installer for Windows takes away a lot of problems, many users don’t know what system they have and which installer to download. Waiting a few seconds for a common installer to download hasn’t caused any complaints.
If you want to reduce the installer file size further install the same Resources folder on both systems, then you only need to package it once.

For services such as a Web app running standalone I would expect a 64bit build to be a must and maybe for end user products that involve a heap of graphics manipulation on large images. For normal applications follow MS’s lead (e.g. Office) and continue to use 32bit builds. An exception to this might be when you need your app to have elevated privileges which is now supported with 64 bit builds.

Hahahahaha

The newly introduced Text DLL is 20Mb on its own.
What are you shipping… "Hello w’ ? :slight_smile:

(ps… I dont actually need to know.
My own apps would end up at leat 10 times that.
I do worry but apparently I shouldnt)

Sorry Emile I just can’t thank Xojo enough for the 64bit version.
As soon as I distributed my app as 64bit my programs Facebook page lit up with nothing but praise. A huge improvement in speed.

I take it you have used aggressive optimization ?

Is there a button for that? It’s the same code as the 32bit.

I didn’t notice any improvement on my high end computer but there’s a lot of users out there with budget computers with just enough processing power to run Windows and not much else.
Running the extra layer of 32bit architecture really chews up resources.

Uses all the available memory without memory disk swaps, removes the WoW64 Win32 emulator layer and runs natively.

[quote=377556:@Craig Grech]@Michel Bujardet I take it you have used aggressive optimization ?

Is there a button for that? It’s the same code as the 32bit.[/quote]

In Shared build settings, Build/Optimization level. You got the choice between Default, Moderate, and Aggressive. Compilation in Aggressive is slow, but the executable is supposed to be a lot faster.

Thanks Michael, I didn’t know that existed. Will try. Every little bit helps.

I had switched to 64-bit Windows builds last year. Then 32-bit users complained that they can’t install the software. I was told on this forum that 32-bit builds will run on both 64-bit and 32-bit Windows. So I switched back to 32-bit builds. This seemed to work for about a year. Then recently (in the past month) I received weird crash reports from a 64-bit Windows user who installed my 32-bit build. Nothing I can reproduce. So I compiled a 64-bit build and asked them to try it. And that worked for them. Why that should be the case, is beyond me. I had one other similar case. The fact that a 32-bit build did not work on these customers’ 64-bit machines is enough for me to start offering both builds, because I offer demos for download to test, and I know in the case this incompatibility appeared and the app doesn’t run, instead of getting a note I would just lose a potential customer. It takes maybe 10 minutes more per app to manage both 32- and 64-bit builds, but it seems necessary now.

Because you’re only using one set of libraries instead of two. Any OS which supports 32- and 64-bit is doing just what Apple used to do when it switched from 68000 to PowerPC to Intel processors: supplying two sets of everything. So every framwork, every library the OS has, has to be supplied by Apple or MS in both 32 and 64 bit versions.

By ditching 32-bit, Apple is reducing to one set of everything. Of course, moving to ARM is going to double it again until that transition is over.

When Apple stopped supporting PowerPC apps via Rosetta, I saw plenty of people who thought that all they needed to do was install the missing Rosetta app (or library, whatever it was). Wrong: they would have needed to install all the libraries and frameworks that Apple hadn’t implemented for whatever new OS vesion that was.

@TimStreater, Not sure if you realized that this was a topic from 2018. But since you took the time to reply, I will add where my comment came from. It wasn’t really a question, but more of a rhetorical. The concept from an OS creation is probably true, an OS that only supports one or the other is by definition less bulky than one that supports both; but that seems a very narrow-minded view and myopic (of course something that is double the size will always be bigger than half of it, not sure why it is even necessary to make that an argument). But the concept from an application point of view could not be further from. Not that I have been looking pretty hard at all applications both in 32-bit and 64-bit, but the few I have paid attention the 64-bit app is always bigger than the 32-bit app. I was just challenging this concept that any 64-bit app will be a smaller binary than its 32-bit counterpart (which is what the person I was responding to was implying). The 64-bit app does have many advantages (more memory access, speed in many cases) but it would be really a very far stretch to try to claim size is one of them.

Not until much later. One of the defects of this forum is that the posting-date info is way over to the right and in faint type, so it’s much less noticeable than it should be. I might propose that threads over 6 months be locked automatically, and request that instead of “reply” for such threads, a “thread continuation” button appear which makes it obvious that an ancient thread is being continued.

In addition to an OS being twice as bulky, there’s twice as much code for the vendor to maintain and test, so it’s unsurprising that they are keen to remove the older one ASAP.