- Forum
- Windows Programming
- Windows std c lib name?
Windows std c lib name?
Is there a name for microsofts standard c lib implementation?
Like on linux theres gnu c library
But whats the windows one called?
Like on linux theres gnu c library
But whats the windows one called?
There isn't one.
Unix was written in C and the two are quite intertwined. On Unix, the C runtime library is libc. That's pretty convenient because the leading lib on library names is implied by Unix linkers, so you just say "link with c".
GNU (Gnu is Not Unix) is a freely available alternative, but is Unix like. It uses the same system. The GNU C library is just GNU's C runtime, their equivalent of the Unix C runtime.
There isn't a Microsoft equivalent because Microsoft operating systems have a different history, they started with DOS. First of all, DOS didn't have dynamic linking, so the library name didn't matter. Second of all, they licensed Lattice C for up to version 4 of their compiler. DOS runs on the Intel 16bit segmented architecture and you can have single/multi segments for data and code, resulting in 4 different kinds of programs, each with their own C runtime libraries. Further more, the math library was split out because different versions were needed because the 8086 didn't do floating point math, there was a separate 8087 for that. So there was a math library that used the math coprocessor and there was a different one that did emulation.
And then, finally, there were loads of vendors running C compilers on DOS. Microsoft themselves used Watcom C to build their C compiler. There was Zortech, Borland, ...
Windows doesn't bother with a standard C library. The standard libraries on Windows implement the Platform SDK calls, which can be made from any language, even though they're written in C.
Unix was written in C and the two are quite intertwined. On Unix, the C runtime library is libc. That's pretty convenient because the leading lib on library names is implied by Unix linkers, so you just say "link with c".
GNU (Gnu is Not Unix) is a freely available alternative, but is Unix like. It uses the same system. The GNU C library is just GNU's C runtime, their equivalent of the Unix C runtime.
There isn't a Microsoft equivalent because Microsoft operating systems have a different history, they started with DOS. First of all, DOS didn't have dynamic linking, so the library name didn't matter. Second of all, they licensed Lattice C for up to version 4 of their compiler. DOS runs on the Intel 16bit segmented architecture and you can have single/multi segments for data and code, resulting in 4 different kinds of programs, each with their own C runtime libraries. Further more, the math library was split out because different versions were needed because the 8086 didn't do floating point math, there was a separate 8087 for that. So there was a math library that used the math coprocessor and there was a different one that did emulation.
And then, finally, there were loads of vendors running C compilers on DOS. Microsoft themselves used Watcom C to build their C compiler. There was Zortech, Borland, ...
Windows doesn't bother with a standard C library. The standard libraries on Windows implement the Platform SDK calls, which can be made from any language, even though they're written in C.
Last edited on
While it does not fully conform to any of the assorted *NIX standards...
When you build C binaries using the Microsoft C++ toolset the library that they're usually linked to is the Microsoft (Visual) C Run-Time (CRT) aka MSVCRT. You usually dynamically link to the CRT DLLs, including MSVCRT.dll
But you don't have to use the CRT; you can link to the Windows API directly (it's just harder work.)
Or you can use a different CRT, including assorted Windows ports of the GNU C library (e.g. MinGW) All the CRT libraries implement their functionality using the Windows API.
Regards, Andy
CRT Library Features
https://msdn.microsoft.com/en-us/library/abx4dbyh.aspx
When you build C binaries using the Microsoft C++ toolset the library that they're usually linked to is the Microsoft (Visual) C Run-Time (CRT) aka MSVCRT. You usually dynamically link to the CRT DLLs, including MSVCRT.dll
But you don't have to use the CRT; you can link to the Windows API directly (it's just harder work.)
Or you can use a different CRT, including assorted Windows ports of the GNU C library (e.g. MinGW) All the CRT libraries implement their functionality using the Windows API.
Regards, Andy
CRT Library Features
https://msdn.microsoft.com/en-us/library/abx4dbyh.aspx
Last edited on
Thanks for the interesting info kbw. I didn't know all that. Some of it but not all of it.
The situation with the C Runtime and Windows has been somewhat of a treacherous landscape, especially with regard to msvcrt.dll and all the versioned instances of it since the VC6 compiler.
Over the course of the past several years I've developed my own private version of the C Runtime I use. Microsoft's linker has a /nodefaultlib switch which allows for the exclusion of whatever, including the C Runtime. A lot of the C Runtime's functionality are contained within various Windows Api functiions, as kbw and Andy mentioned. That which isn't is available in msvcrt.dll, which is default loaded into every GUI Windows process (not console processes). That is is so hasn't been lost on some of us, but for Microsoft's part they take a dim view on folk's use of it....
https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273
Some of my work regarding this is here...
http://www.jose.it-berater.org/smfforum/index.php?topic=5140.0
http://www.jose.it-berater.org/smfforum/index.php?topic=5085.0
The situation with the C Runtime and Windows has been somewhat of a treacherous landscape, especially with regard to msvcrt.dll and all the versioned instances of it since the VC6 compiler.
Over the course of the past several years I've developed my own private version of the C Runtime I use. Microsoft's linker has a /nodefaultlib switch which allows for the exclusion of whatever, including the C Runtime. A lot of the C Runtime's functionality are contained within various Windows Api functiions, as kbw and Andy mentioned. That which isn't is available in msvcrt.dll, which is default loaded into every GUI Windows process (not console processes). That is is so hasn't been lost on some of us, but for Microsoft's part they take a dim view on folk's use of it....
https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273
Some of my work regarding this is here...
http://www.jose.it-berater.org/smfforum/index.php?topic=5140.0
http://www.jose.it-berater.org/smfforum/index.php?topic=5085.0
freddie1, is TCLib one of yours?
I'm familiar with LIBCTINY and how it works, but I haven't had access to Windows for some years now. There ought to be a way to exclude unused stuff from C++ programs in a more general portable way.
I'm familiar with LIBCTINY and how it works, but I haven't had access to Windows for some years now. There ought to be a way to exclude unused stuff from C++ programs in a more general portable way.
Yes, I first started out with Matt Pietrek's LIBCTINY (from MS Developer Journal circa 1997 - 98 or so), and then endeavored to add to it stuff and functionality I needed. Oh, backing up a bit.... As you know, all that goes way back into the ansi world of 32 bit. Adopting Matt's work for 64 bit was easy - I believe one parameter in his HeapAlloc() implementations of new() needed to be changed. Then next I got wide character sets working.
My first work on it involved writing code myself for the various string.h and stdio.h functions Matt Pietrek didn't provide, but which I needed. He didn't provide any floating point support, for example.
After fooling with it for about a year the startling realization I came to was that I was being ridiculous writing, for example, thousands of lines of code for my own implementation of the printf family of functions I needed. I realized everything I needed was sitting in msvcrt.dll, which, as I've said, is one of the base dlls Windows loads into every GUI process. Of course Mingw, etc, realized this a long time ago, which was the direction they took early on. As my link above makes clear, Microsoft isn't real happy about any of it, but so long as it works its OK by me.
My whole reason for doing this, being as I'm an 'old timer', is the size of binaries produced by Microsoft compilers (and now Windows ports of GNU), they simply infuriate me. I just said enough is enough, and I sunk about a year into working on all this. It worked out beyond my wildest expectations. As things stand now, using my TCLib, I can produce a 3.5 K console UNICODE Hello, World! program in Windows x64, or a 4k Windows GUI.
A great deal of my early angst on all this was how much of it I could utilize in terms of C++ coding as opposed to C. For my work I really, really need C++ for such things as String Class, dynamic multi-dimendional arrays, database objects, etc. I wouldn't say it was terribly easy, but I got everything working finally.
As things stand now, all my major work related projects involving hundreds of thousands of lines of code I now build against my TCLib. I can build major enterprise C++ applications that are only several hundred k. So I'm happy.
If you want to test it I can make it available somehow. Actually, all my work on it is at the site I gave links to. That's all about 99.9% up to date.
My first work on it involved writing code myself for the various string.h and stdio.h functions Matt Pietrek didn't provide, but which I needed. He didn't provide any floating point support, for example.
After fooling with it for about a year the startling realization I came to was that I was being ridiculous writing, for example, thousands of lines of code for my own implementation of the printf family of functions I needed. I realized everything I needed was sitting in msvcrt.dll, which, as I've said, is one of the base dlls Windows loads into every GUI process. Of course Mingw, etc, realized this a long time ago, which was the direction they took early on. As my link above makes clear, Microsoft isn't real happy about any of it, but so long as it works its OK by me.
My whole reason for doing this, being as I'm an 'old timer', is the size of binaries produced by Microsoft compilers (and now Windows ports of GNU), they simply infuriate me. I just said enough is enough, and I sunk about a year into working on all this. It worked out beyond my wildest expectations. As things stand now, using my TCLib, I can produce a 3.5 K console UNICODE Hello, World! program in Windows x64, or a 4k Windows GUI.
A great deal of my early angst on all this was how much of it I could utilize in terms of C++ coding as opposed to C. For my work I really, really need C++ for such things as String Class, dynamic multi-dimendional arrays, database objects, etc. I wouldn't say it was terribly easy, but I got everything working finally.
As things stand now, all my major work related projects involving hundreds of thousands of lines of code I now build against my TCLib. I can build major enterprise C++ applications that are only several hundred k. So I'm happy.
If you want to test it I can make it available somehow. Actually, all my work on it is at the site I gave links to. That's all about 99.9% up to date.
I've never looked into it, but I believe in the *nix world there are projects related to this, i.e., developing one's own C Runtime lib. I havn't messed with Linux in a number of years though, so I'm not familiar with those projects. At least years ago when I did play around with Linux, their binaries were rather tight. So maybe not the issue there.
There was a lot of that kind of stuff at http://www.catch22.net, but it seems to be down now.
One consequence of pulling in fat runtime libs is to enforce the claim that C++ is unsuitable for kernel work and such.
One consequence of pulling in fat runtime libs is to enforce the claim that C++ is unsuitable for kernel work and such.
if this is what you are asking, msvcrt.dll or some similar name to that is a good chunk of it. That is the microsoft visual c run time library. I don't know if that is current in winx or not, but there is probably something like it floating around. Its unclear to me what is part of visual studio and what is part of the OS -- the lines blurred a few years ago when .net came out and everyone installed the .net dlls even if not developers...
Topic archived. No new replies allowed.