View unanswered posts | View active topics



Reply to topic  [ 2 posts ] 
AIR 64 bit build package 
Author Message
Member

Joined: Thu May 03, 2012 11:36 am
Posts: 21
Reply with quote
I have a few questions regarding the workflow for building /packaging a 64bit AIR exe.

1. Does AIR have a 64bit runtime (i can't find any download of that?) I have AIR 29.0.0.112 runtime installed but don't know if its 64 bit or 32 bit.
2. Is it OK to only package an already existing SWF built to target an older version of AIR runtime (AIR 19) with ADT from the AIR29 SDK and that would make the final exe OR
Is it necessary to first compile the source to an SWF with swf-version=40 and then only use that compiled SWF to package as 64bit AIR exe?


Thu Aug 02, 2018 7:14 am
Profile
Member

Joined: Fri Jan 21, 2011 5:17 am
Posts: 78
Reply with quote
I am going to try to assist @ASKer by doing the unseemly thing of [temporarily] usurping his topic.

What I intend is to provide a convenient place for the developers -- and any community members who will -- to provide some concise statements concerning the many questions about the over-all topic of 64-bit versus 32-bit use of FD. I think anyone doing a conscientious search either via google, or just within this board, will find that many questions have been asked over the years, but they have mostly been asked in relation to some specific problem a user had been having, most often because some new release of FD, or of one of the toolkits or frameworks upon which FD depends, or one of the SDKs, we are using to develop our application, had caused the appearance of some new diagnostic error message when attempting to build/test.

What there has never been, to the best of my knowledge, is a crisp statement of purpose and/or recommended usage of the 64-bit executable versus the 32-bit executable. So I would like to pose it here: Can we list the motivations/needs/features/benefits of a 64-bit version of FD? [And I would ask that we approach this purely in terms of Actionscript/AIR/Flex applications, not Haxe. That is not an anti-Haxe slur, that is because, as I review the matter, it appears to me that most of the motivations/needs/features/benefits of the 64-bit version actually relate pretty specifically to requests that arose from that part of our joint community, and that it was simply a natural optimization of effort that caused the refactoring which eventually resulted in the Haxe-specific version of FD, using a common source code base. So, if we can try to identify non-Haxe use cases and properly document them, I think everyone wins.]

To get this kicked off, I will do another unthinkable thing -- expose my own ignorance of these matters. It seems if I can make some assertion from a review of the history of postings, coupled with my own attempts to make things work properly when new diagnostic messages have popped up, where my assertion is just slightly erroneous or completely ignorant, my posting will provide a good place for someone in the know to correct my error.

A. There is not, never was, never will be support for a 64-bit development/test environment from Adobe. The Adobe toolchain for AIR/Flex development is entirely based on 32-bit java development tools [primarily in the jar files found in the bin and lib directories of the SDK releases].

B. There is now [has been for sometime] a capability to use the AIR Developer Tool [adt] to generate a Windows 64-bit [I will ignore discussing the MacOS world for simplicity] distributable application with a "Captive Runtime" that is 64-bit capable, but the few remaining folks involved in AIR engineering at Adobe, decided NOT to provide any upgrade of adt to permit debug-testing of a 64-bit-destined application either in their own IDE or in ours. The only means for testing an application being deployed/distributed as 64-bit-enhanced, is to go ahead and create the package, deploy it and test it running, not test it inside any IDE.

C. OK, so what, exactly, do we mean when we say that an AIR application is 64-bit capable? We most certainly to not mean that it has been coded/compiled/tested in anything like the same manner that an application built using Visual Studio with C, C++ or C# as the language, will have been built. Now I am admittedly on really weak grounds here, but I am going to say that the compiler for those languages and those frameworks and those deployments as .exe files not only have the large address space made available only in a 64-bit world, but the emission of some amd-64 instructions which are only available in that compilation mode.

So, since our toolchain only produces intermediate byte codes, there is no equivalent sense in which we develop for the 64-bit versus the 32-bit world. When, in fact, we use the new <architecture> tag in an AIR application descriptor file, nothing really changes in terms of what the compiler does. [Now I have to really be careful because, as we know, there are two different compilers that may be involved. If you have code that does not need XMLC-awareness, you hopefully use ASC2 [Falcon] and that very well may have some capability to produce differently-optimized byte code sequences, but when we are talking about xmlc, we are strictly working with technology that the Adobe folks stopped supporting/enhancing more than six years ago.]

So, if it is not the compilers [java 64-bit versus old java 32-bit], what does it really mean to have a 64-bit-enhanced AIR application? As far as I know, what we are really gaining is just a 64-bit version of the runtime, and what that version ought to be able to do is better handle memory allocation and garbage collection than the 32-bit version of the runtime which clearly begins to have problems somewhere south the 1.5GB range if your application is handling large amounts of data -- most often of the bitmap variety. The only part of the Adobe toolchain/infrastructure changed by setting <architecture>64</architecture> arises if your build script produces a captive output. If you request 64-bit, you will get a 64-bit runtime handling the byte codes in your swfs; if you request 32-bit, you will get a 32-bit runtime handling the byte codes in your swfs.

D. So, I think that brings us to the fundamental questions. For what reasons, under what circumstances, and for what benefit, should I run the 64-bit version of FD while performing my code/test work? Are there some specific types of AIR/Flex applications which were not compiling properly, not compiling properly or not compiling fast enough using the old-reliable 32-bit version of FD. I suppose that means that were treated as WOW applications when we moved from Windows Xp to Windows 7, 8 and 10. Was running a 32-bit executable IDE on a 64-bit OS some sort of handicap?

I am hopeful that as we get solid answers to these questions, it will make it easier to handle the questions concerning: a.) the best/most appropriate version of the Oracle java jre to grab, b.) the necessary version of the .NET framework to be installed with your upgrade from 3.5 to 4.0, and finally, and most interestingly, the definitive answer to the proper setting of the java.home variable in the jvm.config file for each and every targeted deployment use case.


Fri Sep 21, 2018 2:45 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 2 posts ] 

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.