> ... but FIRST!!! > > PEOPLE!!!! if you know something about the internals of BeOS, > SHAREEEEE! > write a document about them!!! ESPECIALLY if you don't work in > that area!!! I would write something if I had the time, but I spent already lots of time this week just writing these e-mails :). And I rather spend time writing code :P. Actually I do work on an app_server, but one for MS windows, which I started more than a year ago now. At the point I joined OpenBeOS, my app_server was very different from the BeOS R5 one, so I joined the interface kit to work on controls instead, since that code works unchanged on windows and BeOS (yup all code is written and run on windows :P). When progressing, more and more windows code was eliminated, and now 90% of the code in the libs is OpenBeOS code. The libtranslation for example is 100% OpenBeOS, as are all translators. Nowadays apps like StyledEdit compile, build and run on windows. I noticed however that in order to make apps work the same way, or even just work, you have to mimic the app_server much more closely then I did, it's from that point I started to do some research on the R5 app_server. > I'm relatively new to BeOS, as a matter of a fact, the > most complicated program that I made under it as just 5(!!!) buttons; > but I know, in high lines, how things work under the hood, that's why > I wanted to join this project since the beginning, but I couldn't! > I stayed and studied BeOS architecture, figured some things > out, others not, made presumptions, tried to do things like Be did, > for now to discover that SOMEONE ( I think with experience in > BeOS area. Marc !?!!) ACTUALLY *KNOW* BeOS internals!!!!! I don't know the complete internals, I also have to make assumptions, and I'm never 100% sure. Only now and then I research something thoroughly to find out how it should work. > SHARE people SHARE! I don't have time to write eveything down what I know, and my notes are scatered around, however if you have a problem with something you can always ask on the list, that way it also gets some more trafic :). > > I know, but before we start to optimize, we can look if it's > needed to do > > so. As some people on the list already said, and even found out by > > themselves ;), "Premature optimization is the root of all evil". > > Here I don't agree. I think once you have a better method you have to > implement it! But I think it's better to see if it has to be optimized in the first place :). > > > dispatched to BWindow::ConvertToMessage() who will create > > > a BMessage then call BWindow::DispatchMessage(). > > > > It is indeed the event port of BWindow that gets the event messages from > the > > app_server, but they arrive as normal flattened BMessages. They are > > unflattened from the port data using the normal BMessage::Unflatten(char > > const *) in _CEventPort_::GenerateMessage() called from task_looper(). > > That's quite strange, since, by sending a BMessage, additional > data is sent > (BMessages's). By sending a message(a package of preordered data) > it will be > faster. Me and DarkWyrm would like to achieve a minimum of port > messages, with a minimum of data! I'll try to look at the 'FOB2' format once I find some time, to see if it's smaller :). > > BWindow::ConvertToMessage() is a virtual overridden method > called from the > > BLooper methods. > > In my implementation of BWindow it looks like this: > > BMessage* BWindow::ConvertToMessage(void* raw1, int32 code){ > BMessage *msg; > > // This is in case we receive a BMessage from another thread or > application > msg = BLooper::ConvertToMessage( raw1, code ); > if (msg) > return msg; > > // This is in case we receive a message from app_server > uint8 *raw; > raw = (uint8*)raw1; > > msg = new BMessage(); > > switch(code){ > ... > } > return msg; > } > > Is this not good? It also performs the functions that R5's > _CEventPort_::GenerateMessage() does. As far a I know _CEventPort_::GenerateMessage() just reads data, creates a new BMessage and unflattens it. BWindow::ConvertToMessage first calls BLooper::ConvertToMessage, if that fails it does pretty much the same as _CEventPort_::GenerateMessage(). I haven't searched for more detail, though if you're interested I'll look into it, it could be the locking is different for example. > What I would like you to > remember is that, in task_looper() both ports are checked for > messages, so there would be a few BMessage calls, a few app_server > message calls, a few BMessage calls, a few app_server message > calls .... for BWindow::ConvertToMessage(...). I think in task_looper() it first checks if _CEventPort_::GenerateMessage() has a message, if it has, it adds it to the queue, if not it calls BLooper::ReadMessageFromPort, and adds that one to the message queue if there is one returned. That's just the beginning of task_looper(), I'm afraid I don't have the time today to work it out completely, as it's 20:06 here, so I really have to go home now :). Marc Flerackers (mflerackers@xxxxxxxxxx) Software Engineer