a build dll-file: does not work on a different W7-computer

Dear Forum'ers,

My 'PLATO IDE' build dll-file works fine at the same W7-computer on which the free personal edition of Silverfrost FTN95 is installed: Calling my subroutine and function in the build dll-file from an Excel-VBA routine gives the correct results. However, this very same build dll-file can not be found by both the Excel-VBA routine as well as the 'regsvr32.exe' using a different W7-computer with no installed free personal edition of Silverfrost FTN95.

Is this 'meant to be' because of the free personal edition? Or is there another technical reason which I am not aware of? I would like to solve this issue before I decide to purchase the commercial edition of Silverfrost FTN95.

You will need to copy salflibc.dll to the new machine together with your executable.

Dear PaulLaidler,

thank you for your reply. I recognize your reply as the correct answer for the case of a buil [u:42f4b51e16]exe[/u:42f4b51e16]-file. A build exe-file works only on a different computer if the salflibc.dll file is also present on the other computer.

The case I am dealing with, is about a build [u:42f4b51e16]dll[/u:42f4b51e16]-file. The presence of the salflibc.dll does not solve the problem I've described. Using regsvr32.exe for trying to register the build dll-file only yields error. I am very much interested in solving this technical problem, because all the possible answers given by relevant forums on the internet I've found don't work.

If you have built your dll using FTN95 then you will need to copy salflibc.dll together with your dll.

I've managed to get my DLL going: To copy salflibc.dll to the new machine is the solution to my problem if salflibc.dll is copied to the windows-system-directory 'C:\Windows\SysWOW64\'. If salflibc.dll is copied to the same directory as my own created dll, then it only works if I run my vba-routine as an 'administrator'.