On Wed, 09 Jul 2008, Szakáts Viktor wrote:
Hi Viktor,
> 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.
But it's not acceptable by me and Harbour users which have to
use 3-rd party binary libraries. As long as Harbour will depend
on C compiler and linker then droping native compiler .DLLs
will be night mare.
1-st: user will notbe able to create Harbour DLLs themself using
C compiler they have for Harbour so they will have to install
two different compilers in such case.
2-nd: he will end with binaries having two sets of C-RTLs: one used
by user code and 3-rd party binary libraries and seconds used
by harbour.dll with all other .DLLs refereed by it. It's even
possible that the same .dll libraries will be loaded by different
implib wrappers.
3-rd: The final binaries will be bigger and slower due to additional
wrapper code. And of course for full dynamic builds you will need
to have in final computers .DLLs from native C compiler and from
the one used to create for harbour.dll. I do not know how big
problem it can create in MS-Windows world and if it's it real
problem or not.
In summary it will cause that C compilers which cannot generate and
natively support "common" .dll format will have to be dropped by users
and instead of resolving some meaningless problem we will create new
very serious one.
> 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.
HB_EXPORT is only visibility attribute. It informs linker
for which symbols it should create special translation table
used by application when it loads .DLL. This attribute is
efectively used at link time. There is also IMPORT attribute
which is used only at compile time and inform compilers that
some symbols will come from .DLLs so cannot be accessed directly
but using translation table with exported symbols inside DLL.
It means that compiler cannot enable some optimizations because
in DLL format this translation table supports only direct addreses
without offsets so if you access some structure members compiler
cannot calculate the offset during compilation but has to generate
.asm code which will add it to address taken from translation table.
The code is a little bit slower but it's a must in DLL format.
And here we have yet another problem. All public structures will
need fixed alignment so we will have to force alignment switches
during compilation. Anyhow it may also not help because in some
cases even if you force the same alignment different C compilers
can calculate it differently!. It will be necessary to carefully
check all our public structure definitions and if possible make
them alignment independent changing the order of structure members
and/or adding dummy members (BTW some cleanup in public structures
which may resolve some potential alignment problem should be done
even if we will not try to create common harbour.dll)
All of the above has nothing to naming and calling conventions.
> 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.
C compilers have build-in import libraries for standard system
DLLs so you simply do not see them but they exists and are linked.
> 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 do not think that Harbour users using other compilers will accept
it. Anyhow if you really need it then you can chose one format (f.e.
MSVC one) and reserve harbour.dll name only for this format. But
please do not force other users to create slower and bigger binaries
which may also have some unpleasure side effect for MT mode when
two different C-RTLs will be linked with final binaries. F.e. some
system functions may not be MT safe and C-RTL may use some mutex
which protect their execution. This functions may be used internally
by some other ones which we use in Harbour code and which are used
by 3-rd party code. Two different C-RTLs will not know anything about
their own protection and this may cause unpredictable results.
I do not know if such situation will appear but if it will then
finding the real reason of some seldom and unexpected behavior or
GPFs will be in practice impossible.
> 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.
Not every one have to use 3-rd party .DLLs you are talking about
and AFAIK some of this libraries where recompiled bu users using
native compilers.
> 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.
1-st we should add support for direct .obj file generation and
add some simple linker. In such case you can define "suggested"
standard which will be compatible with generated .obj files and
and linker. It will also force 3-rd part developers to create
binaries in this format. Anyhow it should be still possible for
users to create native .DLLs if they like and want to use them
because the need maximum speed and minimal size.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
