![BeCor[o]ner](http://reveng.110mb.com/images/becoroner.gif)
06/2009 by Zadig.
Introduction:
Eresi is a wonderful and very powerful tool. However it is still lacking an important feature in my opinion: A graphical user interface. Sure its cli and its scripting language allow much more flexibility than you will ever have in any gui, but a lot of common tasks are much easier in a graphical environment, and some features just cannot be presented in a cli. This paper is a reflexion on a possible gui design that could be embedded in Eresi.
The most important point to take into account when considering a gui solution
for Eresi is that it must be cross-platform. And by cross-platform it obviously
means that it must runs perfectly on Haiku! Also in the tradition of Eresi it
should have as few external dependencies as possible so that it can run on
exotic Linux installs for example (embedded systems ?).
With such constraints only a few solutions are possible. All usual gui
frameworks are not adapted. The only one that may have been possible is QT since
it runs on a lot of systems and there are rumors that a port of for Haiku is
under work. However it is not available yet, and this stays a big dependency.
Only two other options seem possible:
So I choose the web approach for the previous reasons and a few other ones: Several javascript frameworks are available to ease gui writing, and Eresi has always been a nice field for experiments. So it seems a good way to study what can be done and what are the limits of such a design. Another good point for web technology is that canvas and svg are promising to do data visualization which is another domain that I would like to experiment in Eresi. However before everybody stops reading here thinking "argh, he's gona add apache and php in Eresi", let's will try to dissipate all doubts: The web approach that is chosen here is probably the lightest possible for a "web" technology.
So since a web browser displays the gui, a web server is needed to provide the web pages. There are 2 main ways to generate the web content:
The first one is still widely used on a lot of web sites. This solution is
not adapted to Eresi since it means embedding a new language like php with
extensions to communicate with Eresi. Unless we write a dedicated language for
this, which is not interesting to do and does not bring any benefit.
Using rpc can be much easier to integrate. Rpc can be done in a lot of ways in a
browser: Soap, Web-Services, and Rest are some of them. The idea is the same for
all of these solutions: The web page issues an http request to the server and
receives some content in the answer. This answer is then used to update the ui
on the client side. This is the base mechanism of Ajax, and is what will be used
here. From the three previous mechanisms, one was specifically designed to ease
as much as possible the communication and remove all unnecessary overhead: Rest.
REpresentational State Transfer is a design where resources are defined by the
uri and actions defined by the http method used. Requests and answers can be
received in any format, but the lightest one for both servers and clients is
undoubtly json. Json is a subset of
javascript used to store data. So basically in a Rest design, you have some html
pages that do http requests to dynamically update themself. The next figure
shows all this.
One interesting point to note in this figure is that there are 2 kinds of connections: One to get the "application" (the html/js/css files), and one to get some data dynamically (the json content). With this kind of design, you can imagine that the http client part is not a web browser but something completely different: a python or ruby script, some native c/c++ code... You can remotely control Eresi with almost any programming language that you want, provided it can handle http and json.
Everest is the "Eresi Visualization Environment in Rest". It is developed as an Eresi module for the moment. This allows an easy integration in Eresi. Since this module is based on Rest, two important pieces are needed in it: An http server, and a json parser/generator. Moreover the ui is in pure html (no server side scripting). So a javascript framework would help for developing the application.
Choosing an appropriate http server is not that easy because the requirements for it are not usual. It must:
Only few open-source projects meet these requirements. 4 of them seemed good candidates: Klone, Tntnet, libmicrohttpd, and mongoose. Tntnet is written in C++ which is not the best for Eresi. Klone and libmicrohttpd are licensed as gplv3 and I must admit that I am not a big supporter of it. Mongoose is the best choice because it is very small, it fits in a single c file, and it is documented. Moreover its development seems to be quite active.
The choice of the other elements are more natural. json-c is referenced by the json homepage and is stable enough. Moreover it is both a parser and a generator. Concerning the javascript framework I choosed jquery because I already know it and I like its design: The core library contains only tools to help ajax and dom usage. Then you can generate a custom library containing gui widgets, with only the ones that you need.
So finally the general design of Everest is the following:
A first prototype was written to do basic things. The only aim of it is to get a practical idea of the benefits and drawbacks of a rest design. So this prototype provides only 3 features:
These 3 features are provided through 3 rest apis:
All rest apis are located in the "rest" root directory of the http server. Note the use of the "*" regexp that can be used to register a single handle for multiple URIs. In our case the "*" must contain the index of a loaded elf object. The prototype does not handles this, but that is the idea for the future. The answer is sent in the "data" field of a json object.
The "symtab" api can take arguments to specify the start index and item count of the symbols to retrieve. The client side code uses them to fetch symbols by chunks of 100 items. With this it takes about 3s to display a symtab of 1000 items with eresi running in a vmware Haiku, and Opera running on a windows host. This is quite long but there is room for improvements. You can see the visual result of about 200 lines of html/js/css code and 400 lines of C code on the following screenshots.
This is the end for the presentation of Everest. As you can see it is just a very early prototype for the moment, that I will use for my own experiments. The very nice point of html/js is that several kinds of gui elements can be written with only few lines of code. The main drawback, as expected, is performance that will probably be something to watch on big binaries. Sources are not available yet since it not in a useful state but if this project gives interesting results I will provide them. I will be glad to discuss any comment on the Eresi mailing list. The next steps will be displaying disassembly and graphs, and deciding of the general gui layout.
Zadig.