more from the BeOS port, questions

Hello folks,
hmm, there doesn't seem to be much interest in BeOS there...
Or is everyone on vacation ? ;)
Anyway, I'm progressing, as you can see:
http://clapcrest.free.fr/revol/beos/shot_xemacs_native_wide.png
http://clapcrest.free.fr/revol/beos/shot_xemacs_native_running_xmine.png

But, I'll need some answers to avoid doing wrong things and be 
criticised when I submit the patch (yes I do intend to get that 
in the main tree.) :p

* C++:
as I already said, most of the BeAPI consists of C++ classes,
on top of a C API including a POSIX layer.
That said, I didn't have that much problems, only had to enable 
the CXX check in the configure script and add some rules.
The only real problem was that despite that there are ifdefs 
for _cplusplus in some code already, it seemed to assume that 
the whole stuff was to be compiled as C++. I don't really see 
the interest in compiling C files with g++... Anyway, I had to 
remove an ifdef in text.h IIRC, which replaced an union by a 
struct, making me wonder why it crashed in TO_EXTERNAL_FORMAT.

* charsets/encodings: still hard to get the exact differences 
between the 2, with UTF-8 it's quite blured...
Since:
- BeOS uses UTF-8 for most APIs (filesystem, ...). Technically 
it's not bound to utf-8, but it's a convention, and Tracker 
(the desktop), shows filenames as utf-8 strings (which sometimes
gives funny things when it's not).
- the BView class (the base gui widget class if you will), 
as well as the BFont class both have a SetEncoding() method,
which accepts:
enum {
        B_UNICODE_UTF8    = 0,
        B_ISO_8859_1      = 1,
        ...
        B_ISO_8859_10     = 10,
        B_MACINTOSH_ROMAN = 11
};
Which doesn't really differenciates charsets from encodings...
So, how do I tell XEmacs to always use utf-8 (with MULE at least)
when drawing strings in redisplay ?
For now if I open a utf-8 encoded file it draws ~ in place of 
complex chars, and gives warnings that it can instanciate the font
for different charsets like big5.

* The event code is quite tricky. And the way I grafted the BeOS 
messaging to it makes it even trickier.
Unlike X or Gtk, BeOS doesn't use sockets to send messages, but 
a native IPC called ports, which are wrapped by high level classes 
like BLooper (which spawns a thread and dispatches messages) and 
BHandler (which BView inherit from and receive the messages). 
Messages themselves are instances of class BMessage.
This might resembles the windows system, except that the whole 
stuff is multithreaded (that's mandatory, the BWindow class which 
inherits BLooper spawns itself the thread). A graphical BeOS application then has at least the main thread (which entry point 
is main()), and one thread per window, which have their own 
message queue. Usually the main thread gives control to 
BApplication::Run(), which runs the main message loop. In the case
of ported Unix apps, since I need the main thread to run the apps 
code, I spawn a thread just to run the BApplication object. This
works just fine.
Now, in the case of XEmacs, since I can't get the lisp engine 
MT-safe, the only option is to serialize the messages sent to the 
different windows and views (not all, just the interesting ones).
The current design is to keep the select() stuff and send pointers 
to BMessages through a pipe which serializes them.
Then there is a fake beos_main_iteration() (like the gtk one),
which reads them and converts them to Emacs_Events.
All of that works quite well already. Except I tried several things 
in beos_events_pending_p(), and none seem to work fully.
Either I get some "Arithmetic Error" on startup, either it thinks 
there has been user events, both preventing the splash screen to 
show on startup. Not that it's really harmful, but still.
Also, I can't seem to get sub processes handled correctly. If I
M-x shell all I get is a blank buffer, which doesn't respond and 
I have to C-g. On the opposite when run with -nw I can spawn a 
shell, except it sometimes get blocked, that is I get the prompt, 
I type ls, then I don't get any output. Maybe it's a bug in 
select(), or in the pipefs (which I already rewrote since the 
original one had a bug which made select() to fail in the build 
process, getting everything locked when spawning make-docfile).

That's about it for now, I'd really appreciate comments.

Cheers,
François.