Linking to cygwin1.dll and msvcrt.dll ?

Linking to cygwin1.dll and msvcrt.dll ?

[Mo DeJong]

Hi all.

I am trying to figure out how to create a .dll
that depends on cygwin1.dll and msvcrt.dll.
Here is the link time error I am currently seeing:

gcc -shared -g -o tcl84d.dll -Wl,--out-implib,libtcl84d.a 
regcomp.o regexec.o regfree.o regerror.o tclAlloc.o tclAsync.o tclBasic.o 
tclBinary.o tclCkalloc.o tclClock.o tclCmdAH.o tclCmdIL.o tclCmdMZ.o 
tclCompCmds.o tclCompExpr.o tclCompile.o tclDate.o tclEncoding.o tclEnv.o 
tclEvent.o tclExecute.o tclFCmd.o tclFileName.o tclGet.o tclHash.o 
tclHistory.o tclIndexObj.o tclInterp.o tclIO.o tclIOCmd.o tclIOGT.o 
tclIOSock.o tclIOUtil.o tclLink.o tclLiteral.o tclListObj.o tclLoad.o 
tclMain.o tclNamesp.o tclNotify.o tclObj.o tclPanic.o tclParse.o 
tclParseExpr.o tclPipe.o tclPkg.o tclPosixStr.o tclPreserve.o tclProc.o 
tclRegexp.o tclResolve.o tclResult.o tclScan.o tclStringObj.o 
tclStubInit.o tclStubLib.o tclThread.o tclThreadJoin.o tclTimer.o 
tclUtf.o tclUtil.o tclVar.o tclWin32Dll.o tclWinChan.o tclWinConsole.o 
tclWinSerial.o tclWinError.o tclWinFCmd.o tclWinFile.o tclWinInit.o 
tclWinLoad.o tclWinMtherr.o tclWinNotify.o tclWinPipe.o tclWinSock.o 
tclWinThrd.o tclWinTime.o  strftime.o tcl.res.o 

Creating library file: libtcl84d.a
tclWinThrd.o(.text+0x2e): undefined reference to `_beginthreadex'
tclWinThrd.o(.text+0xf5): undefined reference to `_endthreadex'
collect2: ld returned 1 exit status
make: *** [tcl84d.dll] Error 1


When building with the -no-cygwin, the -lmsvcrt
flag is automatically passed to the linker. Thing
is you can't just pass -lmsvcrt to Cygwin's gcc
because the libmsvcrt.a file lives in
/lib/mingw/libmsvcrt.a which is only searched
when -mno-cygwin is passed.

These calls to _beginthreadex and _endthreadex
are made instead of calling CreateThread and
ExitThread because of a problem with memory
leaks.

Any ideas how I can work around this problem?

thanks
Mo DeJong
Red Hat Inc

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Linking to cygwin1.dll and msvcrt.dll ?

[Christopher Faylor]

On Tue, Jul 17, 2001 at 12:59:46PM -0700, Mo DeJong wrote:
>I am trying to figure out how to create a .dll that depends on
>cygwin1.dll and msvcrt.dll.  Here is the link time error I am currently
>seeing:

You can't do that.  You can't mix two different runtime systems
they are mutually exclusive.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Linking to cygwin1.dll and msvcrt.dll ?

[Mumit Khan]

On Tue, 17 Jul 2001, Christopher Faylor wrote:

> On Tue, Jul 17, 2001 at 12:59:46PM -0700, Mo DeJong wrote:
> >I am trying to figure out how to create a .dll that depends on
> >cygwin1.dll and msvcrt.dll.  Here is the link time error I am currently
> >seeing:
> 
> You can't do that.  You can't mix two different runtime systems
> they are mutually exclusive.


In this particular case however, you need to replace _beginthreadex and
_endthreadex with Windows32 API "equivalents" -- Create/EndThread. Here's
the bit from my local tree, based on tcl 8.3. Caveat noted in the source.

2000-02-22  Mumit Khan  <khan@xraylith.wisc.edu>
	
	* win/tclWinThrd.c (TclpThreadCreate): Conditionalize on 
	TCL_THREADS. Add workaround for lack of _beginthreadex under 
	CRTDLL runtime. 
	(TclpThreadExit): Likewise.

Index: win/tclWinThrd.c
===================================================================
RCS file: /homes/khan/src/CVSROOT/tcl8.3.0/win/tclWinThrd.c,v
retrieving revision 1.1.1.1
retrieving revision 1.3
diff -u -3 -p -r1.1.1.1 -r1.3
--- win/tclWinThrd.c	2000/02/16 21:47:46	1.1.1.1
+++ win/tclWinThrd.c	2000/02/22 04:15:06	1.3
@@ -120,15 +120,31 @@ TclpThreadCreate(idPtr, proc, clientData
     Tcl_ThreadCreateProc proc;		/* Main() function of the thread */
     ClientData clientData;		/* The one argument to Main() */
 {
+#ifdef TCL_THREADS
     unsigned long code;
 
+#if !defined(__GNUC__) || (defined(__GNUC__) && defined(__MSVCRT__))
     code = _beginthreadex(NULL, 0, (LPTHREAD_START_ROUTINE) proc,
 		(void *)clientData, 0, (unsigned *)idPtr);
+#else
+    /* 
+     * MS CRTDLL runtime, one of two supported GCC/Mingw, does not support 
+     * the _beginthreadex and endthreadex interfaces, and we resort to using
+     * Win32 API CreateThread and ExitThread interfaces instead. A side 
+     * effect is that there is a potential resource leak after each thread 
+     * exits. 
+     */
+    code = (unsigned long) CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE) proc,
+		(DWORD *)clientData, 0, (DWORD *)idPtr);
+#endif
     if (code == 0) {
 	return TCL_ERROR;
     } else {
 	return TCL_OK;
     }
+#else
+    return TCL_ERROR;
+#endif
 }
 \f
 /*
@@ -151,7 +167,13 @@ void
 TclpThreadExit(status)
     int status;
 {
+#ifdef TCL_THREADS
+#if !defined(__GNUC__) || (defined(__GNUC__) && defined(__MSVCRT__))
     _endthreadex((DWORD)status);
+#else
+    ExitThread((DWORD)status);
+#endif
+#endif
 }
 
 \f

Regards,
Mumit



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Linking to cygwin1.dll and msvcrt.dll ?

[Corinna Vinschen]

On Tue, Jul 17, 2001 at 04:11:55PM -0500, Mumit Khan wrote:
> On Tue, 17 Jul 2001, Christopher Faylor wrote:
> 
> > On Tue, Jul 17, 2001 at 12:59:46PM -0700, Mo DeJong wrote:
> > >I am trying to figure out how to create a .dll that depends on
> > >cygwin1.dll and msvcrt.dll.  Here is the link time error I am currently
> > >seeing:
> > 
> > You can't do that.  You can't mix two different runtime systems
> > they are mutually exclusive.
> 
> 
> In this particular case however, you need to replace _beginthreadex and
> _endthreadex with Windows32 API "equivalents" -- Create/EndThread. Here's
> the bit from my local tree, based on tcl 8.3. Caveat noted in the source.
> 
> 2000-02-22  Mumit Khan  <khan@xraylith.wisc.edu>
> 	
> 	* win/tclWinThrd.c (TclpThreadCreate): Conditionalize on 
> 	TCL_THREADS. Add workaround for lack of _beginthreadex under 
> 	CRTDLL runtime. 
> 	(TclpThreadExit): Likewise.
> 
> Index: win/tclWinThrd.c
> ===================================================================
> RCS file: /homes/khan/src/CVSROOT/tcl8.3.0/win/tclWinThrd.c,v
> retrieving revision 1.1.1.1
> retrieving revision 1.3
> diff -u -3 -p -r1.1.1.1 -r1.3
> --- win/tclWinThrd.c	2000/02/16 21:47:46	1.1.1.1
> +++ win/tclWinThrd.c	2000/02/22 04:15:06	1.3
> @@ -120,15 +120,31 @@ TclpThreadCreate(idPtr, proc, clientData
>      Tcl_ThreadCreateProc proc;		/* Main() function of the thread */
>      ClientData clientData;		/* The one argument to Main() */
>  {
> +#ifdef TCL_THREADS
>      unsigned long code;
>  
> +#if !defined(__GNUC__) || (defined(__GNUC__) && defined(__MSVCRT__))
>      code = _beginthreadex(NULL, 0, (LPTHREAD_START_ROUTINE) proc,
>  		(void *)clientData, 0, (unsigned *)idPtr);
> +#else
> +    /* 
> +     * MS CRTDLL runtime, one of two supported GCC/Mingw, does not support 
> +     * the _beginthreadex and endthreadex interfaces, and we resort to using
> +     * Win32 API CreateThread and ExitThread interfaces instead. A side 
> +     * effect is that there is a potential resource leak after each thread 
> +     * exits. 
> +     */
> +    code = (unsigned long) CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE) proc,
> +		(DWORD *)clientData, 0, (DWORD *)idPtr);

I'm somehow missing a

       CloseHandle ((HANDLE)code);

at this point which at least closes the handle to the thread. Otherwise
the following from MSDN is valid:

    The thread object remains in the system until the thread has
    terminated and all handles to it have been closed through a
    call to CloseHandle.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Linking to cygwin1.dll and msvcrt.dll ?

[Mo DeJong]

On Wed, 18 Jul 2001, Corinna Vinschen wrote:

> I'm somehow missing a
> 
>        CloseHandle ((HANDLE)code);
> 
> at this point which at least closes the handle to the thread. Otherwise
> the following from MSDN is valid:
> 
>     The thread object remains in the system until the thread has
>     terminated and all handles to it have been closed through a
>     call to CloseHandle.
> 
> Corinna

That is interesting. The code variable is a local and the
pointer is not saved. Would this call to CloseHandle()
need to be done after a call to ExitThread()?

I guess I am not even sure why a call to _beginthreadex
is being made here instead of calling CreateThread.
The cvs log talks about a memory leak, perhaps this is
the leak Corinna has identified.

cheers
Mo

P.S.
Here is the patch I am currently playing with. This
is from the CVS version of Tcl at sourceforge.

Index: win/tclWinThrd.c
===================================================================
RCS file: /cvsroot/tcl/tcl/win/tclWinThrd.c,v
retrieving revision 1.12
diff -u -r1.12 tclWinThrd.c
--- win/tclWinThrd.c	2001/07/16 23:30:16	1.12
+++ win/tclWinThrd.c	2001/07/17 22:55:14
@@ -135,8 +135,15 @@
 
     EnterCriticalSection(&joinLock);
 
-    code = _beginthreadex(NULL, (unsigned) stackSize, proc, clientData, 0,
-	(unsigned *)idPtr);
+#ifdef __CYGWIN__
+    code = (unsigned long) CreateThread(NULL, (unsigned) stackSize,
+        (LPTHREAD_START_ROUTINE) proc, (LPVOID) clientData,
+        (DWORD) 0, (DWORD *)idPtr);
+#else
+    code = _beginthreadex(NULL, (unsigned) stackSize,
+        proc, (void *) clientData,
+        (unsigned) 0, (unsigned *)idPtr);
+#endif /* CYGWIN */
 
     if (code == 0) {
         LeaveCriticalSection(&joinLock);
@@ -202,7 +209,11 @@
     TclSignalExitThread (Tcl_GetCurrentThread (), status);
     LeaveCriticalSection(&joinLock);
 
+#ifdef __CYGWIN__
+    ExitThread((DWORD)status);
+#else
     _endthreadex((DWORD)status);
+#endif /* __CYGWIN__ */
 }
 
 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Linking to cygwin1.dll and msvcrt.dll ?

[Corinna Vinschen]

On Tue, Jul 17, 2001 at 04:01:06PM -0700, Mo DeJong wrote:
> On Wed, 18 Jul 2001, Corinna Vinschen wrote:
> 
> > I'm somehow missing a
> > 
> >        CloseHandle ((HANDLE)code);
> > 
> > at this point which at least closes the handle to the thread. Otherwise
> > the following from MSDN is valid:
> > 
> >     The thread object remains in the system until the thread has
> >     terminated and all handles to it have been closed through a
> >     call to CloseHandle.
> > 
> > Corinna
> 
> That is interesting. The code variable is a local and the
> pointer is not saved. Would this call to CloseHandle()
> need to be done after a call to ExitThread()?

No. After CreateThread() the thread is up and running. The
handle returned by CreateThread() is just the handle for the
parent thread to have control over the child thread. If the
parent is not further interested in controlling the child
it simply closes the handle immediately and forgets about
the child thread:

  if ((thdl = CreateThread (...)) != NULL)
    CloseHandle (thdl):

This is only possible if the thread is not started in a suspended
state, of course. Otherwise the parent would need the handle to
resume the child.

If the parent thread never closes the thread handle, the thread
is similar to a zombie process which still waists system resources
until the process exits.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Linking to cygwin1.dll and msvcrt.dll ?

[Mo DeJong]

On Wed, 18 Jul 2001, Corinna Vinschen wrote:

> > > I'm somehow missing a
> > > 
> > >        CloseHandle ((HANDLE)code);
> > > 
> > > at this point which at least closes the handle to the thread. Otherwise
> > > the following from MSDN is valid:
> > > 
> > >     The thread object remains in the system until the thread has
> > >     terminated and all handles to it have been closed through a
> > >     call to CloseHandle.
> > > 
> > > Corinna
> > 
> > That is interesting. The code variable is a local and the
> > pointer is not saved. Would this call to CloseHandle()
> > need to be done after a call to ExitThread()?
> 
> No. After CreateThread() the thread is up and running. The
> handle returned by CreateThread() is just the handle for the
> parent thread to have control over the child thread. If the
> parent is not further interested in controlling the child
> it simply closes the handle immediately and forgets about
> the child thread:
> 
>   if ((thdl = CreateThread (...)) != NULL)
>     CloseHandle (thdl):


I implemented the change you suggested and took care
of calling CloseHandle() for the handle returned by
CreateThread() or _beginthreadex(). Once the following
patch is applied to the CVS version of Tcl, it will
build with Cygwin gcc.

Index: win/tclWinThrd.c
===================================================================
RCS file: /cvsroot/tcl/tcl/win/tclWinThrd.c,v
retrieving revision 1.12
diff -u -r1.12 tclWinThrd.c
--- win/tclWinThrd.c	2001/07/16 23:30:16	1.12
+++ win/tclWinThrd.c	2001/07/19 07:15:41
@@ -131,14 +131,21 @@
     int flags;				/* Flags controlling behaviour of
 					 * the new thread */
 {
-    unsigned long code;
+    HANDLE tHandle;
 
     EnterCriticalSection(&joinLock);
 
-    code = _beginthreadex(NULL, (unsigned) stackSize, proc, clientData, 0,
-	(unsigned *)idPtr);
-
-    if (code == 0) {
+#ifdef __CYGWIN__
+    tHandle = CreateThread(NULL, (DWORD) stackSize,
+        (LPTHREAD_START_ROUTINE) proc, (LPVOID) clientData,
+        (DWORD) 0, (LPDWORD)idPtr);
+    if (tHandle == NULL) {
+#else
+    tHandle = (HANDLE) _beginthreadex(NULL, (unsigned) stackSize,
+        proc, (void *) clientData,
+        (unsigned) 0, (unsigned *)idPtr);
+    if (tHandle == 0) {
+#endif /* CYGWIN */
         LeaveCriticalSection(&joinLock);
 	return TCL_ERROR;
     } else {
@@ -146,6 +153,7 @@
 	    TclRememberJoinableThread (*idPtr);
 	}
 
+	CloseHandle(tHandle);
 	LeaveCriticalSection(&joinLock);
 	return TCL_OK;
     }
@@ -202,7 +210,11 @@
     TclSignalExitThread (Tcl_GetCurrentThread (), status);
     LeaveCriticalSection(&joinLock);
 
-    _endthreadex((DWORD)status);
+#ifdef __CYGWIN__
+    ExitThread((DWORD) status);
+#else
+    _endthreadex((unsigned) status);
+#endif /* __CYGWIN__ */
 }
 

Of course, there may still be a problem. The reason Tcl started
using _beginthreadex() instead of CreateThread() was related
to memory that would not be deallocated after a call to
ExitThread(). Here are some docs I found on the subject.

http://support.microsoft.com/support/kb/articles/q132/0/78.asp
http://www.microsoft.com/msj/0799/win32/win320799.htm
http://technology.niagarac.on.ca/courses/comp831/win32/_beginthread.htm 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_crt__beginthread.2c_._beginthreadex.asp

My question is, is this same memory leak problem going
to show up when using Cygwin's CreateThread() and
C library APIs?

Even if this is not going to be a problem, should
Cygwin provide the _beginthread, _beginthreadex,
_endthread, and _endthreadex methods to ease
porting existing apps that have already dealt
with this issue?

thanks
Mo DeJong
Red Hat Inc


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Linking to cygwin1.dll and msvcrt.dll ?

[Mumit Khan]

On Thu, 19 Jul 2001, Mo DeJong wrote:

> Of course, there may still be a problem. The reason Tcl started
> using _beginthreadex() instead of CreateThread() was related
> to memory that would not be deallocated after a call to
> ExitThread(). Here are some docs I found on the subject.
> 
> http://support.microsoft.com/support/kb/articles/q132/0/78.asp
> http://www.microsoft.com/msj/0799/win32/win320799.htm
> http://technology.niagarac.on.ca/courses/comp831/win32/_beginthread.htm 
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_crt__beginthread.2c_._beginthreadex.asp
> 
> My question is, is this same memory leak problem going
> to show up when using Cygwin's CreateThread() and
> C library APIs?

I believe the memory leak is only applicable if you're using MSVCRT
runtime, but that's not the case with Cygwin. The *ex functions close
the various handles and TLS' that are created per thread if I remember 
correctly. 

> Even if this is not going to be a problem, should
> Cygwin provide the _beginthread, _beginthreadex,
> _endthread, and _endthreadex methods to ease
> porting existing apps that have already dealt
> with this issue?

It's tempting, but IMO Cygwin should stay away from creeping feature'ism
such as this. Most of the threaded applications I see tend to use Win32
API directly, and Cygwin of course supports that just fine. Of course, we
can always have msvcrt helper/port library that can facilitate ports.

Regards,
Mumit



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Linking to cygwin1.dll and msvcrt.dll ?

[Mo DeJong]

On Fri, 20 Jul 2001, Mumit Khan wrote:

...

> > My question is, is this same memory leak problem going
> > to show up when using Cygwin's CreateThread() and
> > C library APIs?
> 
> I believe the memory leak is only applicable if you're using MSVCRT
> runtime, but that's not the case with Cygwin. The *ex functions close
> the various handles and TLS' that are created per thread if I remember 
> correctly.

The way I understood it, calling CreateThread() would not create the
TLS block and a later call to a C api function might allocate
the TLS block for you. Later on, you would call ExitThread() the
the TLS block that was allocated would not be deallocated and
the memory would leak.

> > Even if this is not going to be a problem, should
> > Cygwin provide the _beginthread, _beginthreadex,
> > _endthread, and _endthreadex methods to ease
> > porting existing apps that have already dealt
> > with this issue?
> 
> It's tempting, but IMO Cygwin should stay away from creeping feature'ism
> such as this. Most of the threaded applications I see tend to use Win32
> API directly, and Cygwin of course supports that just fine. Of course, we
> can always have msvcrt helper/port library that can facilitate ports.

If the app uses only the Win32 API then I don't think this problem
shows up. It only applies when a thread created with CreateThread()
calls C APIs. I don't even know if this is a problem in Cygwin
since as far as I know Cygwin does not implement C function is
the same way as msvcrt.dll.

I am not in a position to judge "creeping feature'ism". It is
just that these 4 *ex methods are documented and are even
suggested in the Microsoft documentation. If this memory
leak is not a problem in Cygwin, then these functions
should be really easy to implement since they would just
call the Win32 APIs.

cheers
Mo

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Spaces in User Name...

[Dave BT]

Hi

My prompt displays 

<forename> space <Surname>@ etc...
how can I config cygwin so that it acknowledges a non-spaced name?

Dave G

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Linking to cygwin1.dll and msvcrt.dll ?

[Robert Collins]

----- Original Message -----
From: "Mo DeJong" <mdejong@cygnus.com>
To: <cygwin@cygwin.com>
Sent: Sunday, July 22, 2001 7:26 AM
Subject: Re: Linking to cygwin1.dll and msvcrt.dll ?


> On Fri, 20 Jul 2001, Mumit Khan wrote:
>
> ...
>
> > > My question is, is this same memory leak problem going
> > > to show up when using Cygwin's CreateThread() and
> > > C library APIs?
> >
> > I believe the memory leak is only applicable if you're using MSVCRT
> > runtime, but that's not the case with Cygwin. The *ex functions close
> > the various handles and TLS' that are created per thread if I remember
> > correctly.
>
> The way I understood it, calling CreateThread() would not create the
> TLS block and a later call to a C api function might allocate
> the TLS block for you. Later on, you would call ExitThread() the
> the TLS block that was allocated would not be deallocated and
> the memory would leak.

I'm not sure that the emory leak referenced was the TLS area. TLS on pre
win2k had only 64 entries, which implied a static block as part of the
thread information . On 2k the TLS memory area may be reserved dynamically,
but recall that the same amount of storage is needed in all threads of the
sae process (ie if you have 3 TLS keys, storage for 3 LPTR's are neeed _per
thread_.

The way I read the MS advisory was that there C library was not native-win32
thread-safe/aware unless those acros were used.

> > It's tempting, but IMO Cygwin should stay away from creeping feature'ism
> > such as this. Most of the threaded applications I see tend to use Win32
> > API directly, and Cygwin of course supports that just fine. Of course,
we
> > can always have msvcrt helper/port library that can facilitate ports.

I like this idea - if those macro calls are needed by programs.

> If the app uses only the Win32 API then I don't think this problem
> shows up. It only applies when a thread created with CreateThread()
> calls C APIs. I don't even know if this is a problem in Cygwin
> since as far as I know Cygwin does not implement C function is
> the same way as msvcrt.dll.

Correct. We don't use the MS C library. We don't have that problem. However
the request for these calls was made on the basis that someone's program
ported to MSVC needed them if built under cygwin - which is false - they're
not needed under cygwin :].

> I am not in a position to judge "creeping feature'ism". It is
> just that these 4 *ex methods are documented and are even
> suggested in the Microsoft documentation. If this memory
> leak is not a problem in Cygwin, then these functions
> should be really easy to implement since they would just
> call the Win32 APIs.

They are suggested to work around MS's inability to write high-quality code.
The calls would be easy to implement yes, but there is no point in putting
them in *cygwin*.

Rob

> cheers
> Mo
>
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
>
>


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Linking to cygwin1.dll and msvcrt.dll ?

[Trevor Forbes]

>
> > I am not in a position to judge "creeping feature'ism". It is
> > just that these 4 *ex methods are documented and are even
> > suggested in the Microsoft documentation. If this memory
> > leak is not a problem in Cygwin, then these functions
> > should be really easy to implement since they would just
> > call the Win32 APIs.
>
> They are suggested to work around MS's inability to write high-quality
code.
> The calls would be easy to implement yes, but there is no point in putting
> them in *cygwin*.
>
> Rob
>

I agree with Mo.  What is the harm in adding "minor" functions which in the
end will help programmers, port and maintain programs more easily. Is that
not the purpose of Cygwin. Anything that reduces the addition of #ifdef
__CYGWIN__ would be a "smart" move in my humble opinion.

Trevor



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Linking to cygwin1.dll and msvcrt.dll ?

[Christopher Faylor]

On Sun, Jul 22, 2001 at 01:02:09PM +0930, Trevor Forbes wrote:
>>>I am not in a position to judge "creeping feature'ism".  It is just
>>>that these 4 *ex methods are documented and are even suggested in the
>>>Microsoft documentation.  If this memory leak is not a problem in
>>>Cygwin, then these functions should be really easy to implement since
>>>they would just call the Win32 APIs.
>>
>>They are suggested to work around MS's inability to write high-quality
>>code.  The calls would be easy to implement yes, but there is no point
>>in putting them in *cygwin*.
>
>I agree with Mo.  What is the harm in adding "minor" functions which in
>the end will help programmers, port and maintain programs more easily.
>Is that not the purpose of Cygwin.  Anything that reduces the addition
>of #ifdef __CYGWIN__ would be a "smart" move in my humble opinion.

The main purpose of cygwin is to provide a UNIX environment for Windows.
I don't see, offhand, how this applies.

I have no objections to adding a new library which provides more Microsoft
functionality but this has absolutely nothing to do with Cygwin's stated
goal.

And, in case it isn't clear, I suspect that someone is going to actually
have to write these functions and develop this library.  That's usually
the kiss of death here -- getting someone to actually do the work.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Linking to cygwin1.dll and msvcrt.dll ?

[Robert Collins]

----- Original Message -----
From: "Trevor Forbes" <trevorforbes@ozemail.com.au>
> >
> > They are suggested to work around MS's inability to write high-quality
> code.
> > The calls would be easy to implement yes, but there is no point in
putting
> > them in *cygwin*.
> >
> > Rob
> >
>
> I agree with Mo.  What is the harm in adding "minor" functions which in
the

The harm is that every added feature requires maintenance (to prevent
bitrot). If the feature is not really helpful (and we can debate the merits
of this particular feature ad nauseum) then you are adding to the
maintenance workload for few returns.

> end will help programmers, port and maintain programs more easily. Is that

These don't help porters from unix - they help folk who ported to pure win32
first, and now want cygwin support. In most cases a __CYGWIN__ won't be
needed because cygwin by default doesn't define WIN32 - thus their win32
code won't be activated.

> not the purpose of Cygwin. Anything that reduces the addition of #ifdef
> __CYGWIN__ would be a "smart" move in my humble opinion.

Sure - for porting _from unix_. IMO.


> Trevor
>

BTW: An alternative solution was suggested by Mumit - the creation of a
msvcrt compatability package that could include such macros - and wouldn't
involve creeping featurism. - I support such an approach.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Linking to cygwin1.dll and msvcrt.dll ?

[Steve Jorgensen]

How would this relate to a Cygwin app (links against cygwin1.dll) that also 
uses a native Windows DLL that probably uses msvcrt.dll (such as GTK+)?

Is this allowed or disallowed?

Sorry if this appears twice.  I messed up and can't tell if I already sent 
it

-----Original Message-----
From:	Christopher Faylor [SMTP:cgf@redhat.com]
Sent:	Tuesday, July 17, 2001 1:02 PM
To:	cygwin@cygwin.com
Subject:	Re: Linking to cygwin1.dll and msvcrt.dll ?

On Tue, Jul 17, 2001 at 12:59:46PM -0700, Mo DeJong wrote:
>I am trying to figure out how to create a .dll that depends on
>cygwin1.dll and msvcrt.dll.  Here is the link time error I am currently
>seeing:

You can't do that.  You can't mix two different runtime systems
they are mutually exclusive.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/