Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@sourceware.cygnus.com Delivered-To: mailing list cygwin@sourceware.cygnus.com Date: Wed, 3 Nov 1999 04:30:38 -0800 (PST) From: "Daniel C. Sinclair" X-Sender: uf657@vtn1 To: Mumit Khan cc: GNU-win32 Subject: Re: mingw32 DLL getting main args? In-Reply-To: <199911012210.QAA24789@pluto.xraylith.wisc.edu> Message-ID: 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@sourceware.cygnus.com