Re: Linking DLL's across different compilers and languages

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:nqm8n2por0blc97cjkjf0ua3eochnbvp7n@xxxxxxxxxx
See below...
On Mon, 4 Dec 2006 09:56:47 -0600, "Peter Olcott" <NoSpam@xxxxxxxxxxxxx>
wrote:


"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:cnh8n2pfq8to7s6r84gqi80aqfajs83cdk@xxxxxxxxxx
Key here is that you have to use it internally ONLY. The caller only sees
an
LPVOID or
some other pointer which has no structure associated with it. Note that you
can create a
new HANDLE-derived type (there are some macros in windows.h & friends to
declare new
handle types that are type-checked at compile time), and since a HANDLE and
a
pointer are
the same size, you could declare a new HANDLE type, say HTHING. You return
HTHINGs, the
caller calls you with HTHINGs, but the caller can never "open up" an HTHING
to
look inside

it. That is done solely within your DLL. If the user wants the 10th
element
of an
HTHING, you might have a int GetSubElement(HTHING, 10), but you would never
allow the
caller to index directly. By maintaining a rigid isolation, you make
yourself
independent
of versioning issues, particular runtimes, etc. But key here is that the
caller NEVER
sees a struct or class, NEVER sees methods of a class, etc.

When you say that it never sees a method of a class, would it still be able to
see a global function that calls a member function of a class? What exactly is
the issue with seeing inside of structs? COM provides a way for compound data
types to be passed back and forth, do different versions of different
compilers
and different languages pack their structures differently?
***
The user sees a global function that takes a handle and possibly some other
parameters.
Whether or not that function is implemented by calling a member of a class is
invisible to
the caller, and irrelevant to their image of what is going on.

int MyGlobalFunction(HTHING thing, int somevalue)
{
CMyThing * object = (CMyThing *)thing;
return object->SomeMethod(somevalue);
}

isolates the caller from the details of the representation of CMyThing, since
it is only
unwrapped inside your code, which could look like the above.

If the user can see inside the struct, you have problems with versioning, you
have
problems of portability across programming environments, and you allow the
users to create
code that isn't really viable if you change representations.

COM uses "marshaling" to convert data from a "native" representation to an
"interchange"
representation and back again. So the representation inside can be different
from the
representation outside, but the COM interface handles all the necessary
translation
issues.
*****

I don't think that my system can tolerate this much overhead. There is no way to
pass compound data structures back and forth between calling programs and DLLs
that always works? What about if I simply pass integers, and char *, will this
always work? (If look like I might need to understand COM just to understand
every nuance of the problem).



When an application terminates, all handles are freed. So of course all
DLLs
are
released, because the process has terminated. But in that case, the concern
is
irrelevant; a DLL could not remain in memory if the only process using it is
gone.

Note that you are certainly free to prototype using your own COM simulation,
but you
should think carefully about whether or not this is an ultimately good idea.
COM is very,
very easy for a lot of environments to use, e.g., VB, C#, whereas supporting
your own
private DLL interface will make it very hard for people using these
languages.
Furthermore, if you use COM/ActiveX, then components could be written in VB
or
C# and
plugged in, which also has charm.

To be honest, if I were faced with this problem, I would dust off my old COM
manuals and
spend the effort to get up to speed in COM. Some years ago I decided that
COM/ActiveX was
basically a distraction I couldn't afford. It's not that I don't like it,
or
think it is
a Bad Idea (except when used in Web pages, where it is downright Evil), I
just
chose not
to spend time on it because it did not fit into my business model. But I
think it is an
ideal match for your business model.
joe

I am beginning to think that you are right. One benefit of COM (if nothing
else), is that if I follow all the rules of COM, the interface to my code is
guaranteed to work, it might be worth learning elemental COM just to get this
single guarantee. This same guarantee goes both ways, customers can know in
advance that it will work, too. I would estimate that spending the time to
grok
"Inside COM
(Microsoft's Component Object Model)' 1997 by Dale Rogerson, may be fruitful,
and sufficient.


On Mon, 4 Dec 2006 00:29:49 -0600, "Peter Olcott" <NoSpam@xxxxxxxxxxxxx>
wrote:


"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:6o07n21hh5l7eogdhlbelm9jqm4hnveak1@xxxxxxxxxx
Basic language objects will be the same size in most implementations (you
can't mix 32-bit
and 64-bit DLLs, but that's a different issue). Structures can be
rendered
the same if
you handle explicit packing yourself.

OTH: using std: could be dangerous, since it is not clear that all
implementations of std:
are fully interchangeable across all possible implementations of std:.

If I only use this internally to the DLL then I would estimate that this
would
not be a problem, right?


A DLL is unloaded when its reference count goes to 0. THis means if DLL A
loads DLL B,
then DLL A unloads, DLL B remains in memory until the process terminates.
This is because
if DLL A does not do an explicit FreeLibrary (and you have to be careful
what
you do in
DllMain) then as far as the OS is concerned, there is an active reference
to
DLL B. The
OS has (a) no idea that DLL A was responsible and (b) no idea that once
DLL
A
is unloaded
that no one can call DLL B again. Think "explicit reference count" and
realize that you,
and you alone, are responsible for the proper maintenace of that reference
count. So
every LoadLibrary must have a matching FreeLibrary. If you fail to
execute
a
FreeLibrary,
then the reference count remains incremented.

How will it work if executable A loads DLL B, and when executable A is done,
it
simply terminates, will DLL B be automatically unloaded?


While it is true that you can avoid the COM learning curve, it is not
clear
that the added
complexity of a custom interface can be maintained in the light of
evolution
of the
system.

Note that allocations passed across COM boundaries use the IMalloc
interface,
which means
that you aren't stuck with the issues of allocation, deallocation,
implementation
conventions for std:, and similar problems (this is why I said that COM
tends
to
discourage raw allocation). IMalloc is a universal technology for COM.

If all the allocation and deallocation is internal to the DLL, then none of
this
stuff matters, right?


For something like this where you're looking for a long-term solution, the
investment in
learning COM would likely have a high payoff.

I will probably be doing this concurrently with my development of the
working
prototype. I want to make the working prototype as functional as possible.
From
what you have told me so far, I don't see any issues. Do you see any issues?


Perhaps some of the COM experts here can give you some pointers on how to
look
at subsets
of COM. If you aren't doing GUI components, a lot of the COM complexity
tends
to
disappear. Don't dismiss it too soon. You'll end up, over time, spending
a
lot more time
building a custom interface, and give you the opportunity to paint
yourself
into a corner
where you hit some intrinsic limit because you didn't think of some issue
two
years before
it arises. COM has thought out a lot of these issues already.

The problem is that .NET will soon supercede COM for things such as my
recognizer. I don't want to focus a lot of time on learning COM, when by the
time that I am done, it is obsolete.

I have to get to self-sustaining profitability on an unreasonably short
schedule. Normally if everything is ideal, it takes three years, after the
product is fully developed. I have at most one year, including development
time.
I am probably going to either have to get a partner, or sell some of my
patent
rights, I am currently looking into both.

joe

On Sun, 3 Dec 2006 13:24:38 -0600, "Peter Olcott" <NoSpam@xxxxxxxxxxxxx>
wrote:


"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:fu36n2h82as6ib5v2h92hichk0oevah7bt@xxxxxxxxxx
There are additional problem.s For example, a DLL that uses the C
runtime
as
a DLL might
use the C6, C7, or C8 runtimes. This means that objects created in the
DLL
cannot be
disposed of except BY the DLL, because of heap issues. Similarly, a DLL
which
uses MFC
has the same limitation. While it is possible to have MFC42.dll,
MFC71.dll
and MFC80.dll
coexisting, they cannot exchange objects; once you get an object from a
DLL,
you must NOT
PASS IT ON to any other dll. So this can be limiting. COM tends to
discourage this sort
of behavior and therefore I still think it is your best choice for
plugins.
joe


How is your change of punctuation going? (: into ;)

Good you confirmed my suspicions. I figured this out on my drive to the
movies
last night, I work at least 80 hours a week, so I also work when time
would
be
otherwise wasted idle time.

So I am figuring that there should not be any problem with passing back
and
forth structures of integer types, or even blocks of memory containing
structures of integer types, as long as the compiler is new enough that
the
sizes of these types is consistent across language compilers. I must
remember
to
have the DLL do all the memory allocation and deallocation.

I was figuring on using std::vector for memory management and either
passing
back the address of the first element of this std::vector, and its length
to
the
caller, or only pass back one element at a time, as needed. I am also
assuming
that the DLL is automatically unloaded as soon as its caller is unloaded,
is
this correct or do I have to tell the DLL to unload?

Also as long as the language understands conventional DLL files, I would
also
assume that it could execute any function contained in this DLL. If this
is
the
case then I can create my system as a conventional DLL, and can skip the
COM
learning curve. This will save me months of development time.

On Sun, 3 Dec 2006 09:33:59 -0600, "Peter Olcott" <NoSpam@xxxxxxxxxxxxx>
wrote:


"Ajay Kalra" <ajaykalra@xxxxxxxxx> wrote in message
news:1165156423.277959.302780@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
What about VB's inability to handle unsigned integer types? Is there
any
way
around this that you can conceive?

We used COM and there was no problem. I dont know what types VB does
or
does not support. COM makes it all uniform.

---
Ajay

I was hoping to avoid the COM learning curve. I will research this
further.
I
think that I might be able to achieve most of my goals with a regular
(Non
COM)
DLL.

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm


.

Relevant Pages

  • Re: Linking DLLs across different compilers and languages
    ... caller calls you with HTHINGs, but the caller can never "open up" an HTHING to ... private DLL interface will make it very hard for people using these languages. ... then DLL A unloads, DLL B remains in memory until the process terminates. ... While it is true that you can avoid the COM learning curve, ...
    (microsoft.public.vc.mfc)
  • Re: Linking DLLs across different compilers and languages
    ... caller calls you with HTHINGs, but the caller can never "open up" an HTHING to ... private DLL interface will make it very hard for people using these languages. ... then DLL A unloads, DLL B remains in memory until the process terminates. ... While it is true that you can avoid the COM learning curve, ...
    (microsoft.public.vc.mfc)
  • Re: RosAsm, F2 wont work with DLL
    ... I start RosAsm by double clicking RosAsm2035d.exe, ... Automatic, from earlier analyses. ... I then press F2, which should ask me for the caller process, but ... This is for testing a bit of what the DLL does and the validity ...
    (alt.lang.asm)
  • Re: RosAsm - exports issue with some DLLs
    ... The DLLScanner is a simple toy for viewing the Exports of a DLL. ... push Address ... way, but to go and see, in the caller, what these things are. ... a pointer to a pointer, you are in the ++ hell... ...
    (alt.lang.asm)
  • Re: Linking DLLs across different compilers and languages
    ... caller calls you with HTHINGs, but the caller can never "open up" an HTHING to look inside ... That is done solely within your DLL. ... then DLL A unloads, DLL B remains in memory until the process terminates. ... that you aren't stuck with the issues of allocation, deallocation, ...
    (microsoft.public.vc.mfc)