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
Date: Wed, 3 Nov 1999 04:30:38 -0800 (PST)
From: "Daniel C. Sinclair" <uf657 AT victoria DOT tc DOT ca>
X-Sender: uf657 AT vtn1
To: Mumit Khan <khan AT thor DOT xraylith DOT wisc DOT edu>
cc: GNU-win32 <cygwin AT sourceware DOT cygnus DOT com>
Subject: Re: mingw32 DLL getting main args? 
In-Reply-To: <199911012210.QAA24789@pluto.xraylith.wisc.edu>
Message-ID: <Pine.GSO.3.95.iB1.0.991103041652.29751A-100000@vtn1>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 1 Nov 1999, Mumit Khan wrote:

> I did take out the _argv and _argc code from DLL, but then I realized that
> the DLL will never be independent of the runtime, simply because there are
> calls to malloc/free within the compiler/language support library (libgcc),
> part of which is embedded in each executable and DLL.

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?

> MSVC++ does the same, and any DLL created with VC++ will also depend on
> MSVCRT.DLL. It should be easy to convince yourself of that.

I don't have Visual C++, so I can't verify. I'm going to look into the
issue further on a machine that does have it when I get a chance.

> 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.

> As for mixing runtimes, just create a DLL that depends on MSVCRT.DLL, which
> 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.

Daniel


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com