This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cygwin.dll crash, alloca and custom stack


On Sunday, August 14, 2005 1:47 AM [EDT], Chris wrote:
Yeah dude, you did.  You pulled the rug out from under the C runtime,
Cygwin, and apparently even the OS.  It is not within the
jurisdiction of a C program to do that.

Uh, C doesn't have a "runtime".


All major languages in use today have a runtime - C is no different. On UNIX/Linux, its mostly (if not always) called libc (glibc being the GNU variant used on most Linux systems). On Windows, its msvcrt.dll (and for newer programs built with the 1.1 .Net tools, msvcr71.dll, and 2.0 beta .Net tools, msvcrt80.dll). These shared libraries provide the interfaces, calls, etc that all C language programs need and use.

In the case of Cygwin, it provides the C runtime for applications that use it - which means you wont be using msvcrt.dll (and IIRC from discussions here, programs linked against both will either 1. crash and burn and/or 2) function in unexpected ways). I believe that issue has been covered in at least one FAQ entry.

If a binary is 100% free of dependancies (and its not done in assembly), it usually means that the runtime is statically linked with the binary (which also tends to bloat the binary up quite a bit in size). I've not seen situations like that under Windows very often (to be honest, never in my experience), since even programs written in assembly need to link with GDI.DLL, COMCTL32.DLL, WSOCK32.DLL, etc in order to provide a GUI interface through Windows or access the TCP/IP stack, or access files on the disk, and so on.. And, correct me if I am wrong, Microsoft doesn't allow you to statically link msvcrt.dll with your program. Someone was working on a open source/free software version of msvcrt.dll that was going to be a drop in replacement for the MS version - no idea how far it actually got.

Though I see static linked binaries on Linux quite a bit with commercial programs that don't provide you with the source. Easier then providing 50 builds to support every distribution in use, since every distribtuon seems to use a different version of glibc that may or may not be fully compatible with the version the program was compiled and dynamically linked against.


I am not a programmer - though I was in the past (I did Pascal on the Mac, as well as TurboPascal on DOS/Win 3.x, and earily Borland C++ on Windows 3.x). These days I just port apps from Linux to Windows using Cygwin, and I'm a Linux sysadmin. So, all my knowledge/experience on stuff like this is from what I've read on here or on the web, or from blowing up and repairing my desktop/laptop and server systems. I welcome corrections to my explanations obviously.



--
Brian Bruns
The Summit Open Source Development Group
http://www.sosdg.org / http://www.ahbl.org



-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]