2

Developing a Firefox addon, using ctypes to load a custom DLL - On my real computer (win 7/64) the DLL loads without a hitch, but inside my test VM using the same OS, the following error occurs:

console.error: bzaddon:
  Message: Error: couldn't open library .\BZAddOnHelper.dll: error 126
  Stack:
    @resource://bzaddon/index.js:25:11
run@resource://gre/modules/commonjs/sdk/addon/runner.js:145:19
startup/</<@resource://gre/modules/commonjs/sdk/addon/runner.js:86:7
Handler.prototype.process@resource://gre/modules/Promise-backend.js:867:23
this.PromiseWalker.walkerLoop@resource://gre/modules/Promise-backend.js:746:7
this.PromiseWalker.scheduleWalkerLoop/<@resource://gre/modules/Promise-backend.j
s:688:37

The code to load the library:

// Get the chrome components
let { Ci, Cu, Cr } = require('chrome');
// Get ctypes
Cu.import("resource://gre/modules/ctypes.jsm");
// External DLL
var lib = ctypes.open(".\\BZAddonHelper.dll");

I even tried with a completely empty DLL, that does NOT depend on msvc*:

screenshot of 'depends' on the target vm

I tried using moving the DLL to the data directory and using self.data.url and using no path at all. I tried using a complete path. the ONLY thing that works is copying my DLL to SysWow64 (The DLL is 32bit, as firefox is 32bit). Again, running this on MY (dev) machine works with ".\dllname" - but not on any other computer... I am at a complete and utter loss... Anyone?

Uriel G
  • 23
  • 6
  • Update: got the same result on a VM running Windows 7/32.... – Uriel G Oct 20 '15 at 09:13
  • Update 2: got the same result copying kernel32.dll from C:\windows\system32 over my own DLL... And I'm quite certain kernel32.dll can be loaded by any process in the system :) – Uriel G Oct 20 '15 at 09:22
  • Please see this article: https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes/Using_js-ctypes/ctypes.open . When you tryied kernel32 you need to double backslash if you use a full path. Or you should just `var lib = ctypes.open('kernel32')`. In your above topic post, for your custom dll, you are using a relative path, you have to use a full path, and it cannot be a chrome path, you have to make a file uri out of it. A file uri is `file://blah/blah/blah.dll` – Noitidart Oct 21 '15 at 04:03
  • @Noitidart I copied kernel32 over my own DLL just to make sure the problem was not with the DLL itself (an unresolved dependency, failure in DllMain, etc.). For the life of me I cannot remember where I saw that using ".\DllName.dll" in ctypes.open() will take it from the addon's directory - but, and it's a big but, on my dev machine it works! on any other computer it doesn't. Anyway... I can always install our helper DLL in to system32, as the addon is just a part of a bigger product... so if all else fails - that's what i'll end up doing... – Uriel G Oct 21 '15 at 07:45
  • You should not have to install to system32, see this working addon that uses custom dll: https://github.com/NoitForks/Firefox_addon_sdk_jsctypes and this one: https://github.com/NoitForks/fx-sapi-test Im certain your mistake is you are not using a string that is using `file://` protocol. If its at `C:\\blah.dll` do `ctypes.open('file://C:/blah.dll')` – Noitidart Oct 21 '15 at 08:07
  • 1
    @Noitidart Thanks! Please re-post as the answer and I'll +1 you :) – Uriel G Oct 27 '15 at 11:51
  • Awesome! I'm glad it worked :) – Noitidart Oct 28 '15 at 08:27

1 Answers1

1

You should not have to install to system32, see this working addon that uses custom dll: github.com/NoitForks/Firefox_addon_sdk_jsctypes and this one: github.com/NoitForks/fx-sapi-test Im certain your mistake is you are not using a string that is using file:// protocol. If its at C:\blah.dll do ctypes.open('file://C:/blah.dll')

Noitidart
  • 35,443
  • 37
  • 154
  • 323
  • 1
    My +1 doesn't show publically until I earn "15 reputation". Man, this feels like a PS4 game ;) – Uriel G Oct 29 '15 at 09:12
  • Haha that's funny, no prob about the +1. – Noitidart Oct 29 '15 at 19:53
  • 1
    After looking at the code from NoitForks (and after adding unpack: true to the package.json), I get the following message - message = Component returned failure code: 0x80004002 (NS_NOINTERFACE) [ns IFileURL.file] - name = NS_NOINTERFACE - result = 2147500034 Here's my code: var dataUrl = self.data.url("BZAddonHelper.dll"); var nuri = Services.io.newURI(dataUrl,null,null); var s = nuri.QueryInterface(Ci.nsIFileURL); var f = s.file(); // <- I tried s.file, s.file(), and also, like in the sample, nuri.QueryInterface(...).file.path var p = f.path; Any ideas?? – Uriel G Nov 01 '15 at 09:34
  • Can you upload your code to a github repo, Ill test it myself – Noitidart Nov 01 '15 at 10:12
  • https://github.com/urielgin/fftest Just placed kernel32.dll from my syswow64 directory in to the addon's data directory, just for tests... – Uriel G Nov 01 '15 at 11:24
  • I have tried every permutation possible to load in a DLL using Firefox ctypes. Each time ctypes.open comes back with error 126 since it cant seem to find the dependency DLLs despite them being in the same folder as the one I'm trying to open. If I put a folder with all the dependent DLLs as part of the path system variable it works. Why is this happening? – Eamonn May 05 '16 at 06:14
  • 1
    @eamonn what is the dll you are trying to load? Is it a dll packaged with the addon? If it is then you will have to modify `install.rdf` to be `true`, the default unpack is false. If it is not a packaged with your addon dll then you can just specify the path to it. – Noitidart May 05 '16 at 15:32
  • @Noitidart Yep the dlls are packaged with the extension. The package.manifest contains the line: `"unpack": true`. To get the path of the dll I'm doing: `var dll_path = Services.io.newURI(data.url('operations.dll'), null, null).QueryInterface(Ci.nsIFileURL).file.path;` which returns a path like `C:\Users\Eamonn\AppData\Local\Temp\1\f6ff0a5f-64b9-4953-a7a4-cb5b0a16c29c\extensions\@extension\data\operations.dll`. – Eamonn May 06 '16 at 02:32
  • When I drop an executable in that path with the dlls that runs some tests on operations.dll, it works. I have tried other ways of getting the path like using prepending 'file://' to the start of the file path string and using forward slashes but Firefox cant load the dll when doing that either. – Eamonn May 06 '16 at 02:36
  • I have uploaded a project to github to show the issue I am facing. [https://github.com/EamonnLaffey/ctypes-test](https://github.com/EamonnLaffey/ctypes-test) – Eamonn May 06 '16 at 04:48
  • I have posted a seperate question here: [http://stackoverflow.com/questions/37065027/firefox-ctypes-js-cannot-open-a-dll-with-dependencies](http://stackoverflow.com/questions/37065027/firefox-ctypes-js-cannot-open-a-dll-with-dependencies) – Eamonn May 06 '16 at 05:37