Hi Marek,
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?
I have a similar opinion. Dll files are used to do function calls
from external application, and these is no restrictions on compiler
to be used to compile this external app.
Sorry guys, but it seems to me you both mix Harbour.dll
with general purpose dll libraries used by a system.
It's not the case. The problem is C standard Runtime
library. Each C compiler has its own dynamic CRTL designed
and compiled for that compiler. Harbour uses C Runtime
library extensivly. If I would like to create and use
Harbour dll which uses *dynamic C Runtime library" I will
not be able to do so - following your aproach.
And in fact I do this. My HbWxW uses Harbour dll AND
dynamic CRTL (Borland build).
Okay, that's also part of the issue. But f.e.
libcurl.dll also uses C RTL, so it depends on MSVCRT.DLL.
[ BTW, all MinGW binaries depend on MSVCRT.DLL ]
Standard ANSI C calls shouldn't be a problem, as they
should work regardless of the underlying C RTL
implementation. Then, I guess the problem may be with
compiler specific C RTL functions (?).
There was a direction way back in time, so that we
should try to use ANSI C functions or direct OS API
calls, while avoiding any C RTL specific functions.
Maybe following the above could clear up such issues,
if we really have them.
So please don't force anything based on your (not real
life) experience with dlls. Current aproach is a good
balance between "dll hell" and a "real life" requirements.
Who forces what? I was raising a potential issue/question
and we're discussing it, hopefully everybody will learn
something, but surely nobody loses anything.
Or do you want to have a "final word" again ?
Is this REALLY necessary?
Or is Harbour developers' list such a place where
questions cannot be asked about Harbour's properties,
inner workings, design considerations behind certain
moves in the past or current state, or raise any
possible issues without being faced with this comment
again and again?
Final word, yeah: Regardless of any moves made out
this discussion I think it's very important to discuss
why Harbour has harbour-b32.dll and harbour-vc.dll, when
and why should one use any one of them. These questions
are nowhere documented, and very much unclear for me
(and probably for other users downloading binaries, too),
so they would raise anyway as soon as someone would try
to use any harbour.dll at all.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
