This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: mingw32 DLL getting main args?


"Daniel C. Sinclair" <uf657@victoria.tc.ca> writes:
> On Mon, 1 Nov 1999, Mumit Khan wrote:
> 
> My DLL imports __getmainargs() and NOTHING else. I modified dllcrt1.c,
> crt1.c, and stdlib.h so that _argc and _argv are imported directly from
> the DLL. They only get imported if I use them (which I don't). In
> dllcrt1.c there's no call to __getmainargs() and in crt1.c there is.  This
> still allows _argc/v to work properly in the EXE and the DLL. This also
> gets rid of the include"init.c" thing because I put init.c inside crt1.c.
> 
> Did you add malloc/free calls to the runtime since the last update?

The DLLs are not necessarily written in C; eg., DLLs written in C++
will include some malloc/free calls to the runtime for thread-safe
exception handling.

If you code just in C, and stay away from C RTL calls, your DLL will
be free MSVCRT or CRTDLL starting from the next release.

> > Until someone is willing to write a small memory manager just for the 
> > runtime and hence make it independent of either MSVCRT.DLL or CRTDLL.DLL,
> > I'm afraid the situation is unlikely to change.
> 
> Maybe you could just rip one out of a 'Data Structures and Algorithms'
> book.

I have no intention of doing so, sorry. I don't consider this an issue,
so unless someone contributes with proper justification, I'm not going
to pursue this further.

> > is the case for just about all native DLLs. Use the msvcrt add-on package
> > instead of the default CRTDLL one.
> 
> Does this mean that it's ok for the DLL to use MSVCRT.DLL and the EXE to
> use a static runtime or a different DLL? Watcom 10.6 will be linking
> against my DLL; I think that only had a static C runtime.

The usual caveats apply -- don't allocate memory in one and free in the
other; don't open a file in one and close in the other, and so on. It's
not a question of mixing runtimes, but rather a question of avoiding
mixing up resources owned by the different runtimes. 

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]