From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-07-28 06:29:01
Vladimir Prus wrote:
>Bronek Kozicki wrote:mechanism Garland wrote:
> >> This isn't really a re-invention of either -- just a very small library
> >> does someskeletonsilar to what both do -- without all the baggage. COM
> >> is a
> >> Windows only option, for example. Both are big frameworks with gobs of
> >> stuff not needed to load a dll and call a function.
> > I think that similar motivation drove YAMI project, see
> > http://www.msobczak.com/prog/yami/
>Do you mean "without all the baggage" by "similar motivation"? What I see
>the page is still very complex -- some network communication and the like.
>I want just portable mechanism to access objects from shared libraries.
>is much more lightweight than CORBA, which requires IDL, stubs, skeletons,
>supports talking to objects on other machines, a lots of other stuff.
Frameworks like COM and CORBA are designed to be language independent: this
is why they use IDL for describing interfaces. Since what you require is
C++-specific, you can skip the IDL language and use abstract base classes
and/or virtual functions, which is what Volodya is doing.
The frameworks also provide some means of generic exception handling. COM
skips this by returning an error code (HRESULT) value because of the issues
of dealing with exceptions across language borders (e.g. C++ to C). The C++
exception mechanism is fine for what Volodya wants because there will be no
The frameworks may provide some means of automation. COM uses a discriminant
union type (VARIANT) and a dispatch interface to achieve this, as well as
providing direct access via the interfaces. I don't think scripting is an
important issue in this case, but it should be possible to implement using
The frameworks provide a mechanism for managing object lifetimes. COM does
this by the base interface supporting AddRef/Release with the DLL
responsible for construction (via exposed object types) and the object
responsible for deconstruction (deleting itself once the reference count is
0). As I see it, this is intended to be implemented using shared_ptr's, the
issue being *how* to load the objects and DLL's.
In COM the object is responsible for keeping the DLL alive (via a reference
count on the DLL as has been mentioned in other posts). If there are two
objects from the DLL alive, then the DLL's reference count is two (unless it
is explicitly locked to keep it alive).
The MS documentation on DllMain says:
During initial process startup or after a call to LoadLibrary, the system
scans the list of
loaded DLLs for the process. For each DLL that has not already been
called with the
DLL_PROCESS_ATTACH value, the system calls the DLL's entry-point
Thus, if the DLL is already loaded by a process, it will not reload it on
successive calls to LoadLibrary.
The documentation on FreeLibrary says:
The FreeLibrary function decrements the reference count of the loaded
library (DLL). When the reference count reaches zero, the module is
the address space of the calling process and the handle is no longer
Thus, there is no easy way to reload a DLL. The best solution would be to
release the instance of the plugin you have loaded and let the system unload
the DLL. It is best to only be concerned about the DLL when loading the
If you want to alter plugins at run-time (e.g. removing or adding a plugin),
just remove all references to the plugin to delete it or load the plugin
into the plugin map from the DLL.
The frameworks provide other facilities, but I think these are the main
(core) facilities. I am not sure how this will map to Linux or MacOS
Want to block unwanted pop-ups? Download the free MSN Toolbar now!