Hmm ... watch out that COM with C can become really hard to deal with (and generate quite ugly code with all those CLSID.)DarylD wrote: The COM idea Tim mentioned is quite interesting.
Update: I have decided to stick to C for now. Seems like C++ has too many issues.
I wish there was a nice language to express interface-based code and which would translate to plain C.
I'm also addressing this issue and the best way i found to have clean code is to generate those structs and __inline__ message formatting from a small interface description language called "slang".I would also like to use my message passing system more if I can including OS calls. The problem I have currently is that all my calls to the kernel using the API require various structs which must be in the header files for the API. Seems a little messy, I would like a system where I can send all parameters in a message and maybe instead of using the get module handle/module call ID system, is instead a way of using Module::call syntax. It should hopefully help separate the API and kernel more. Still toying with ideas though.
Code: Select all
Here is what to be said to declare the boxes and lines drawing
for "Simple Super User Interface" of Clicker:
service display {
/** The default display interface. It has the ability to draw a
* character array on a given text console and can be extended
* to draw boxes, areas and line (wildly used in the showinfo
* text interface.
*/
interface basic {
void print(console* con; char txt[0];);
}
interface box extends basic {
void printbox(console* con; char {x, y, w, h}; dspBoxPattern pattern );
void printarea(console* con; dspArea area);
void printhline(console* con; char {x, y, len, stx, etx, txt});
void printvline(console* con; char {x, y, len, stx, etx, txt});
}
}
Code: Select all
extern struct kdsClient *__DISPLAY_BOX_PREFIX(Client);
enum { __DISPLAY_BOX_NOPE=__DISPLAY_BASIC_LAST_METHOD-1,
__DISPLAY_BOX_PRINTBOX,
__DISPLAY_BOX_PRINTAREA,
__DISPLAY_BOX_PRINTHLINE,
__DISPLAY_BOX_PRINTVLINE,
__DISPLAY_BOX_LAST_METHOD
};
// method printbox (console* con; char {x, y, w, h}; dspBoxPattern pattern ) returns void
struct __DISPLAY_BOX_PREFIX(_printbox_msg) {
console* con;
char x;
char y;
char w;
char h;
dspBoxPattern pattern;
};// stub for display.box:printbox
static __inline__ void __DISPLAY_BOX_PREFIX(_printbox)(console* con, char x, char y, char w, char h, dspBoxPattern pattern)
{
struct __DISPLAY_BOX_PREFIX(_printbox_msg) msg={
con : con,
x : x, y : y, w : w, h : h,
pattern : pattern,
};
kdsInvoque(__DISPLAY_BOX_PREFIX(Client),
__DISPLAY_BOX_PRINTBOX, &msg);
}
// method printarea (console* con; dspArea area) returns void
struct __DISPLAY_BOX_PREFIX(_printarea_msg) {
console* con;
dspArea area;
};
// stub for display.box:printarea
static __inline__ void __DISPLAY_BOX_PREFIX(_printarea)(console* con, dspArea area)
{
struct __DISPLAY_BOX_PREFIX(_printarea_msg) msg={
con : con,
area : area,
};
kdsInvoque(__DISPLAY_BOX_PREFIX(Client),
__DISPLAY_BOX_PRINTAREA, &msg);
}
Multiple mouse cursors on the screen, if you have two hooked up? Who would need that? but the point is does the system have the potential to do so.
)