Archived Forum Post

Index of archived forum posts


Why separate 32- and 64-bit Chilkat libraries for .NET?

Feb 22 '17 at 08:20

I was curious as to why the Chilkat .NET libraries are released in separate 32- and 64-bit modules. Microsoft .NET allows applications to be compiled in the following modes - x86, x64, IA64, Any CPU and, with Visual Studio 2012 and Modern UI, ARM.

When I began marketing my software, I spoke with the good folks at the Association of Software Professionals, and one of the items they pointed out was that I was being too technical and made things burdensome for the end user. There was a lot of emphasis on simplicity.

I always compile my software in "any CPU" mode. This provides the luxury of knowing the software will work, regardless of the machine it is run on.

Using the Chilkat libraries forces me to change that mode of thinking, and compile in either 32- or 64-bit (x86/x64) modes, and also forces me to release the software in separate 32- and 64-bit downloads. This adds to the complexity for an end user who has no idea what 32- or 64-bits means. I try to help the user by telling them on the webpage that we detected 32- or 64-bit.

But, in a perfect world, I would like to be able to make just one download, and know it will install and run on every user's computer, regardless of 32- or 64-bit Windows.

Matthew Sawyer Owner, Dojo North Software, LLC


The Chilkat libs are implemented in C++ and compile to native code. The fact that it's written in C++ allows for the exact same code base to be used across many different operating systems, and with different thin wrappings, exposed to many different programming languages. One advantage is that you have a uniform API across all these disparate languages, platforms, systems, etc.

The Chilkat .NET assembly is therefore a mixed-mode assembly. This means the outer-layer is managed but the inner core is unmanaged. It is for this reason that both 32-bit and 64-bit builds are provided.


Thank you chilkat and blaze4218. These are all good answers, and chilkat's explanation is certainly an excellent reason why there are two different modules.

From my perspective, it's not hard to make two installers. I was just hoping to take the minimalist approach in terms of trying to make it as easy as possible on the average, nontechnical end user.

I use what I like to call the "mother test." I call up my mom, who can use an iPhone and is pretty good at email, but otherwise always calls me with technical questions. The test is this -- make a download available and ask her to download and install it. If she needs to ask my help, even once, I then regard what I have available as too complicated for the average home user and thus likely to turn folks off. In my case, she called and asked, "What's 64-bit?" This was despite the fact the website text said "we detected you are running 64-bit Windows and recommend the 64-bit download."

That goes to blaze4218's option #3 -- provide a bootstrapper installer that detects the system and behaves accordingly.

I guess I'm a fan of plain MSI installations, however, because these are very attractive to businesses--especially system administrators, because they're so easy to script and deploy via PowerShell or tools like System Center.

It seems I'm in the "he who tries to please everybody pleases nobody" conundrum.

Matthew Sawyer
Owner, Dojo North Software, LLC


I think the idea of creating a single installer that determines the system type (32-Bit or 64-Bit) and installs the appropriate libraries is the best choice. The only questions is if MSI packages give you this flexibility or not.

If not, then I think you could make a big "Download" button on your webpage that is linked to the single installer created by another tool that allows you to dynamically install files based on system parameters (such as Inno Setup). Then, underneath that button you could include a smaller link for tech-savvy users and administrators (such as "Looking for an MSI?" or "Other Builds") that would take them to a page where they could choose the appropriate 32-bit or 64-bit download. Anyone looking for an MSI should be able to understand the differences between 32-bit and 64-bit, but most users will just see the big download button and immediately click it.


How 'bout you branch inside your "wrapper", so that we don't have to? You have 2 options:

  1. Embed both 32-bit and 64-bit versions of your native code into a single assembly, then on runtime execute the one that matches the application runtime mode (this is very easy to check; e.g. System.IntPtr.Size == 8 means it's running as 64). This simplifies your ship process, too! And you will never have to answer a similar question again.

  2. Take your native code out of .NET assembly. Place it in two different C++ assemblies that have different names (both internal and external). Then, have a single .NET assembly with your "wrapping" code load one or the other one of those. This is almost the same thing as #1. Maybe this would be even better for you, as you won't have to maintain multiple versions of your native code for multiple development platforms, and I'm pretty sure that you do.