Should I bother with 32 bit desktop apps these days ?

I’m working on an a desktop program (mostly open source) which will take some time to complete, probably another six ( or way more ) months to complete as it’s mostly a spare time thing.

I see no reason to complicate matters any longer and believe I should just go for 64 bit all the way and forget about 32 bit completely.

I do need to create and build / declare in Xojo some libraries in C for use in the project so sticking with 64 bit across Mac/Win/Linux platforms will definitely simplify things.

Anyone got any thoughts on this ? I think I’ve made my decision anyway, would just like to hear what others are doing…

understand that Xojo’s 64 bit support is still BETA

http://developer.xojo.com/64-bit-guidelines

we expect that it will move out of that status in the near future BUT in the mean time it is still regarded as beta
you may encounter issues in a 64 bit app that do not exist in 32 bit apps

JUST FYI

It really depends on your target audience.

My company makes an app that is used in schools in France. Recently the head teacher was complaining that a very important feature wasn’t working. We were using a 64bit external library and his computer was a 32bit Windows 7.

The Mac App Store will be 64-bit only as of June 2018, and whatever follows High Sierra may not run 32-bit anymore (or if so, with “compromises”).

Mac Observer

I understand the 64 bit beta issue but considering this will be in development until much later in the year and even then it will just be an early ‘test’ release I don’t think it’s going to be too much of an issue for me.

I would consider this a project which will emerge from test / experimental release in 2018.

Sure
I just wanted to hilight the state of 64 bit builds

Go as far as you can with 64-Bit, 32-Bit has been unofficially deprecated by Apple for a couple of years and 10.13 is the last OS release to “support” 32-Bit applications. So you might find in 14 months your 32-bit application no longer works on those who update their macOS.

32-Bit has been compromised since Yosemite, with at least two frameworks that got broken and never fixed (that affected the applications we develop). So I dread to think what they mean by with compromises…[quote=334340:@Neil McAliece]I do need to create and build / declare in Xojo some libraries in C for use in the project so sticking with 64 bit across Mac/Win/Linux platforms will definitely simplify things.[/quote]

[quote=334345:@Jérémie Leroy]It really depends on your target audience.

My company makes an app that is used in schools in France. Recently the head teacher was complaining that a very important feature wasn’t working. We were using a 64bit external library and his computer was a 32bit Windows 7.[/quote]
Yeah for sure, I would certainly do some market research. 64-Bit should be your goal; but if 80% of your customers are running 32-Bit OS versions.

I expect that on macOS we can move to 64 bit only readily since macOS has been fully 64 bit since about 10.6/10.7
Linux will probably be the same

Windows is likely to be the lone hold out where building 32 and 64 bit apps is still a necessity

Xojo will move to 64bit eventually.
Unless we have a specific customer, we’ll be shipping 32 and 64 bit builds for a long time.
Heck, I still sell to people who have OSX 10.4 and the odd PPC machine, (but I send ‘old versions’ for those)

p.s. Does flood fill work in 64bit yet? I know its going to be a very low priority bug but I cant ship 64bit until its fixed…

I’m not sure exactly when OSX received the ability to run 64bit apps, but it’s got to be at least 10.6 or maybe even 10.5? we can’t even compile for those with the most recent Xojo versions anyway. I’ve been releasing apps with the “beta” 64 bit support for some time and have found a few bugs over that time. There are a couple that still plague me that I think are rather serious that you need to be aware of there are probably more in feedback and you should search around in there, but these ones are mine:

assigning a double to a 32 bit integer container can result in incorrect numbers, even if the double contained an integer that would have fit into the integer you’re assigning it to. If the last bit of the 32bit integer is used the number returned is goofy. The work around is to assign the double to a 64bit integer and then to a 32bit integer if you need a 32bit integer for some struct or binary data somewhere. Many of the internal framework calls return doubles so you can’t get away from them even if you’re only working with integers: <https://xojo.com/issue/45954>

The one that really bugs me though is that exception objects are never released from memory on 64bit. Back in the day I did a lot of work updating some code to throw proper exceptions and properly handle them and it was quite nice way to send up error and even other information. Unfortunately these leak memory when compiled for 64bit. Having a few build up from actual errors is probably not a big deal, but you should not use exception handling and try/catch as a regular programming technique because you’ll eventually start swapping to disk and cause trouble for your own app and the OS. Yes, that takes a while and theoretically they should run forever and just keep writing blocks to disk until you run out of disk space because 64bit can address so much memory, but in reality it does start to slog and hang after a while if you’re building these up in the normal course of your work. <https://xojo.com/issue/45954>

OH, and you can’t use any of the .refresh methods to force a control to redraw inline. On 64bit nothing happens it works like invalidate. There is a long thread around here somewhere where I defend the evidently indefensible of using that for updating status displays while running large chunks of inline code. Yes, it could be converted to a thread or to work in chunks in a timer, but there are still valid reasons why that is not an option in my particular case, too many sockets that would need to have flags added for blocking their reception until the process is done, it’s non-trivial and it used to work :frowning:

The main thing I use 32bit for now days is when I’m going to be debugging or tweaking things and I need to debug run a hundred times in a day, it’s still faster by enough than the 64bit compile that it really does add up to my getting more work done under those situations. Even taking into account that I can’t debug for 64bit issues in that circumstance.

64bit is no fun at the moment because of this lovely bug here: <https://xojo.com/issue/48281> happens every couple of compiles for me. Not reproducible for Xojo people at the moment.

As long as “if then else” is screwed up I’d not even consider 64bit beta at all. I would think that ALL applications are affected.

That would indeed be frustrating if the IDE is packing up on you regularly. I haven’t had that specific problem have you sent your project to the Xojo folks and let them try to duplicate it? They are good about keeping your Intellectual Property private under such circumstances.

[quote=334450:@Beatrix Willius]64bit is no fun at the moment because of this lovely bug here: <https://xojo.com/issue/48281> happens every couple of compiles for me. Not reproducible for Xojo people at the moment.
[/quote]
This report is usually an out of memory since the IDE is still a 32 bit app

[quote=334450:@Beatrix Willius]
As long as “if then else” is screwed up I’d not even consider 64bit beta at all. I would think that ALL applications are affected.[/quote]
Pardon ???
JUST FYI Feedback ships as a 64 bit app and I can assure you it makes heavy use of “if then else”

This comment is really just spreading fear uncertainty and doubt Beatrix

EDIT : Mostly because its based on an incomplete analysis of the actual problem

@Norman: please show me an application that isn’t affected by <https://xojo.com/issue/47822> . Still at “verified”.

Apparently Feedback on OS X as it ONLY ships as a 64 bit version

Then try that case using a DOUBLE instead of a currency
That it works as expected for a double say this is a problem of comapring currency values under 64 bit
NOT IF THEN ELSE doesn’t work

Ah, as per norman’s last update to the case, it’s not if/then/elseif thats broken, it’s a comparison with the currency data type. Which makes more sense since I use rather a lot of comparisons in my own 64 bit apps without difficulty.

Ah, I was asking myself. I built all my applications in 64-bit and they run well. I just have to make my own SPLIT function as it cause trouble under 64-bit.

Before build them all in 64-bit, I looked for information about 64-bit was still beta or not and, as I didn’t find anything, I supposed it was final realize.
How can I know if it’s beta or not please (for future version) ? I searched on Xojo release-notes.
Thank you.

I posted the link that tells you this previously

[quote=334344:@Norman Palardy]understand that Xojo’s 64 bit support is still BETA
http://developer.xojo.com/64-bit-guidelines
[/quote]

Thank you Norman, I saw your link but I didn’t click it.

I think that it should be written in the realize note that 64-bit is beta.
On other way, it’s not a big problem as many people downloaded the last version of my applications (in 64-bit) and I did’t receive any feedback about problem. (I received some but it was my fault, not 64-bit trouble).