xlsgen > overview > 64-bit build

In the install folder is a x64 sub-folder which contains native 64-bit versions of core xlsgen components.

These are produced by a 64-bit compiler and are therefore suited for 64-bit development and deployment.

These are necessary on a 64-bit operating system running a 64-bit application, in the case the xlsgen licensee prefers not to use the isolated server. An example of such 64-bit operating system and 64-bit application is Microsoft's IIS web server (ASP or ASP.NET hosted most likely).

The x64 folder contains the following files :

• xlsgen.dll, (core)
• xlsgen_jproxy.dll, (java proxy to be used in conjunction with 64-bit java.exe from Sun)
• Sparklines.ocx, (vu-meter, sparklines, Google charts)

How to use the files? Simply replace the corresponding files in the main install folder. The license file needs no change.

Is a COM registration needed? No since the files are simply replaced, the old COM registration should still be valid. Of course, in doubt, you can always open-up a command line window and type regsvr32 <path>\xlsgen.dll and hit return.

What if I were using the isolated server prior choosing the native 64-bit build? The COM registration is indeed required before being able to load xlsgen.dll in a process. See paragraph above.

Why the native 64-bit build is worth having?

1. Runs direct, not through the WOW64 layer, which improves speed
2. The dll needs not marshall method calls back and forth, unlike our isolated server, which improves speed
3. The dll allows effective use of the 64-bit memory bandwidth, a big difference with the 2GB limit of the 32-bit world
4. More convenient activation (than the isolated server), results in easier deployments as well

Of course the 64-bit build has limits as well, which are the limits of xlsgen dependencies (not xlsgen itself) :

1. Chart rendering unavailable since Microsoft OWC components do not exist for 64-bit
2. ODBC data source querying unavailable since there is no 64-bit version of this either