When we register DBusObjectPathVTable then who will call the message_function? i.e dbus-daemon will call or the dbus main loop ( _dbus_loop_run function) will call?
libdbus will call members of the DBusObjectPathVTable from the libdbus main loop. You could have checked this yourself by grepping for the members in the libdbus source code: cd dbus.git && git grep message_function shows that dbus/dbus-object-tree.c contains all the calls to it. dbus-object-tree.c is part of libdbus.
It is highly recommended that you use a D-Bus library other than libdbus, however, as libdbus is fiddly to use correctly. If possible, use GDBus or QtDBus instead, as they are much higher-level bindings which are easier to use. If you need a lower-level binding, sd-bus is more modern than libdbus.
Related
I have a devilish-gui.exe, a devilish.dll and a devilish.h from a C codebase that has been lost.
devilish-gui is still used from the customer and it uses devilish.dll
devilish.h is poorly documented in a 30-pages pdf: it exposes a few C functions that behave in very different ways according to the values in the structs provided as arguments.
Now, I have to use devilish.dll to write a new devilish-webservice. No, I can't rewrite it.
The documentation is almost useless, but since I have devilish-gui.exe I'd like to write a different implementation of the devilish.h so that it log function's call and arguments in a file, and than calls the original dll function. Something similar to what ltrace does on linux, but specialized for this weird library.
How can I write such "intercepting" dll on windows and inject it between devilish.dll and devilish-gui.exe?
A couple of possibilities:
Use Detours.
If you put your implementation of devilish.dll in the same directory as devilish-gui.exe, and move the real implementation of devilish.dll into a subdirectory, Windows will load your implementation instead of the real one. Your implementation can then forward to the real one. I'm assuming that devilish-gui isn't hardened against search path attacks.
Another approach would be to use IntelliTrace to collect a trace log of all the calls into devilish.dll.
Is it correct to use (parts of) GLib without calling g_main_loop_run? If so, how to identity which parts of GLib I can use like this?
I'm mostly interested in (as referred to by https://developer.gnome.org/glib/2.34/index.html):
GLib Data Types;
GLib Utilities.
Common sense tells me that there should be nothing there to require GMainLoop (except Timers, may be?), but I'm a complete GLib newbie, and somehow didn't find any explicit statement in the docs when GMainLoop is required and when not.
From "GLib Core Application Support" section I'd like to use Message Logging, but not sure about it interaction with main loop.
For those wondering about why, I use FUSE/osxfuse, which already has its main loop, and I'm not sure how easy it is to deconstruct it and integrate into GMainLoop.
Also, I welcome alternative C library suggestions. Looking through GLib docs I rather like it, but I feel uneasy about it trying to be a framework, rather than a set of libraries.
Very little of the GLib code requires the main loop, timers for example are implemented using the system's normal timestamp.
The code that does require the main loop will reference it, such as the IO Channels. Even then you can see that it's possible to use the IO Channels with or without the main loop, it's your choice.
We have a "library" (a selection of code we would rather not change) that is written from the perspective that it has access to 2 files directly. It uses "open", "read" and "seek" posix calls directly on a file descriptor.
However, now we have a proprietary file system that cannot be accessed through standard IO calls. Seeing that we do not want to re-write the code, it would be great if we could redirect the IO calls to known functions that could then be used as an interface.
Is there any way of changing the calls used above so that the "read" and "seek" can be over-written with new function calls?
Thanks.
When you say you don't want to change the library code, do you mean you want to use existing binary code, or just source? If you have the source and can recompile, I would simply pass -Dread=my_read -Dopen=my_open etc. to the compiler when building the library, and then provide your own my_read etc. functions.
One thing you can try is library function interposition.
In addition to already mentioned function interposition and renaming function calls using a macro, another Linux-only option is to use Filesystem in Userspace. This way you can make your proprietary filesystem accessible to other applications which use the standard POSIX filesystem API. FUSE hello world example is surprisingly short.
Without getting into specifics, say I need to make use of a non-standard calling convention from C code. Functions that use this convention may return multiple values on the stack. It would be simple to put each function in a wrapper that uses inline assembly to make the call, sending output via pointer parameters given to the wrapper. Unfortunately, this solution doesn't generalise well, and I need something that works in the general case. Should I just give up and use macros to encapsulate wrapping, or is there a more general way to write, say, a variadic invoke function that handles the dirty work of managing the stack?
Whichever approach you choose, you'll need to write the wrapper in assembly. There is no way to fiddle with the stack from C. I do like your idea of writing a single invoke wrapper (in asm) that does all the dirty work, and then wrapping that with C.
How one can achieve late binding in C language ?
Late binding is not really a function of the C language itself, more something that your execution environment provides for you.
Many systems will provide deferred binding as a feature of the linker/loader and you can also use explicit calls such as dlopen (to open a shared library) and dlsym (to get the address of a symbol within that library so you can access it or call it).
The only semi-portable way of getting late binding with the C standard would be to use some trickery with system() and even that is at least partially implementation-specific.
If you're not so much talking about deferred binding but instead polymorphism, you can achieve that effect with function pointers. Basically, you create a struct which has all the data for a type along with function pointers for locating the methods for that type. Then, in the "constructor" (typically an init() function), you set the function pointers to the relevant functions for that type.
You still need to include all the code even if you don't use it but it is possible to get polymorphism that way.
Symbol binding in C is always done at compile time, never runtime.
Library binding, or dynamic linking as it's called, is done via dlopen() and dlsym() on *nix, and LoadLibrary() and GetProcAddress() on Windows.
How one can achieve late binding in C language ?
The closest would be through dynamic loading of library (DLL) such as with dlopen & dlsym on Linux. Otherwise, it is not directly available in C.
Use Objective-C or Lua. Both are late-bound languages which can easily interface with C.
Of course you could implement your own name resolution scheme, but why re-invent the wheel?
Unfortunately you did not specify an OS. For Unix you can use shared libraries, or create a configurable (plugin) module structure. For details you may find the source code of an apache 1.3 webserver useful. http://httpd.apache.org/download.cgi
cppdev seems to be the one and only to hit the spot with his/her remark.
Please, have a look at the definition itself. In a few words:
Late binding, or dynamic binding, is a computer programming mechanism
in which the method being called upon an object is looked up by name
at runtime.
All other answers just miss the main point, that is "look up by name".
The needed solution would be very similar to a lookup table of pointers to functions along with a function or two to select the right one by name (or even by signature). We call it a "hash table".