I am trying to convert a fairly straight-forward BPL package to XE7 (originally in XE2) and create both 32-bit and 64-bit version (original only 32-bit).  32-bit version compiles fine and works the same way as it did in XE2.  64-bit package also compiles fine (after some changes to how exported global vars are declared) but it crashes in attempting to access Application global variable (e.g. calling Application->MessageBox() or accessing Application->Title from the package results in $C00...05 access viol
ation - while it works fine when the package and the test application are compiled as a 32-bit target).

Has the Application global been deprecated for 64-bit VCL (compiler is not complaining about it and it still works fine even in 64-bit when accessed from the application itself - just not from the package)?  Is there any initialization that need to be explicitly done for VCL to initialize globals in the 64-bit target?

I also created an even simpler package that only has one single export:
{code}
Header file:
//---------------------------------------------------------------------------
#ifndef PackageUnit1H
#define PackageUnit1H
//---------------------------------------------------------------------------
int PACKAGE TestMe();
#endif

//---------------------------------------------------------------------------
#include 
#pragma hdrstop

Source file:

#include "PackageUnit1.h"
//---------------------------------------------------------------------------
#pragma package(smart_init)

int PACKAGE TestMe()
{
	Application->MessageBox(L"Test Me", L"From Package", MB_OK);
}
{code}

Along with an equally simplistic application that calls TestMe() in response to a button click and it also works fine when compiled 32-bit and crashes the same way ($C00...05 access violation) when compiled to a 64-bit target.

So... Anyone knows if there are any extra initialization steps that need to be taken for 64-bit VCL packages?

Thanks...

Marko

Edited by: Marko Majic on Dec 23, 2014 11:55 AM

> {quote:title=Remy Lebeau (TeamB) wrote:}{quote}
> Marko wrote:
> 
> > Has the Application global been deprecated for 64-bit VCL
> 
> No, of course not.
> 
> Do you have Runtime Packages enabled in both the BPL and EXE?  If not, then 
> they will not be sharing a common Application object.
> 
> --
> Remy Lebeau (TeamB)

I got the same problem.

1. Created a new  64bit Package with just one edit control (.bpi + .bpl)
2. Accessed the "Application" pointer in the constructor of the new control (e.g. HWND hWnd = Application->Handle;)
3. Placed this control in a new VCL application (Runtime packages)
4. The application crashes as soon as the "Application" pointer is used.

Peter

Marko wrote:

> This does not seem to work quite the same way with a 64-bit compiler -
> the main difference being that the 64-bit code does NOT export the
> global variable.  I tried changing the declaration and definition in a
> few ways without success.

Does this apply to your situation?

Differences between Win32 and Win64 packages
http://docwiki.embarcadero.com/RADStudio/XE7/en/C%2B%2BBuilder_64-bit_Windows_Differences#Differences_between_Win32_and_Win64_packages

--
Remy Lebeau (TeamB)

This may (or may not) be partly related to the problem with the Application global variable but can anyone tell me what is the proper way to export your global variables from your package with a 64-bit compiler?

With many of my low-level 32-bit packages, I have a class defined in the header file like so:

{code}
//---------------------------------------------------------------------------
#ifndef tmyunitH
#define tmyunitH
//---------------------------------------------------------------------------
#include 
#include 
#include 
using namespace std;

class PACKAGE TMyClass
{
public:
	TMyClass();
....
};

extern PACKAGE TMyClass my_var;

#endif
{code}

With the corresponding implementations and definitions in the source file:
{code}
//---------------------------------------------------------------------------
#include 
#pragma hdrstop
//---------------------------------------------------------------------------
#pragma package(smart_init)
#include 
#include 
#include 
#include 

TMyClass my_var;

TMyClass::TMyClass()
{
}
{code}

This would create the class code in the package as well as the exported global variable of the type.  Using this package in the EXE or from other packages worked fine.  If either the EXE or another package referred to my_var - it was all referencing the same global variable created by the package.

This does not seem to work quite the same way with a 64-bit compiler - the main difference being that the 64-bit code does NOT export the global variable.  I tried changing the declaration and definition in a few ways without success.

Is there any documentation or guidelines as to how this is supposed to work with the 64-bit compiler?

Marko

> {quote:title=Remy Lebeau (TeamB) wrote:}{quote}
> Do you have Runtime Packages enabled in both the BPL and EXE?  If not, then 
> they will not be sharing a common Application object.

Yes, of course...  Link with runtime packages has been enabled for the EXE. As for the BPL - I wasn't aware that you can even link it without runtime packages?

Marko

Marko wrote:

> Has the Application global been deprecated for 64-bit VCL

No, of course not.

Do you have Runtime Packages enabled in both the BPL and EXE?  If not, then 
they will not be sharing a common Application object.

--
Remy Lebeau (TeamB)