Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
As i know Windows operating system used the assembly language to interact with the hardwares.
When they did this,they could use c,c++ or any other language to the rest work.
As i know C++ header files actually call the windows api for the implementaion.
So where are header files located? Are them installed by compilers ? or they come with the operating systems?
What keyword or code do the header files use to interact with the sutable api(for example std::cout on windows,calls a function in a dll file and in linux an other)?
For example is iostream.h different on linux from windows?
And how that how they find suitable libraries?
And my last question is that,how libraries interact with assembly code?(so assembly code interacts with hardware)
TIA.
The following passage isn't meant to be any sort of complete description of how libraries, compilation processes or system calls invoking works but rather a bird-eye view of what OP asked, thus lacks several details and important passages which will have to be studied in-depth by the OP himself
By "C++ library" I assume you're referring to the C++ standard library (although the considerations here are valid for any other library as well).
The C++ standard library isn't mandatorily present on any operating system by default, it usually comes shipped with a compiler installation or with a secondary package. That doesn't mean you can't execute C++ compiled routines, you just need headers and the library in order to compile your programs along with a compiler which supports it.
The C++ standard library is usually compiled platform-specific and you can't just copy the headers and lib files from one operating system to another one (you'll end up in tears).
Everytime you import the declarations from a header file with something like
#include <iostream>
you're rendering your program aware of the moltitude of data structures, functions and classes provided by the standard library. You can use them as you want as long as you provide the .lib file (in a Windows environment) where the code of the routines is usually defined (in Visual Studio this is usually referred as the Runtime Library with /MT /MD options) for linking.
Once you've linked your executable against those .lib files, you have a compiled executable which, opened in a disassembler, might have something like (for a simple hello world, snippet from here - not a windows environment)
mov edx,len ;message length
mov ecx,msg ;message to write
mov ebx,1 ;file descriptor (stdout)
mov eax,4 ;system call number (sys_write)
int 0x80 ;call kernel
thus eventually every C++ function or routine provided by the standard library either implements an algorithm and/or eventually call some operating-system specific routines through System Calls. There are several design and implementation differences between the various operating systems (and even the boundaries of the system call points) in addition to a thousand of layers for security checking (not to mention ring3/ring0 switches) so I won't spend more words here about that.
You may try to install the Windows SDK and check the %PROGRAMFILES%\Microsoft SDKs\Windows directory.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
I want to learn the source code of floor() in c Function library, so I use the Vs quick lookup definition function to find in VS, and then
I find that _Check_return_ _ACRTIMP double __cdecl floor(_In_ double _X); statement。
I don't know what to do next.enter image description here
Because there seems to be only a macro definition, no function definition。
Is it that I should not use the IDE to view the source code, I am a newbie。
In general, for C, no.
C code can be shipped in pre-compiled form, when you get:
A header file (mylibrary.h) that provides declarations of contents of a particular module of code.
A library (mylibrary.lib, mylibrary.dll, mylibrary.so and so on, depending on the exact type of library and the platform), this contains the code and data that are needed for the module.
These two files are enough; the compiler reads the header when you #include it in your code, and the linker "glues in" the necessary code and data from the library.
Note that there is no source code available.
The floor() function is part of the C runtime library and shipped with the compiler implementation; I'm not sure whether Microsoft provides the source for theirs. Of course there are open source implementations, here is the code from the "musl" implementation of the C standard library, for instance.
Most library functions are visible to your project just as prototypes, as they have been already compiled into a static (or dynamic) library. As far as functionality is concerned, the compiler could ship without those sources, as they are not necessary to compile your program. It's pretty much the same e.g. for OS APIs: you invoke them all the time, but you don't have the Windows sources.
On the other hand, Visual C++ traditionally shipped with the sources of (most of) its C runtime to aid debugging; they are usually found somewhere under your VC++ installation directory.
edit better indications in this answer; thanks #Martin R for digging it out
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am currently working on a Raspberry Pi project that uses the OpenCV library, among others. The OpenCV library is quite large, and the build process for it is decently extensive. I found a script which downloads and installs the latest version of OpenCV, and following some suggestions from this question, I was able to build the library, and begin using the functions within OpenCV.
Considering the actual build process for OpenCV took considerably longer than building our project would, is it acceptable to just build the library once, as opposed to building the library each time we build our project?
While I realize this is probably personal preference, I am wondering how others handle situations similar to this.
As you probably already know, code that does not change does not need to be recompiled. This is true for executables and libraries alike.
A library is supposed to provide you addictional functionality in a neat, pre-packaged form. The difference between additional code you add to your project and a library is that the code included in a library is supposed to be in a stable state, so that once built the user will be able to use its features without any maintenance hassle; the APIs will be available and they will always work. You will be able to discard any implementation files, and just work with the header files - which provide you with the API within your code - and the library files, which contain the compiled implementation.
You are pretty much pre-compiling part of your program; a part that will also be able to be used in other projects, again without recompiling.
Note that C++ itself is an example of this: an implementation of the C++ standard library (for example libc++) is already included with your compiler, so that you are able to use the standard C++ headers without the need to recompile C++ whole every time you try a "Hello World!" program.
You can even extract libraries out of parts of your project that you feel are already completed and stable: this can allow you to reduce the time required to compile your project even though it becomes bigger. These reasons are part of why modularity is so strongly encouraged when programming.
TL; DR: Recompiling a library only once is not only acceptable, is most probably what you want to do.
It is normal to compile once and then only link the library. For that reason the compilers can detect whether there are changes in source files.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I'm getting a lot of conflicting information on how to build native Windows apps using GCC.
Basically, I want to learn Windows programming, from a familiar standpoint. I want to learn the nitty gritty of which libraries need to be included with which headers, etc etc. So I can get some idea of the underlying implementation. I feel that visual studio takes a lot of this away with what seems to be a sometimes opaque build process (it frustrates me that when I include the header the libraries are automatically linked, making it hard for me to see what is doing what)
EDIT: Thanks to Ben and Serge for pointing out the falsity of the last statement. VS does not automatically include libraries based on what headers are included, rather it links a number of default libraries, regardless of what headers are included, however only functions/classes etc. required by the translation units will end up in the final executable.
Is there a way that I can develop for Windows, using the Windows API (i.e. not libc) but using a less "user-friendly" environment?
I would preferably like to stick with GCC (MinGW etc.), but I am open to other tool chains. I just want to get under a bit of that bloat and abstraction that visual studio has.
Can I just download the windows SDK and start building using MinGW? If not, where can I get the headers and libraries I need for native development? Will it compile correctly using something like minGW?
A lot of questions!
Thanks!
SUMMARY: See Serge's very helpful answer!
Thanks to everyone for the info!
If you want to do command line builds, nothing prevents you from writing your own NMake file that describes what files get compiled with what flags and how they are all linked into their own executable.
The windows compiler is cl.exe.
The windows linker is link.exe
Visual Studio, (or its free variant Visual Studio Express) do not automatically find the library associated to a header. Simply by default, it uses a set of standard libraries. But I can tell you that as soon as you will use less standard API, you will have to declare both headers and libraries. And if you look a little deeper in the project properties, you will find the exact command line for compilation and linking phases.
You can use either MSVC tools or MingW ones, but never try to mix them ! The object formats are not compatible with each other
EDIT :
I will now describe how it works in the version I know (MSVC Express 2008). The configuration of the project is available under Project / Properties. You normaly find 2 configuration here (Debug and Release) but can always add new special build configurations via Configuration Manager. You choose the config you want to tweek (or choose All configurations to apply changes everywhere.
Under Configuration properties you find (among others) items for C/C++ (compilation phase) and Linker (link phase) with menus to tweak almost everything. Last menu is always Command line and gives the actual command line that will be used.
If you use another version, your mileage may vary, but I had always been able to find the configuration under Project / Properties on older MSVC versions ...
EDIT 2 :
Concerning the list of default libraries, they are used by the linker independantly of headers you could have used or not in your different sources. But as they are libraries and not object modules, only object modules (contained in libraries) that are actually required by the program directly or indirectly will end in the executable. I almost never used the Ignore default libraries option. Mainly when I wanted to be sure that I did not use a system library to reduce the size of the executable for a very special use case.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I've recently started trying to compile/link C++ code dynamically. Let's suppose I have an application MyApp.exe running. I want that program to load some compiled object files (.o) and do all the linking stuff. Is it possible or I need a shared library?
Is it possible
Yes.
or I need a shared library?
That's exactly what a shared library is!
Update
For a plugin system you should look into the system API functions
LoadLibrary GetProcAddress (Windows)
dlopen dlsym (Linux, *BSD, MacOS)
The recommended approach for implementing a plugin is to have exactly one function of a specific name, common to all plugin modules, exported by the plugin.
This function serves two purposes:
initializing the plugin
filling a structure of function pointers with the pointers to the plugin's functions
That way the user of the plugin gets all the plugin's symbols by only a handful of system function calls, instead of littering the code with countless calls to dlsym or GetProcAddress.
It is theoretically possible, but probably not practical. On Windows, you cannot dynamically load object (.obj) files using LoadLibrary, so you would have link the object(s) into a DLL first. This would require a linker (along with static library dependencies, etc.) compatible with the compiler used to produce the object files, knowledge of the appropriate linker flags for the objects, etc.
Generally, it makes more sense to produce needed DLLs as part of the same build process that is performing the compilation. That process is in a better position to have all the necessary tools and information.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I don't seem to understand the need of *.lib files. Let's say I have 3 *.c files:
module1.c
module2.c
module3.c
myheaders.c
In each .c file we have 2 functions. Now if I call function x in module3.c from module1.c, module1.c knows about function x by looking in myheaders.c.
So if I compile this in VS I get a shiny little portable *.exe with no *.lib file attached, so why and when does one need *.lib files?
*.lib files are for other programmers who want to use your functions in their own programs.
*.exe files are for end users who just want to run your program.
Libraries can be made from groups of related functions that have been tested. They allow you to reuse code without having to go through the compilation stage each time.
Dynamic or Shared libraries allow you to upgrade parts of your executable without recompiling the executable or altering it.
In larger projects, validation of a program is a large portion of the schedule. Libraries that have already been tested will shorten the schedule and make everybody happy.
Let's say I wrote a compiler. I implement some IO functions (in English - cout) to work on windows. If you write code, and want to compile it with my compiler, you don't want to wait on each compilation for my implementation of cout to compile. More than that, you don't care about the HOW, so you don't need the source code (witch will take up some memory). So, instead of recompiling code, you get a *.lib file with the functionality, compiled once by me, no heavy source code to take along.
When you sell someone a program you wrote to use with other programs, you (usually) don't want to give him the source code - just the functionality.
If two languages share the same standard's for functions (or if the linker knows about different standards) I could write some code in one language, compile it to a *.lib, then use it with the different language. That doesn't look useful until you download some third party code written in a language you are not using.
The header files doesn't contain the function, they only contain there prototypes so the compiler know how to call them. In the case of predefined functions, they are precompiler seperatly as .lib file which refers to (library) so to call them you will need that .lib file and the header so the compiler know how to call them. when you compile using VS or any compiler, there is another process called the linking which links these files as a single executble.
Because library can be use in a lot of programs.
Your header file is necessary only for your prof
Good Question.
*.exe stands for executable. This executable could be used to run the program from End user or developer.
*.lib could be used when someone wants to use functions from your code.
There are two types of linking libraries. Static linking and Dynamic linking. follow this question to understand the difference between both of them.
Static linking vs dynamic linking