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
OK?
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: http://www.samlogic.net/articles/32-64-bit-windows-folder-x86-syswow64.htm (link provided by Dennis Wallentin).
Newton Excel Bach, not (just) an Excel Blog 
Hi Doug, it is impossible to call a 32bit dll from within 64bit-XL/VBA directly:
http://support.microsoft.com/kb/282423
If you have no access to the source code, the only way is to write a COM wrapper around the 32bit DLL:
http://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/
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:
http://msdn.microsoft.com/en-us/windowsserver/bb980924.aspx
I found this post very helpful:
http://stackoverflow.com/questions/1865069/how-to-compile-a-64-bit-application-using-visual-c-2010-express
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
Georg
LikeLike
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!
LikeLike
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”.
LikeLike
Doug,
The following article is a nice write up:
http://www.samlogic.net/articles/32-64-bit-windows-folder-x86-syswow64.htm
LikeLike
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.
LikeLike
Pingback: Daily Download 5: Frame Analysis | Newton Excel Bach, not (just) an Excel Blog
Partially related to this subject, there is one important thing to note about dll’s in the 64 subsystem:
THERE IS ONLY ONE CALLING CONVENTION
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 ming64.zip 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.
LikeLike
“auto_open point to the directory of the excel file and put the dll there”
?
explain
LikeLike
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
LikeLike
Pingback: Installing C# dll files, reminder | Newton Excel Bach, not (just) an Excel Blog