[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: msvc*.dll versioning conflicts
- From: "Paul Moore" <p.f.moore@...>
- Date: Wed, 6 Aug 2008 12:46:45 +0100
On 06/08/2008, David Manura <firstname.lastname@example.org> wrote:
> The CRT normally defines a function that initializes the CRT and then
> calls the usual main/WinMain (in an application) or DllMain (in a DLL)
> entry point defined by the user.
> However, if you set your own entry point, then it's
> possible the CRT won't be initialized.
I believe that's what is happening here. I am writing a plugin for
JPSoft's Take Command, which I understand from the developer does NOT
use the MS C runtime (and so, would presumably not use the CRT
initialisation entry point).
My plugin is a DLL, loaded at runtime by Take Command. It in turn
loads the Lua DLL and calls Lua API functions. I don't presently take
any measures to initialise the CRT in my DLL entry point.
Maybe I need to. However, it doesn't seem to cause any issues with
msvcrt, although that may just be because the initialisation
requirements for that CRT are minimal enough that missing them doesn't
cause any visible issues.
> There's articles on the web concerning the CRT initialization process.
I'll do a search, but any specific pointers would be of great help.
Preferably to short "how to" articles so that I can get a quick
practical overview before diving deeper.
> Microsoft's behavior is fairly clear in . I was rather referring
> to Lua C extension modules (e.g. LuaZIP), any C libraries they depends
> on (e.g. zziplib), and even lua51.dll. It's currently rare in
> practice for such modules to make any claims in their documentation as
> to what extent they are safe to mixing CRTs.
True, but surely the basic safety level of not passing CRT-managed
data across DLL boundaries (don't allocate in one place and free in
another, for example) is sufficient (although maybe not necessary)?
Thanks for the reference to MS's statement though. I'll look through
it when I get some time.
> An example with comments about building a Lua C extension module with
> no CRT (as well as mixing CRTs) has been added to .
> Obviously Lua
> itself needs to link against a CRT...unless you rewrite Lua to use
> only operating system API calls (any takers? ;) ). However, there are
> likely many cases where C extension module need not link directly to
> any CRT.
Interesting. You've given me lots to read up on. Now all I have to do
is find the time :-)