An open community 
of Macintosh users,
for Macintosh users.

FineTunedMac Dashboard widget now available! Download Here

Topic Options
#46066 - 08/23/17 06:36 PM 32 bit v 64 bit apps
artie505 Online


Registered: 08/04/09
I don't know if there's a definitive answer to this question, but how big a deal is it to recompile (Correct word?) a 32 bit app as a 64 bit app?

I'd like to ask ("beg" may be a better word) a few developers to update their apps, but before I do, I'd like to know what I"m asking them to get into.

Thanks.
_________________________
The new Great Equalizer is the SEND button.

In Memory Of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire

Top
#46068 - 08/24/17 01:50 AM Re: 32 bit v 64 bit apps [Re: artie505]
Urquhart Offline


Registered: 08/10/17
Loc: Netherlands
As I understand it, “it depends”. Old code may have things that assume 32 bit without being explicit about it (or checks if things behave within boundaries), because 64 bit was never a real option when the code was written. Some not-so-strict programming that would mostly work for its purpose in 32 bit, may fail in 64 bit. These are the things that may break without clear cause, and those errors may be hard to track down.

Some programs rely on 3rd party code (internal routines or external plugins) that is 32 bit. Maybe that 3rd party code is not (freely) available to also be converted to 64 bit. Such things could mean the end for certain features.

Converting Your App to a 64-Bit Binary at developer.apple.com

Top
#46069 - 08/24/17 02:07 AM Re: 32 bit v 64 bit apps [Re: Urquhart]
artie505 Online


Registered: 08/04/09
Originally Posted By: Urquhart
Such things could mean the end for certain features.

Such as most of my favorite, most useful, and, unfortunately, ooold apps. frown

Thanks for the info, though. smile
_________________________
The new Great Equalizer is the SEND button.

In Memory Of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire

Top
#46072 - 08/24/17 06:15 AM Re: 32 bit v 64 bit apps [Re: artie505]
pbGuy Offline


Registered: 08/04/09
Loc: Portland, Oregon
Originally Posted By: artie505
... I'd like to know what I"m asking them to get into. ...


Here's an interesting post by TidBITS shedding light about their iOS app: Updating to 64 bit
_________________________
MBP15 i7 (2017) - 1TB PCIe-SSD - 10.15.5, iPhone X & iPadPro 11 WiFi, Watch4

Top
#46073 - 08/24/17 06:21 AM Re: 32 bit v 64 bit apps [Re: pbGuy]
artie505 Online


Registered: 08/04/09
Originally Posted By: pbGuy
Originally Posted By: artie505
... I'd like to know what I"m asking them to get into. ...


Here's an interesting post by TidBITS shedding light about their iOS app: Updating to 64 bit

Not the least bit reassuring, but thanks.
_________________________
The new Great Equalizer is the SEND button.

In Memory Of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire

Top
#46111 - 08/31/17 08:43 AM Re: 32 bit v 64 bit apps [Re: artie505]
Virtual1 Offline


Registered: 08/04/09
Loc: Iowa
Originally Posted By: artie505
I don't know if there's a definitive answer to this question, but how big a deal is it to recompile (Correct word?) a 32 bit app as a 64 bit app?

"In theory" it should be very easy to do. But the people writing the system often take advantage of this "forced code review" to make changes to their API calls. If you try to just do a "find-and-replace" to update an old function call to a new one, you often will find it's not compatible because parameters have changed. Creating a sort of example, lets say a program needs to draw a window so it calls DrawWindow32(x,y,w,h). But now that the new OS has "themes", it needs to know the theme the window is drawn under, so the new call is DrawWindow64(x,y,w,h,t). Trying to omit T will cause a compile error that you will have to fix somehow, either by passing in the current theme or a default value etc. It forces you to review your code.

If enough of these change formats, it can be quite a headache to have to go review dozens, or hundreds, or even thousands of these "breaks" and fix them all. Return values also will change type, from 32 to 64 bit, as will data types in blocks of data. Numbers could be too big for your current 32 bit code to handle, and you will have to adjust them so you don't overflow. The above call may return the WindowID of the new window it created, and if it's a 64 bit number now you will need to be able to store it, so everything in your code that referenced the WindowID will need to be adjusted. And this can get out of hand very fast. A few dozen function calls being updated can easily lead to thousands of lines of code that need to be changed to handle the higher precision. Also, each and every one of those changes you have to make could introduce a bug. So after making changes to 2,000 lines of code scattered far and wide within your app, just how many bugs do you think you've managed to accidentally create?

This is NOT something developers are looking forward to. It has to be done, but it's not going to be pleasant for a lot of developers and even some users.


Tangent: I leverage this "side effect" to my advantage when coding. If I change the behavior of a function in a way that doesn't cause the call to change, (and thus it will still compile without error, but not RUN correctly) I simply rename the function. Add _1 or B or something to the end for example. NOW the whole world blows up, as every call to that function breaks, requiring me to go fix the name in each place I call it. While I'm there, I adjust the code (if necessary) to accommodate the change to the function. As an example, maybe it was handing back a number indicating how many items are in a list, a list that USED to have a max of 10 items, but I've upgraded it and now the max is 20. 10 and 20 are both easily handed back using an INT so the compiler is happy, but maybe some of my code can't handle more than 10 (or 15?) items at a time and needs to be adjusted. So the compiler drags me by the collar, from one call to the next, so I can make sure I review each and every one of them without missing any. This has become a very useful and reliable coding practice for me. Sometimes I will then find another function that needs to be changed as a result, and so that too will get renamed. Sometimes this has a "domino effect" in my program, leading to a dozen or more function changes. It's SOOO easy to miss something that needs changing, especially when there's so many places each one of them needs to be reviewed. This insures I hit every one, no matter how crazy things get.

_________________________
I work for the Department of Redundancy Department

Top
#46118 - 08/31/17 06:29 PM Re: 32 bit v 64 bit apps [Re: Virtual1]
artie505 Online


Registered: 08/04/09
Thanks for that clear explanation of what may (will?) be involved in converting an app from 32 bit to 64 bit.

(I always knew there was more to being a developer than I've got any inclination to learn, but it's even worse than I thought! crazy )
_________________________
The new Great Equalizer is the SEND button.

In Memory Of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire

Top
#46124 - 09/01/17 11:54 AM Re: 32 bit v 64 bit apps [Re: artie505]
Virtual1 Offline


Registered: 08/04/09
Loc: Iowa
Originally Posted By: artie505
Thanks for that clear explanation of what may (will?) be involved in converting an app from 32 bit to 64 bit.

Believe it or not that's far from the only issue. Think "preference files" (of the binary sort). Your 64 bit number won't fit where the 32 was, (8 bytes vs 4) so now you have to create a new version of preference file too. Not only does that force the reading and writing of the file to change, but they must be savvy to both old and new, AND be able to tell the difference. AND you may still have to change some files. There are several other problems commonly ran into as well. What stinks the most is you can't just change a little at a time and test it. You have to spend all day (week? month?) changing all the stuff that needs changing, and then run it, and hope it doesn't completely barf. And if there's a new bug, normally you'd just go look at the bit of code you just changed. But you just changed thousands of lines of code, in many dozens of places, so you've just lost a valuable response shortcut, and basically have to start your bug hunt from scratch for each and every new bug you find.
_________________________
I work for the Department of Redundancy Department

Top
#46128 - 09/01/17 02:01 PM Re: 32 bit v 64 bit apps [Re: Virtual1]
artie505 Online


Registered: 08/04/09
Originally Posted By: Virtual1
Originally Posted By: artie505
Thanks for that clear explanation of what may (will?) be involved in converting an app from 32 bit to 64 bit.

Believe it or not that's far from the only issue. Think "preference files" (of the binary sort). Your 64 bit number won't fit where the 32 was, (8 bytes vs 4) so now you have to create a new version of preference file too. Not only does that force the reading and writing of the file to change, but they must be savvy to both old and new, AND be able to tell the difference. AND you may still have to change some files. There are several other problems commonly ran into as well. What stinks the most is you can't just change a little at a time and test it. You have to spend all day (week? month?) changing all the stuff that needs changing, and then run it, and hope it doesn't completely barf. And if there's a new bug, normally you'd just go look at the bit of code you just changed. But you just changed thousands of lines of code, in many dozens of places, so you've just lost a valuable response shortcut, and basically have to start your bug hunt from scratch for each and every new bug you find.

Ouch!
_________________________
The new Great Equalizer is the SEND button.

In Memory Of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire

Top
#46181 - 09/05/17 06:38 AM Re: 32 bit v 64 bit apps [Re: artie505]
Virtual1 Offline


Registered: 08/04/09
Loc: Iowa
Originally Posted By: artie505
Ouch!

Yeah, that's why I like my method, it makes it essentially impossible to not look at code that may need to be adjusted. There's a hard rule in programming, "Make sure the computers are doing the jobs the computers are good at, and the people are doing the jobs the people are good at." Identifying all the bits of code that need to be reviewed definitely falls into the former.
_________________________
I work for the Department of Redundancy Department

Top

Moderator:  alternaut, dianne, dkmarsh