Installing dlls on 64 bit Windows

Several of the spreadsheets available here include routines linking to compiled code written in C#, C++ or Fortran, which require the installation and registration of dll files.  The procedures for doing this are significantly different on machines with 64 bit versions of Windows.  These procedures are not complicated, but they are not well documented, and the naming conventions used are confusing.  The instructions given below are based on my own inexpert investigations; if anyone has any corrections, clarifications, or a better way of doing things, I’d be glad to hear from you.

All the compiled applications available here (so far) are compiled as 32 bit dlls. These should be copied to the Windows\SysWOW64 folder, not Windows\System32, so:

  • 32 bit applications go in SysWOW64
  • 64 bit applications go in System32


The applications written C++ or Fortran are then registered using the version of Regsvr32.exe in the SysWOW64 folder.

Applications written in C# use the COM (Component Object Model) and the .Net framework, and are installed using the Regasm application, as described here. In this case use the version of regasm found in the latest folder found under c:\Windows\Microsoft.NET\Framework\, not c:\Windows\Microsoft.NET\Framework64\.

Following these instructions the applications should successfully install on machines with 64 bit Windows, and be available to either 32 bit or 64 bit versions of Office.

For a good clear description of the background to these things see: (link provided by Dennis Wallentin).

This entry was posted in Computing - general, Excel, Link to dll, VBA and tagged , , , . Bookmark the permalink.

10 Responses to Installing dlls on 64 bit Windows

  1. Georg says:

    Hi Doug, it is impossible to call a 32bit dll from within 64bit-XL/VBA directly:
    If you have no access to the source code, the only way is to write a COM wrapper around the 32bit DLL:
    Otherwise, it is much simpler to recompile the code using a 64bit compiler. MS express editions are delivered without the 64bit libraries, but these can be added for free:
    I found this post very helpful:
    Unfortunately, on all PCs I know that were modified according to these instructions, the .Net 4.x framework is now spoiled, so that some updates do not work porperly… it is APITA…
    All the best


    • dougaj4 says:

      Hi Georg,
      Thanks for the comments and links.
      I will compile 64 bit versions of my dlls eventually, but in the mean time I do have some of the 32 bit versions working with 64 bit Excel without modification. I’ll have a closer look and post more details tomorrow (late here now).

      p.s. Glad to see the Internet is still woking in Europe!


  2. kalx says:

    Yep, SysWOW64 for 32-bit dll’s, and System32 for 64-bit. Another thing is the extern “C” name mangling. For 32-bit it is “_function@n” whereas for 64-bit it would be simply “function”.


  3. dougaj4 says:

    Thanks kalx and Dennis. I have copied the samlogic link to the main post – an excellent straightforward description of how it is, and why it’s set up that way.


  4. Pingback: Daily Download 5: Frame Analysis | Newton Excel Bach, not (just) an Excel Blog

  5. maurizio nardò says:

    Partially related to this subject, there is one important thing to note about dll’s in the 64 subsystem:


    The meaning of this is that ANY 64 bit open source dll that is available online can be DIRECTLY linked to Excel 64bit: no more pain if it was compiled “stdcall” or “cdecl” (cdecl is not directly accessable from vba).

    I’ll take as an example OPENBLAS. This is a very fast BLAS implementation, but it includes also LAPACK (some routines are optimized for openblas, but all of them should benefit from the implementation of the blas 3 level procedures, e.g. matrix multiplication). In vba you can link the dot procedure directly with

    Declare PtrSafe Function ddot Lib “libopenblas” (n As Long, ByVal x As LongPtr, incx As Long, ByVal y As LongPtr, incy As Long) As Double

    As usual, libopenblas.dll must be in an accessable directory (or, which I prefer, in auto_open point to the directory of the excel file and put the dll there. In the same directory put three files which come from the on sourceforge, which are required by the openblas runtime).
    Now, given an array of doubles x(), the dot product x .* x is:

    debug.print (ubound(x), VarPTr(x(1)), 1, VarPTr(x(1)), 1)

    Other examples could be CUBLAS and CUSPARSE, in case GPU computing is of interest.

    Conclusion: I just switched from Excel 32 to Excel 64 bit, and I think it is time for this move.


    • Mikhail Kovalev says:

      “auto_open point to the directory of the excel file and put the dll there”



      • maurizio nardò says:

        I usually add to the auto_open few lines like

        with ThisWorkbook
        chdrive .Path
        chDir .Path
        end with

        This makes the current directory the first one to be searched for dll’s; so you can put all required dll’s in the same workbook’ folder, and they will be found.
        Or, if preferred, make a folder like “Libs” and point to it with the same approach


  6. Pingback: Installing C# dll files, reminder | Newton Excel Bach, not (just) an Excel Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.