Mindaugas,
And you consider it as a valid solution ?
What if I wanted to write some C extensions,
mainly to deal with so called "worker threads" ?
Or I would like to use 3-rd party dll which
uses malloc() internally ?
Come on. Be serious. You are a programmer.
I'm not sure I've understood the meaning of "worker threads", but I
think I've found the main idea of malloc(), free() solution: memory
should be allocated and freed using the same library. Dll and main exe
can have separate memory heaps.
Perhaps you did not use dynamic CRTL with those dlls in Borland.
Yes, usually I use static linking. But... do you know any popular
library project with different binary distributions for MinGW, MSVC,
BCC? Somehow zlib, Advantage Database server, MySQL, Firebird, etc is
able to by pass this problem. Or am I wrong?
Yes, you are wrong. See below what MS docs say about the problem.
I see Harbour the first one with separate .dlls.
I guess it's OK :).
Maybe it's because of its nature - virtual machine
inside .dll, maybe we should compare ourself JavaVM, or .NET... But I'm
not sure if it's unsolvable problem. I'm not saying it should be done
today, or before 1.0 Final.
From MSVC documentation :
"The msvcrt.dll is now a "known DLL," meaning that it is a system component
owned and built by Windows. It is intended for future use only by
system-level components.
If you have more than one DLL or EXE, then you may have more than one CRT,
whether or not you are using different versions of Visual C++. For example,
statically linking the CRT into multiple DLLs can present the same problem.
Developers encountering this problem with static CRTs have been instructed
to compile with /MD to use the CRT DLL. Now that the CRT DLL has been
renamed to msvcr90.dll, applications may have some components linked to
msvcrt.dll and others to msvcr90.dll. If your DLLs pass CRT resources across
the msvcrt.dll and msvcr90.dll boundary, you will encounter issues with
mismatched CRTs and need to recompile your project with Visual C++ 2008.
If your program is using more than one version of the CRT, some care is
needed when passing certain CRT objects (such as file handles, locales and
environment variables) across DLL boundaries. For more information on the
issues involved and how to resolve them, see Potential Errors Passing CRT
Objects Across DLL Boundaries."
--
Marek
----------------------------------------------------------------------
Zobacz cala prawde o Lukaszu Podolskim!
kliknij >>> http://link.interia.pl/f1e57
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
