Hi Przemek,
I understand that, but isn't it the point of .dlls that they
provide a _common_ interface for all programs regardless of the
compiler/tools/C/C++ mode used to generate the .dll and the
user applications using it?
Probably it was an intention but not result in real life
and it's the reason why you need import libraries to link
your application with foreign .dll. It simply hides differences
in naming and calling convention. Anyhow it can be added to
application at compile time if you have necessary tool which
understand the ABI used in .dll and can create proper import
library. It cannot be resolved (at least easy) by user which
has only final binaries.
It should behave similarly to harbour.exe which, on a given
platform (win32), is perfectly equal in all respects
regardless the compiler used (mingw, bcc, msvc).
But isn't. In some compilers you can control calling and naming
convention using compiler switches but in some other it's not
possible.
I can see that, but that only means we cannot generate
our "standard" Harbour .dll using every possible compilers,
just some dedicated ones. Which is perfectly acceptable (and
just an implementation/build detail) and in fact irrelevant
from a users POVs. The point from a users POV is IMO that
there should be one and only harbour.dll, and they can use
it through some documented methods, .h and .def files in a
std way.
I mean all the .dlls I know (besides Harbour), provide one
such .dll (the most obvious example being Windows .dlls, but
I could cite all the external tools contribs use) and I can
use them equally well with all compilers and programming
languages.
I've never heard about such .dlls and I cannot imagine how it's
possible. Of course if you have some tool which can create
import library for foreign .dll then it may hide the difference
and you can succesfully link your application but for each function
you will have additional code which will translate function call
from native to forign format and of course will hide naming
differences. Anyhow it's only link time solution (though in
theory it should be possible to create intermediate .dll between
existing binaries and some forign .dll which make the same
translations and resolve the problem even for final binaries)
which causes speed overhead. Additionally there are very serious
differences in ABI used by different C compilers and it will
be hard to find necessary converters. F.e. do you know sth
what can create import libraries for OpenWatcom which by default
uses registers instead of C stack to pass some parameters?
That's not my point. We should use a calling convention for
that .dll which is supported by most compilers, meaning
'MS cdecl' for example. That's why we have the HB_EXPORT
keyword.
I'm not saying that any .c code built using any compilers'
default options should be possible to be used with any other
compilers without a hitch.
What I'm saying is that there exist such a calling
convention and naming convention used to build a .dll
which can allow most (or all) 3rd party tools to be able
to interface with it.
user32.dll f.e. is such a .dll. Creating import libraries
is a different matter, and we should or might supply those
for different compilers to help them being used, but harbour.dll
itself should be the same all across.
I understand this is more complicated to achieve for a
.dll interface (than for harbour.exe), but shouldn't we try it?
If you accept the cost and you chose preferable format which
can and should be used in all different builds (it will be
necessary to find valid converters) then you can try. But I
do not believe that people using BCC will accept using harbour.dll
in MSVC format with additional import library.
They need to use an import lib anyway (which we already supply),
why would they care about the compiler used for harbour.dll if
it works? I don't know of any .dlls I use, which compiler was
used to build them.
All I care (as a .dll user) is a .lib file which works with the
given .dll and with my compiler of choice. IMO, ideally Harbour
should supply one harbour.dll (built with whatever tool is required
to make it proper), possibly a .def file, and also possibly a
proper .lib with COFF and one in OMF format.
Is this nonsense? What am I missing?
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
