AW: 64 bit desktop apps

[Paul Dupuis]

On 6/8/2017 3:54 AM, Mark Waddingham via use-livecode wrote:
> As a general request, can people let us know if they are relying on
> externals on Mac which are currently 32-bit only?

Forgive the dumb question Mark, but how does someone tell whether
externals are 32 bit or 64 bit?


In my first LC 8.1.3 64 bit build, I accidentally included
revVideoGrabber in my inclusions (we don;t use it, it had been checked
by accident). I discovered my OSX standalone would not even launch with
NO error messages or crash report. Only by opening the App bundle to
look around and double-clicking on the actual executable did I get a OSX
Terminal listing that showed error with LiveCode trying to start
revVideoGrabber and failing. Removing that from the Inclusion list
allowed creation of a Standalone that launched.

Then we noticed that the default text font or text flow is different in
8.1.3 from 6.7.11 and test in our splash screen and a licensing dialog
is cut off under 8.1.3 vs 6.7.11. These are the details that add up to a
length migration time for large applications.

As another example, in testing our LC6.7.11 app under LC8.1.4, I
discovered that the 'standaloneSaved pDestinationFolder' message returns:

 'C:/Users/Paul/Desktop/TestProject' under LC6.7.11. Note that the name
of the Standalone folder 'HyperRESEARCH' is not included and there is no
ending slash.

but

'C:/Users/Paul/Desktop/TestProject/HyperRESEARCH/" under LC8.1.3, Note
that the name of the Standalone folder 'HyperRESEARCH' is included and
there is a trailing slash

A small difference, undoubtedly covered in release notes, but another
cause of code that needed to be changed to accommodate the differences
between 2 versions of the engine.


On this topic, I applaud LiveCode for having 64 bit support. I curse
Apple for removing 32 bit support. I still have apps under LC6.7.11 and
LC 5.5.5 that now need to migrate to LC8.1.4+ in the next 6 months and I
am really annoyed at Apple for doing this. To be fair, we've known we've
need to catch up to current LiveCode releases for a good long while, but
between business pressures to add new features and fix customer visible
bugs, cleaning up code that needs fixing just due to engine changes
unfortunately always falls to last place. Now, fortunately or
unfortunately due to Apple's heavy handedness, it now moves to first
place for us.