Mail Archives: cygwin/2005/08/14/11:24:31
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/
- Raw text -