Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

js-ctypes small DLL/LIB not loaded very fast

91 views
Skip to first unread message

gigasof...@gmail.com

unread,
Apr 25, 2013, 1:56:25 PM4/25/13
to
Hi All,

We have run into a few problems with js-ctypes and loading of a DLL. First off we have verified that the DLL works and all methods are called properly. But the problem appears to be the load time of the library.

On a side note… this is a pure “C” DLL/LIB that will be compiled on the Mac/Linux. Very fast and light weight. (no MFC or any other M$ bloat)

This is a code snippet of what we had to do.


AddonManager.getAddonByID(is.EXTENSION_ID, // Not called in the windows load function.. called sometime after
function(addon)
{
var libcPath = addon.getResourceURI("components/our.dll");
if (libcPath instanceof Components.interfaces.nsIFileURL)
{
is.component.is_lib = ctypes.open(libcPath.file.path);
is.component.done = true;

}
});

.
.
.
// A short time after loading, we try to call a function. We were forced to
// put this timer in, otherwise the library handler will be null. Ugly!!!

if(!is.component.done)
{
setTimeout(
function()
{
try
{
var callMe = is.component.is_lib.declare("CallMe",
ctypes.winapi_abi,
ctypes.jschar.ptr,
ctypes.jschar.ptr,
ctypes.jschar.ptr);
}
catch(e)
{
// Throws exception
// if timer is set to like 100 ms ...
// stating the the is.component.is_lib is null
alert(e)
}

}, 1000);

}

We have a few questions to anybody that has any thoughts or ideas.

1. Is there an event that we can capture to let us know the library has finished loading
2. Is there a way to preload the DLL in Firefox.
3. Is there any faster way to load this.


Thanks,
Tom

Jorge Villalobos

unread,
Apr 25, 2013, 7:48:04 PM4/25/13
to gigasof...@gmail.com
You mentioned that you kick off the code some time after the windows
load function. Does that mean that the code is still run at load time?
Have you tried loading it by user action, like with a button, to see if
the timer is still necessary?

The problem could be that it's not possible to load libraries during the
load process, so there's an artificial delay being introduced. In that
case I think the better solution would be to set a timeout for all of
your startup code, which can also help with overall startup performance
(https://blog.mozilla.org/addons/2010/06/14/improve-extension-startup-performance/).

As for preloading the DLL, one way to do this is with a binary XPCOM
component, but I would recommend against it. ctypes were created
precisely as a better alternative to binary XPCOM.

Regards,

Jorge

On 4/25/13 11:56 AM, gigasof...@gmail.com wrote:
> Hi All,
>
> We have run into a few problems with js-ctypes and loading of a DLL. First off we have verified that the DLL works and all methods are called properly. But the problem appears to be the load time of the library.
>
> On a side note� this is a pure �C� DLL/LIB that will be compiled on the Mac/Linux. Very fast and light weight. (no MFC or any other M$ bloat)

gigasof...@gmail.com

unread,
Apr 26, 2013, 9:50:21 AM4/26/13
to
Hi Jorge,

Thanks for your response.

Unfortunately we cannot add any user interface to this extension and XPCOM is not an option.

We are delaying about a second after loading the DLL before trying to call any exported functions.

Our goal is to have this DLL/Lib active before the first content document is loaded.

You mention a JavaScript code module (interesting thought) would be better approach. How would I setup my extension to load this code module in the most time efficient manner that would load the DLL at startup?

Again, thanks for the response.

Regards,
Tom

Benjamin Smedberg

unread,
Apr 26, 2013, 11:15:33 AM4/26/13
to Jorge Villalobos, dev-ext...@lists.mozilla.org
On 4/25/2013 7:48 PM, Jorge Villalobos wrote:
>
> The problem could be that it's not possible to load libraries during the
> load process, so there's an artificial delay being introduced.
Jorge, do you have more details on this? This is very surprising to me:
I would expect that a ctypes library would be completely usable as soon
as ctypes.open has returned. If .open is in fact an asynchronous
function, is there a callback to infor the caller when it is in fact ready?

--BDS

Jorge Villalobos

unread,
Apr 26, 2013, 11:20:17 AM4/26/13
to Benjamin Smedberg, dev-ext...@lists.mozilla.org
Actually, I was asking Tom to perform that experiment to see if what I
said had any truth to it. It was just a hypothesis.

I checked the load API, and it's designed to be synchronous, so I agree
that it should act that way. We should try to figure out the reasons
behind the delay in Tom's case, since there might be something there
that we're missing.

Jorge

Jorge Villalobos

unread,
Apr 26, 2013, 11:20:17 AM4/26/13
to Benjamin Smedberg, dev-ext...@lists.mozilla.org
On 4/26/13 9:15 AM, Benjamin Smedberg wrote:

gigasof...@gmail.com

unread,
Apr 28, 2013, 11:55:52 AM4/28/13
to
The example I gave is executed about 500 ms after the unload event (one shot timer). If we try to load the DLL in the window.onload event and call a function immediately after the "ctypes.open" ...it will throw an exception (null library...). It seems that the DLL is not loaded until about 1-2 seconds after the load and we have verified this on two different windows 7 machines.

I have performed the open function in other extensions; but all of those did not require loading the library at start up. So I believe the issue is probably a start up issue in Firefox.

Unfortunately the goal of this project is to load the DLL at start-up as soon as possible...before the content document is loaded.

Tom

Jorge Villalobos

unread,
Apr 29, 2013, 10:23:08 AM4/29/13
to gigasof...@gmail.com
Have you filed a bug for this? I minimal proof of concept would help
narrow down this problem and figure out what's going on.

Jorge

gigasof...@gmail.com

unread,
Apr 29, 2013, 11:27:30 AM4/29/13
to
I will put together a demo xpi for you sometime today. You will need a windows box...we have not finished our mac library yet
0 new messages