<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
I think that is currently problematic.<BR>
<BR>
<BR>
In particular, I don't think the Modula-3 runtime -- threading and garbage collection -- likes to be called on threads that were not created with it. I am also not sure that module initializers will get called if "main" is not written in Modula-3. Again, I'm not sure.<BR>
<BR>
<BR>
I think I know how to mostly fix both of these problems, if they indeed both exist, though I think in general module initializers, like C++ static constructors, are problematic and cannot be implemented well. Modula-3 may be less problematic in a few ways -- in that the ordering is apparently guaranteed well defined or at least not circular, and, well, we may not have a legacy of calling them from DllMain, which is good and bad. DllMain is called with a lock held, giving you "free" serialization. However that also means you can't do much, without risk of deadlock, or of increasing contention (slowness) on that lock. A hybrid model might be viable, where if "main" is written in Modula-3, the initializers are all run early in main, outside the lock, but if "main" is not written in Modula-3, call the initializers from DllMain. In particular, one easy hack that comes to mind, is module initializers could see if the process's executable imports m3core.dll. If so, assume they will be called, else, not. Similar but less code is to export something from Modula-3 executables, a dummy marker, IAmWrittenWithModula3(), have the module initializers GetProcAddress and if it is not null.. (possibly something more general/extensible for the executable to "advertsize" arbitrary "properties" about itself).<BR>
<BR>
<BR>
Initializers are also problematic because they often front load stuff unnecessarily -- do variables really all have to be initialized when the module loads, or only upon first use? Granted, doing it on first use implies an overhead for every use. But doing at load time implies a possibly unnecessary overhead for loading. But also, folks that do try on-demand initialization often get it wrong (i.e. not thread safe) -- I've fixed several examples around the Modula-3 tree, and I don't have a way to systematically find them, I just happen upon them.<BR>
<BR>
<BR>
Cygwin has serious problems here too -- "main" not in something written using cygwin, leads to cygwin1.dll not being initialized easily/properly, and they seem to consider it not a problem.<BR>
<BR>
<BR>
Some folks seem to have in mind relatively monolithic apps, all written using the same toolset and using the same runtime, while in reality many many apps are dynamically composed at load-time or run-time from separately authored pieces, "plugins" and such. The best example I have found here, of a simple application, that people might think is monolithic -- all dependencies known at build time or initial launch -- but is not actually monolithic -- is notepad. If you print from notepad, printer driver ui is dynamically loaded (indirectly) by it.<BR>
<BR>
<BR>
Apart from Modula-3 and Cygwin1.dll, most .dlls handle their own initialization in their DllMain, and do not depend on their client to initialize them. The main counterexample is ole32.dll and its CoInitialize, which I think is kind of broken.<BR>
<BR>
Btw, this all meant to apply to NT386 and NT386MINGNU.<BR>
They follow the same basic model.<BR>
I'll look into this further, later.<BR>
<BR>
<BR>
(see also: how do I catch a Modula-3 exception in C++, or a C++ exception in Modula-3? Answer: Don't/can't. Heck, there is no interop even from one C++ implementation to another..)<BR>
<BR>
<BR>
- Jay<BR> <BR>> From: rv82@ya.ru<BR>> To: m3devel@elegosoft.com<BR>> Date: Thu, 5 Mar 2009 05:33:00 +0300<BR>> Subject: [M3devel] Building DLLs for Win32 (NT386MINGNU)<BR>> <BR>> Hello!<BR>> Tell me please, how to build DLL in Win32 for using it with non Modula-3's programs? I use NT386MINGNU version of cm3.<BR></body>
</html>