Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe:	<mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive:	<http://sourceware.cygnus.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help:	<mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender:	cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To:	mailing list cygwin AT sourceware DOT cygnus DOT com
Message-Id:	<199911032148.PAA03301@mercury.xraylith.wisc.edu>
To:	"Daniel C. Sinclair" <uf657 AT victoria DOT tc DOT ca>
cc:	GNU-win32 <cygwin AT sourceware DOT cygnus DOT com>
Subject:	Re: mingw32 DLL getting main args?
In-Reply-To:	Your message of "Wed, 03 Nov 1999 04:30:38 PST."
	<Pine DOT GSO DOT 3 DOT 95 DOT iB1 DOT 0 DOT 991103041652 DOT 29751A-100000 AT vtn1>
Date:	Wed, 03 Nov 1999 15:48:48 -0600
From:	Mumit Khan <khan AT thor DOT xraylith DOT wisc DOT edu>

"Daniel C. Sinclair" <uf657 AT victoria DOT tc DOT 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 AT sourceware DOT cygnus DOT com

- Raw text -