JSctypes: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(hint to js-ctypes as hint template)
m (Updated the link to the devmo page)
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
<p>
{{Note|This article is outdated. See the devmo pages for the current version.https://developer.mozilla.org/en/JavaScript_code_modules/ctypes.jsm}}
<span class="fck_mw_template">{{Note|This article is outdated. See the devmo pages for the current version.<br><a href="https://developer.mozilla.org/en/js-ctypes">https://developer.mozilla.org/en/js-ctypes</a>}}</span>
</p>


<h2> Overview </h2>
== Overview ==
<p>js-ctypes is a foreign-function library for Mozilla’s privileged JavaScript. It provides C-compatible data types and allows JS code to call functions in shared libraries (dll, so, dylib) and implement callback functions. The interface and implementation are modeled on the <a href="http://docs.python.org/lib/module-ctypes.html">Python ctypes module</a>.  
 
</p><p>The main objective for the library is to help developers avoid building binary (C++) <a href="http://developer.mozilla.org/en/docs/XPCOM">XPCOM</a> components when only a simple wrapper is needed. Such situations include:  
js-ctypes is a foreign-function library for Mozilla’s privileged JavaScript. It provides C-compatible data types and allows JS code to call functions in shared libraries (dll, so, dylib) and implement callback functions. The interface and implementation are modeled on the [http://docs.python.org/lib/module-ctypes.html Python ctypes module].
</p>
 
<ol><li>Developer wants functionality not built into the Mozilla platform, but easily supported by the native OS.  
The main objective for the library is to help developers avoid building binary (C++) [http://developer.mozilla.org/en/docs/XPCOM XPCOM] components when only a simple wrapper is needed. Such situations include:
</li><li>Developer wants to use a 3rd party library in an extension or XUL app.  
 
</li><li>Developer has methods in native code for performance reasons.
# Developer wants functionality not built into the Mozilla platform, but easily supported by the native OS.
</li></ol>
# Developer wants to use a 3rd party library in an extension or XUL app.
<p>The usual answer to these problems is creating a binary (C++) component to act as a wrapper so the native features can be exposed to JavaScript via XPCOM. However, the process of building binary XPCOM components is significantly harder than <a href="http://developer.mozilla.org/en/docs/How_to_Build_an_XPCOM_Component_in_Javascript">JavaScript components</a>. The macros and memory management rules of binary components are harder than JavaScript, but its really the compiler and linker flags, IDL, makefiles and SDK versioning that make the process painful. The build process must be repeated for each platform too. For many cases, its just too much work.  
# Developer has methods in native code for performance reasons.
</p><p>The goal of js-ctypes is to allow developers to declare methods in binary libraries and then expose those methods as callable JavaScript functions. Developers can then create pure JavaScript library wrappers around binary libraries - without making binary XPCOM wrappers.  
 
</p>
The usual answer to these problems is creating a binary (C++) component to act as a wrapper so the native features can be exposed to JavaScript via XPCOM. However, the process of building binary XPCOM components is significantly harder than [http://developer.mozilla.org/en/docs/How_to_Build_an_XPCOM_Component_in_Javascript JavaScript components]. The macros and memory management rules of binary components are harder than JavaScript, but its really the compiler and linker flags, IDL, makefiles and SDK versioning that make the process painful. The build process must be repeated for each platform too. For many cases, its just too much work.
<h2> Example Usage </h2>
 
<pre>/* Load JS Ctypes Javascript module */
The goal of js-ctypes is to allow developers to declare methods in binary libraries and then expose those methods as callable JavaScript functions. Developers can then create pure JavaScript library wrappers around binary libraries - without making binary XPCOM wrappers.
Components.utils.import(&quot;resource://gre/modules/ctypes.jsm&quot;);
 
== Example Usage ==
 
<pre>
/* Load JS Ctypes Javascript module */
Components.utils.import("resource://gre/modules/ctypes.jsm");


/* Load windows api dll */
/* Load windows api dll */
var lib = ctypes.open(&quot;C:\\WINDOWS\\system32\\user32.dll&quot;);
var lib = ctypes.open("C:\\WINDOWS\\system32\\user32.dll");


/* Declare the signature of the function we are going to call */
/* Declare the signature of the function we are going to call */
var msgBox = lib.declare(&quot;MessageBoxW&quot;,
var msgBox = lib.declare("MessageBoxW",
                         ctypes.stdcall_abi,
                         ctypes.stdcall_abi,
                         ctypes.int32_t,
                         ctypes.int32_t,
Line 32: Line 35:


/* Do it! */
/* Do it! */
var ret = msgBox(0, &quot;Hello world&quot;, &quot;title&quot;, MB_OK);
var ret = msgBox(0, "Hello world", "title", MB_OK);


/* Display the returned value */
/* Display the returned value */
alert(&quot;MessageBox result&nbsp;: &quot;+ret);
alert("MessageBox result : "+ret);


lib.close();
lib.close();
</pre>  
</pre>
<p>Instead of defining the whole path, you may also just give the file name.  
 
</p>
Instead of defining the whole path, you may also just give the file name.
<pre>var lib = ctypes.open(&quot;user32.dll&quot;);
 
</pre>  
<pre>
<p>Or even without the extension.  
var lib = ctypes.open("user32.dll");
</p>
</pre>
<pre>var lib = ctypes.open(&quot;user32&quot;);
 
</pre>  
Or even without the extension.
<p>If the full path is not given, Windows uses the following search order to locate the DLL:  
 
</p>
<pre>
<ol><li>The current directory of the task that is using the DLL.  
var lib = ctypes.open("user32");
</li><li>The \WINNT directory.  
</pre>
</li><li>The \WINNT\SYSTEM directory.  
 
</li><li>The \WINNT\SYSTEM32 directory.  
If the full path is not given, Windows uses the following search order to locate the DLL:
</li><li>The directory of the executable for the task that is using the DLL.  
#The current directory of the task that is using the DLL.
</li><li>A directory listed in the PATH environment variable.
#The \WINNT directory.
</li></ol>
#The \WINNT\SYSTEM directory.
<p>(taken from http://support.microsoft.com/kb/164501/)  
#The \WINNT\SYSTEM32 directory.
</p><p><span class="fck_mw_template">{{Note|This functionality cannot be accessed from JavaScript used in web content. Only JavaScript that runs with chrome privileges (extensions and Firefox UI for example) can use js-ctypes.}}</span>
#The directory of the executable for the task that is using the DLL.
</p>
#A directory listed in the PATH environment variable.
<h2> Technical Notes and Limitations </h2>
 
<p>The js-ctypes code uses the same <a href="http://sourceware.org/libffi/">libffi</a> library as the Python ctypes module. It is currently known to work on Windows, Mac and Linux.  
(taken from http://support.microsoft.com/kb/164501/)
</p>
 
<h2> Getting the Code </h2>
{{Note|This functionality cannot be accessed from JavaScript used in web content. Only JavaScript that runs with chrome privileges (extensions and Firefox UI for example) can use js-ctypes.}}
<p>The code can be checked out using Subversion:  
 
</p>
== Technical Notes and Limitations ==
<pre>svn co http://svn.mozilla.org/projects/js-ctypes/trunk/
 
</pre>  
The js-ctypes code uses the same [http://sourceware.org/libffi/ libffi] library as the Python ctypes module. It is currently known to work on Windows, Mac and Linux.
<p>It can also be viewed online <a href="http://viewvc.svn.mozilla.org/vc/projects/js-ctypes/">here</a>.  
 
</p>
== Getting the Code ==
<h2> Build Instructions </h2>
 
<p>Until js-ctypes makes its way into the Mozilla tree, building it will be a bit of a chore.  
The code can be checked out using Subversion:
</p><p>You'll first want to check out and build the Mozilla tree. See the <a href="http://developer.mozilla.org/en/docs/Build_Documentation">Build Documentation</a> for information on how to do this. The rest of these instructions assume that the path to your mozilla tree source is called <tt>PATH_TO_MOZILLA</tt> and that your objdir is in <tt>PATH_TO_OBJDIR</tt>.  
 
</p><p>You'll first want to create a directory called <tt>PATH_TO_MOZILLA/toolkit/components/js-ctypes</tt> and put the svn checkout there.  
<pre>
</p><p>Then, from your objdir root, run the following command:  
svn co http://svn.mozilla.org/projects/js-ctypes/trunk/
</p>
</pre>
<pre>PATH_TO_MOZILLA/build/autoconf/make-makefile toolkit/components/js-ctypes
 
</pre>  
It can also be viewed online [http://viewvc.svn.mozilla.org/vc/projects/js-ctypes/ here].
<p>This should build the necessary Makefiles in your objdir, creating directories as necessary.  
 
</p><p>Now enter the <tt>PATH_TO_OBJDIR/toolkit/components/js-ctypes</tt> directory and run <tt>make</tt>.  
== Build Instructions ==
</p><p>Once that's done, you should be able to enter <tt>PATH_TO_OBJDIR/dist/bin</tt> and use <a href="http://www.mozilla.org/scriptable/XPCShell.html">xpcshell</a> to play around with the component (see the example usage code above).  
 
</p>
Until js-ctypes makes its way into the Mozilla tree, building it will be a bit of a chore.
<h2> Contributing </h2>
 
<p>Contributions are welcome! We have a Bugzilla component (<a href="https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&amp;product=Other+Applications&amp;component=js-ctypes&amp;resolution=---&amp;chfieldto=Now">see bugs</a>, <a href="https://bugzilla.mozilla.org/enter_bug.cgi?product=Other%20Applications&amp;component=js-ctypes">file bug</a>). Please feel free to join <tt>#labs</tt> on irc.mozilla.org if you have any other questions.  
You'll first want to check out and build the Mozilla tree. See the [http://developer.mozilla.org/en/docs/Build_Documentation Build Documentation] for information on how to do this. The rest of these instructions assume that the path to your mozilla tree source is called <tt>PATH_TO_MOZILLA</tt> and that your objdir is in <tt>PATH_TO_OBJDIR</tt>.
</p><p><br />
 
</p>
You'll first want to create a directory called <tt>PATH_TO_MOZILLA/toolkit/components/js-ctypes</tt> and put the svn checkout there.
 
Then, from your objdir root, run the following command:
 
<pre>
PATH_TO_MOZILLA/build/autoconf/make-makefile toolkit/components/js-ctypes
</pre>
 
This should build the necessary Makefiles in your objdir, creating directories as necessary.
 
Now enter the <tt>PATH_TO_OBJDIR/toolkit/components/js-ctypes</tt> directory and run <tt>make</tt>.
 
Once that's done, you should be able to enter <tt>PATH_TO_OBJDIR/dist/bin</tt> and use [http://www.mozilla.org/scriptable/XPCShell.html xpcshell] to play around with the component (see the example usage code above).
 
== Contributing ==
 
Contributions are welcome! We have a Bugzilla component ([https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Other+Applications&component=js-ctypes&resolution=---&chfieldto=Now see bugs], [https://bugzilla.mozilla.org/enter_bug.cgi?product=Other%20Applications&component=js-ctypes file bug]). Please feel free to join <tt>#labs</tt> on irc.mozilla.org if you have any other questions.

Latest revision as of 07:45, 22 October 2009

Note: This article is outdated. See the devmo pages for the current version.https://developer.mozilla.org/en/JavaScript_code_modules/ctypes.jsm

Overview

js-ctypes is a foreign-function library for Mozilla’s privileged JavaScript. It provides C-compatible data types and allows JS code to call functions in shared libraries (dll, so, dylib) and implement callback functions. The interface and implementation are modeled on the Python ctypes module.

The main objective for the library is to help developers avoid building binary (C++) XPCOM components when only a simple wrapper is needed. Such situations include:

  1. Developer wants functionality not built into the Mozilla platform, but easily supported by the native OS.
  2. Developer wants to use a 3rd party library in an extension or XUL app.
  3. Developer has methods in native code for performance reasons.

The usual answer to these problems is creating a binary (C++) component to act as a wrapper so the native features can be exposed to JavaScript via XPCOM. However, the process of building binary XPCOM components is significantly harder than JavaScript components. The macros and memory management rules of binary components are harder than JavaScript, but its really the compiler and linker flags, IDL, makefiles and SDK versioning that make the process painful. The build process must be repeated for each platform too. For many cases, its just too much work.

The goal of js-ctypes is to allow developers to declare methods in binary libraries and then expose those methods as callable JavaScript functions. Developers can then create pure JavaScript library wrappers around binary libraries - without making binary XPCOM wrappers.

Example Usage

/* Load JS Ctypes Javascript module */
Components.utils.import("resource://gre/modules/ctypes.jsm");

/* Load windows api dll */
var lib = ctypes.open("C:\\WINDOWS\\system32\\user32.dll");

/* Declare the signature of the function we are going to call */
var msgBox = lib.declare("MessageBoxW",
                         ctypes.stdcall_abi,
                         ctypes.int32_t,
                         ctypes.int32_t,
                         ctypes.ustring,
                         ctypes.ustring,
                         ctypes.int32_t);
var MB_OK = 3;

/* Do it! */
var ret = msgBox(0, "Hello world", "title", MB_OK);

/* Display the returned value */
alert("MessageBox result : "+ret);

lib.close();

Instead of defining the whole path, you may also just give the file name.

var lib = ctypes.open("user32.dll");

Or even without the extension.

var lib = ctypes.open("user32");

If the full path is not given, Windows uses the following search order to locate the DLL:

  1. The current directory of the task that is using the DLL.
  2. The \WINNT directory.
  3. The \WINNT\SYSTEM directory.
  4. The \WINNT\SYSTEM32 directory.
  5. The directory of the executable for the task that is using the DLL.
  6. A directory listed in the PATH environment variable.

(taken from http://support.microsoft.com/kb/164501/)

Note: This functionality cannot be accessed from JavaScript used in web content. Only JavaScript that runs with chrome privileges (extensions and Firefox UI for example) can use js-ctypes.

Technical Notes and Limitations

The js-ctypes code uses the same libffi library as the Python ctypes module. It is currently known to work on Windows, Mac and Linux.

Getting the Code

The code can be checked out using Subversion:

svn co http://svn.mozilla.org/projects/js-ctypes/trunk/

It can also be viewed online here.

Build Instructions

Until js-ctypes makes its way into the Mozilla tree, building it will be a bit of a chore.

You'll first want to check out and build the Mozilla tree. See the Build Documentation for information on how to do this. The rest of these instructions assume that the path to your mozilla tree source is called PATH_TO_MOZILLA and that your objdir is in PATH_TO_OBJDIR.

You'll first want to create a directory called PATH_TO_MOZILLA/toolkit/components/js-ctypes and put the svn checkout there.

Then, from your objdir root, run the following command:

PATH_TO_MOZILLA/build/autoconf/make-makefile toolkit/components/js-ctypes

This should build the necessary Makefiles in your objdir, creating directories as necessary.

Now enter the PATH_TO_OBJDIR/toolkit/components/js-ctypes directory and run make.

Once that's done, you should be able to enter PATH_TO_OBJDIR/dist/bin and use xpcshell to play around with the component (see the example usage code above).

Contributing

Contributions are welcome! We have a Bugzilla component (see bugs, file bug). Please feel free to join #labs on irc.mozilla.org if you have any other questions.