When I tried to link the plugin template with the inferno code I found some problems. I need to call inferno functions from the plugin code, inferno code is linked as a shared librery with the plugin code, so it's possible to call inferno functions and to put includes of inferno headers without telling the plugin where are the inferno headers.
It's important to use 'nm' in order to know the symbol definition table, if a call to a inferno function from the plugin code is defined there is no problem, that is, the links are right.
The real trouble I have is the redefinition of malloc(s) functions, the inferno code redefines malloc,free, and many other functions, when emu is compiled as a static executable there is no problem because malloc/free are local symbols and when a call to malloc/free is found it's mapped to the malloc/free redefinition in the inferno code. But when inferno is compiled as a shared library and it's dynamically loaded from firefox, the malloc/free calls from the inferno code are mapped to the libc malloc/free instead the inferno ones. This happens because of firefox uses the standard malloc/free functions from libc, and it's statically linked, so the malloc of libc is found before the malloc redefinition within inferno code.
Shared libraries must import any symbols they use but do not define. But it's possible to import symbols that are defined in the shared library. Even though malloc is in the library, nothing else there refers to it directly; all references are through an imported symbol pointer. If the application does not redefine malloc, both application and library calls are routed to the library version. All calls are mapped to the alternate, if present.
5.05.2008
4.11.2008
Setting the Mozilla Plugin development environment
Before the fight with the Inferno specific issues I must have a right and clean Mozilla Plugin development environment, that is: the structure of source code files and include files from the Mozilla source tree in order to link the code of my plugin to those files.
In order to have a clean environment I decided to use the Gecko SDK 1.8 for linux, download the tar.b2z file and decompress & expand it on a directory of your election, "~/IPMF/gecko-sdk" seems to be ok.
When you will write the Makefile of the plugin you must have in mind to include "gecko-sdk/include" in order to be used for the plugin. You can move the "gecko-sdk/include" folder to another location within your plugin's tree in order to be more clear.
A Mozilla Plugin must implement three types of functions, NPN functions, NPP functions and NP functions.
NPN functions are the functions that the plugin can call from the browser (NPN is NPNetscape), you can find documentation about NPN functions in the Browser-Side Plugin API.
NPP functions are the functions that the browser will call from the plugin (NPP is NPPlugin), and you can find documentation about the NPP functions in the Plugin-Side Plugin API.
Mozilla uses two function tables (NPNetscapeFuncs and NPPluginFuncs) in order to let Netscape to know the pointers to the NPP functions that the plugin implements, and the same thing for the plugin. These two tables must be filled before the plugin instance is created (in the initialization).
So NP functions are the main plugin entry points, these functions are:
- NP_Initialize: fills the NPN and NPP function tables and calls to plugin initialization specific functions.
- NP_Shutdown
-NP_GetMimedDescription: returns MIME Types description before the plugin instance is created (to the about:plugins page for instance).
- NP_GetValue: to get the plugin version, and many other.
In the mozilla source tree there are several locations where you can find plugin examples, for instance, "mozilla/modules/tools/sdk/samples/", I get the entire "common" folder and copied it to the directory of my plugin. The common folder contains three files, np_entry.cpp, npp_gate.cpp and npn_gate.cpp. NPN_gate.cpp contains stubs functions of the NPN functions, the same with NPP for the plugins functions, and NP_entry.cpp contains the main entry points for the plugins, the NP functions.
These stubs calls to specific functions of the plugin's code named NS_function's, i.e., the plugin will implement a function named NS_PluginInitialize or NS_NewPluginInstance but Firefox won't call straight these functions but it will call the NPP_New function (it's in the NPPluginFunctions table), and the stub of NPP_New (in NPP_gate) will finally call NS_New, and you have to write the NS_New function.
To sum up, a right and clean Mozilla Plugin Development Environment will consist in:
- All the include files of mozilla gecko-sdk
- The common folder with the stub files (npp_gate, npn_gate, np_entry)
- The source files of the plugin itself
- A well done Makefile in order to compile the plugin source files (including the gecko-sdk includes)
-IPMF - common - npp_gate.cpp
npn_gate.cpp
np_entry.cpp
include - pluginbase.h
... (gecko-sdk include files)
Makefile
plugin.cpp
plugin.h
...
And then it's time for Inferno issues...
In order to have a clean environment I decided to use the Gecko SDK 1.8 for linux, download the tar.b2z file and decompress & expand it on a directory of your election, "~/IPMF/gecko-sdk" seems to be ok.
When you will write the Makefile of the plugin you must have in mind to include "gecko-sdk/include" in order to be used for the plugin. You can move the "gecko-sdk/include" folder to another location within your plugin's tree in order to be more clear.
A Mozilla Plugin must implement three types of functions, NPN functions, NPP functions and NP functions.
NPN functions are the functions that the plugin can call from the browser (NPN is NPNetscape), you can find documentation about NPN functions in the Browser-Side Plugin API.
NPP functions are the functions that the browser will call from the plugin (NPP is NPPlugin), and you can find documentation about the NPP functions in the Plugin-Side Plugin API.
Mozilla uses two function tables (NPNetscapeFuncs and NPPluginFuncs) in order to let Netscape to know the pointers to the NPP functions that the plugin implements, and the same thing for the plugin. These two tables must be filled before the plugin instance is created (in the initialization).
So NP functions are the main plugin entry points, these functions are:
- NP_Initialize: fills the NPN and NPP function tables and calls to plugin initialization specific functions.
- NP_Shutdown
-NP_GetMimedDescription: returns MIME Types description before the plugin instance is created (to the about:plugins page for instance).
- NP_GetValue: to get the plugin version, and many other.
In the mozilla source tree there are several locations where you can find plugin examples, for instance, "mozilla/modules/tools/sdk/samples/", I get the entire "common" folder and copied it to the directory of my plugin. The common folder contains three files, np_entry.cpp, npp_gate.cpp and npn_gate.cpp. NPN_gate.cpp contains stubs functions of the NPN functions, the same with NPP for the plugins functions, and NP_entry.cpp contains the main entry points for the plugins, the NP functions.
These stubs calls to specific functions of the plugin's code named NS_function's, i.e., the plugin will implement a function named NS_PluginInitialize or NS_NewPluginInstance but Firefox won't call straight these functions but it will call the NPP_New function (it's in the NPPluginFunctions table), and the stub of NPP_New (in NPP_gate) will finally call NS_New, and you have to write the NS_New function.
To sum up, a right and clean Mozilla Plugin Development Environment will consist in:
- All the include files of mozilla gecko-sdk
- The common folder with the stub files (npp_gate, npn_gate, np_entry)
- The source files of the plugin itself
- A well done Makefile in order to compile the plugin source files (including the gecko-sdk includes)
-IPMF - common - npp_gate.cpp
npn_gate.cpp
np_entry.cpp
include - pluginbase.h
... (gecko-sdk include files)
Makefile
plugin.cpp
plugin.h
...
And then it's time for Inferno issues...
3.27.2008
First Step: What is a Mozilla Firefox Plugin?
A Mozilla Firefox plugin is a binary component that, when it's registered with Firefox, can display contents that Firefox itself can't display natively. Plugins are written using NPAPI, the cross-browser API for plugins.
In this case, the Inferno plugin has to let Firefox to execute .dis files, in order to do it, it has to run a minimal Inferno O.S. acting as a virtual machine that will execute .dis files.
The main source of information about Mozilla Plugins is the GECKO Plugin API Reference.
It's impossible to summarize how to write a plugin, and this is not my intention, so I recommend you to read the API Reference and the Plugin Basics chapter, however I will give you some basics: The plugin is loaded into the Firefox memory, and executes within the main thread of the browser, so if you want to allocate memory you have to ask Firefox for memory through the NPN_MemAlloc and many other browser-side functions. In the Gecko API there are two kind of functions, on the one hand you can find the functions that firefox offers to be called by the plugin, the NPN functions, and on the other hand there are the functions that the plugin must implement, the NPP functions, these are the functions offered by the plugin to the browser, and these functions tell the browser how to draw the plugin, how to initialize, and let the browser to ask for plugin information or give event handling to the plugin.
Once I have downloaded and compiled the Mozilla Firefox source tree, I have built my own plugin development environment, this is , I have imported the Mozilla neccesary files from the source tree and I have written the stub of the plugin. Then I have a basic plugin that implements all the necessary NPP functions in order to let Firefox to recognice the Inferno plugin as a right Gecko plugin.
In this case, the Inferno plugin has to let Firefox to execute .dis files, in order to do it, it has to run a minimal Inferno O.S. acting as a virtual machine that will execute .dis files.
The main source of information about Mozilla Plugins is the GECKO Plugin API Reference.
It's impossible to summarize how to write a plugin, and this is not my intention, so I recommend you to read the API Reference and the Plugin Basics chapter, however I will give you some basics: The plugin is loaded into the Firefox memory, and executes within the main thread of the browser, so if you want to allocate memory you have to ask Firefox for memory through the NPN_MemAlloc and many other browser-side functions. In the Gecko API there are two kind of functions, on the one hand you can find the functions that firefox offers to be called by the plugin, the NPN functions, and on the other hand there are the functions that the plugin must implement, the NPP functions, these are the functions offered by the plugin to the browser, and these functions tell the browser how to draw the plugin, how to initialize, and let the browser to ask for plugin information or give event handling to the plugin.
Once I have downloaded and compiled the Mozilla Firefox source tree, I have built my own plugin development environment, this is , I have imported the Mozilla neccesary files from the source tree and I have written the stub of the plugin. Then I have a basic plugin that implements all the necessary NPP functions in order to let Firefox to recognice the Inferno plugin as a right Gecko plugin.
2.27.2008
Welcome
Welcome to the IPMF project, the aim of this project is to obtain a Mozilla Firefox Plugin running a minimal Inferno Operative System instance with many services available.
This project begun in 2007 within the Google Summer of Code Program, but for several work commitments I had to end it unexpectedly... but now I'm back and I'm going to begin it again and with a renew interest, so I hope to achieve it finally.
Enjoy!
This project begun in 2007 within the Google Summer of Code Program, but for several work commitments I had to end it unexpectedly... but now I'm back and I'm going to begin it again and with a renew interest, so I hope to achieve it finally.
Enjoy!
Subscribe to:
Posts (Atom)