David Hackett
David Hackett

Reputation: 235

Compiler Libraries vs. Operating System Libraries

I noticed that both my compiler (MinGW) and the Windows 8 SDK come with the same libraries, save the naming conventions (i.e. win32.lib on the Windows 8 SDK is libwin32.a in the MinGW libraries).

Upvotes: 13

Views: 1072

Answers (2)

Michael Burr
Michael Burr

Reputation: 340218

MinGW comes with its own set of SDK libraries for the simple reason that MinGW is intended to provide a freely available compiler implementation that can produce Windows programs, but the Windows SDK is not freely available in the sense that the MinGW developers want/need. Because of the license on the Microsoft Windows SDK, it is not something that can simply be distributed with the MinGW compiler. So a significant part of the MinGW development effort is a set of headers and libraries that provide the Windows SDK functionality without infringing on Microsoft's licensing terms.

A fair bit of the MinGW WinSDK is public domain (maybe even most or all of it). All of it is freely distributable open source.

There may also be compatibility issues with MinGW using MS object files and libraries, but I was surprised to find that MinGW can often link to object files and libraries produced by MS compilers (though I'm not sure if there are any guarantees that it is supported).

A related issue is that MinGW relies heavily on the msvcrt.dll C runtime DLL provided by Microsoft. But that DLL is not distributed by MinGW - it's a part of every Windows OS, so MinGW relies on it simply being present as a base OS facility.

Upvotes: 2

user541686
user541686

Reputation: 210525

There are two kinds of libraries:

  • Import libraries:
    These libraries only list where to find references to variables/functions/etc., but they don't contain the code itself.

  • "Normal" libraries (which contain object files that contain machine code):
    These libraries contain object files, which contain the actual machine code.

The libraries that ship with an operating system are generally import libraries.
The actual code, after all, is in the operating system itself; the import libraries merely tell you how to use the code provided in the operating system.
Why is this necessary? Because there is no way for a program to "discover" the libraries available on an operating system while it is running, so the program has to know what will be available when it is compiled.

Those that come with a compiler are generally code libraries; they contain code that the compiler requires (which varies depending on your particular compiler) in order to comple your program.

However, there is no single "standard format" for a library; Microsoft uses COFF, but *nix tools use ELF.
So when Microsoft ships the import libraries for a system, it only ships them in COFF format, which is great for the Visual C++ compiler -- but not so useful for other compilers.

This causes compiler vendors such as MinGW to be forced to create their own import libraries for the operating systems which they intended to target -- the purpose of these libraries is exactly the same as as those provided by the operating system vendor (such as Microsoft), but their format is different.

That's why you see seemingly similar libraries provided in multiple ways.

Upvotes: 7

Related Questions