Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , 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" cc: GNU-win32 Subject: Re: mingw32 DLL getting main args? In-Reply-To: Your message of "Wed, 03 Nov 1999 04:30:38 PST." Date: Wed, 03 Nov 1999 15:48:48 -0600 From: Mumit Khan "Daniel C. Sinclair" 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