20
edits
Kirschkern (talk | contribs) (try to correct the hint (shitty editor)) |
Kirschkern (talk | contribs) (corrected the article again (sorry - the editor doesn't like me)) |
||
Line 1: | Line 1: | ||
Note | {{Note|This article is outdated. See the devmo pages for the current version.https://developer.mozilla.org/en/js-ctypes}} | ||
== Overview | == 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 | 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]. | ||
The main objective for the library is to help developers avoid building binary (C++) | 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: | ||
#Developer wants functionality not built into the Mozilla platform, but easily supported by the native OS. | # Developer wants functionality not built into the Mozilla platform, but easily supported by the native OS. | ||
#Developer wants to use a 3rd party library in an extension or XUL app. | # Developer wants to use a 3rd party library in an extension or XUL app. | ||
#Developer has methods in native code for performance reasons. | # 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 | 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. | ||
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. | 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 | == Example Usage == | ||
<pre>/* Load JS Ctypes Javascript module */ | |||
<pre> | |||
/* Load JS Ctypes Javascript module */ | |||
Components.utils.import("resource://gre/modules/ctypes.jsm"); | Components.utils.import("resource://gre/modules/ctypes.jsm"); | ||
Line 36: | Line 38: | ||
/* Display the returned value */ | /* Display the returned value */ | ||
alert("MessageBox result | alert("MessageBox result : "+ret); | ||
lib.close(); | lib.close(); | ||
</pre> | </pre> | ||
Instead of defining the whole path, you may also just give the file name. | |||
<pre>var lib = ctypes.open("user32.dll"); | Instead of defining the whole path, you may also just give the file name. | ||
</pre> | |||
Or even without the extension. | <pre> | ||
<pre>var lib = ctypes.open("user32"); | var lib = ctypes.open("user32.dll"); | ||
</pre> | </pre> | ||
Or even without the extension. | |||
<pre> | |||
var lib = ctypes.open("user32"); | |||
</pre> | |||
#The current directory of the task that is using the DLL. | If the full path is not given, Windows uses the following search order to locate the DLL: | ||
#The \WINNT directory. | #The current directory of the task that is using the DLL. | ||
#The \WINNT\SYSTEM directory. | #The \WINNT directory. | ||
#The \WINNT\SYSTEM32 directory. | #The \WINNT\SYSTEM directory. | ||
#The directory of the executable for the task that is using the DLL. | #The \WINNT\SYSTEM32 directory. | ||
#The directory of the executable for the task that is using the DLL. | |||
#A directory listed in the PATH environment variable. | #A directory listed in the PATH environment variable. | ||
(taken from http://support.microsoft.com/kb/164501/) | (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 [http://sourceware.org/libffi/ 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: | |||
<pre> | |||
svn co http://svn.mozilla.org/projects/js-ctypes/trunk/ | |||
</pre> | |||
It can also be viewed online [http://viewvc.svn.mozilla.org/vc/projects/js-ctypes/ 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 [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>. | |||
You'll first want to | 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> | |||
<pre>PATH_TO_MOZILLA/build/autoconf/make-makefile toolkit/components/js-ctypes | PATH_TO_MOZILLA/build/autoconf/make-makefile toolkit/components/js-ctypes | ||
</pre> | </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. |
edits