Cygwin.dll crash, alloca and custom stack

[Brian Bruns]

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/