Um, I think you are still not quite right. I'm not sure though.
I don't think you can get away with #including and linking libraries, or you are in to some programming hell.
There is (are) the include file(s). You need to include this (these) to be able to use the stuff in the library, which you also need to link. The things in the library that you linked and compiled to the .exe are making the dynamic linking of the .dll files at runtime.
Am I right about this? I'm not sure.
I'm not sure how linking works either, I always thought that only the actually referenced functions (and of course the hidden, internal states, global variables) are compiled into the executable. Then the exe does the dynamic linking (the parts of the exe that were complied from the libraries which require the include files as the interfaces).
But maybe every defined (or declared? I always confuse these terms) function in the include file gets compiled? MAybe, because some libraries (DevIL for example) says you have to alter some directives to control which parts to compile.
rzzzzz. Did I get it right?
So briefly: the included and linked library does the "access on classes/flags used inside a DLL". I guess there are ways to hook into a DLL without this. Well, good luck with it....
Show differencesHistory of post edits
#5szecs
Posted 29 May 2012 - 09:26 AM
Um, I think you are still not quite right. I'm not sure though.
I don't think you can get away with #including and linking libraries, or you are in to some programming hell.
There is (are) the include file(s). You need to include this (these) to be able to use the stuff in the library, which you also need to link. The things in the library that you linked and compiled to the .exe are making the dynamic linking of the .dll files.
Am I right about this? I'm not sure.
I'm not sure how linking works either, I always thought that only the actually referenced functions (and of course the hidden, internal states, global variables) are compiled into the executable. Then the exe does the dynamic linking (the parts of the exe that were complied from the libraries which require the include files as the interfaces).
But maybe every defined (or declared? I always confuse these terms) function in the include file gets compiled? MAybe, because some libraries (DevIL for example) says you have to alter some directives to control which parts to compile.
rzzzzz. Did I get it right?
So briefly: the included and linked library does the "access on classes/flags used inside a DLL". I guess there are ways to hook into a DLL without this. Well, good luck with it....
I don't think you can get away with #including and linking libraries, or you are in to some programming hell.
There is (are) the include file(s). You need to include this (these) to be able to use the stuff in the library, which you also need to link. The things in the library that you linked and compiled to the .exe are making the dynamic linking of the .dll files.
Am I right about this? I'm not sure.
I'm not sure how linking works either, I always thought that only the actually referenced functions (and of course the hidden, internal states, global variables) are compiled into the executable. Then the exe does the dynamic linking (the parts of the exe that were complied from the libraries which require the include files as the interfaces).
But maybe every defined (or declared? I always confuse these terms) function in the include file gets compiled? MAybe, because some libraries (DevIL for example) says you have to alter some directives to control which parts to compile.
rzzzzz. Did I get it right?
So briefly: the included and linked library does the "access on classes/flags used inside a DLL". I guess there are ways to hook into a DLL without this. Well, good luck with it....
#4szecs
Posted 29 May 2012 - 09:26 AM
Um, I think you are still not quite right. I'm not sure though.
I don't think you can get away with #including and linking libraries, or you are in to some programming hell.
There is (are) the include file(s). You need to include this (these) to be able to use the stuff in the library, which you need to link. The things in the library that you linked and compiled to the .exe are making the dynamic linking of the .dll files.
Am I right about this? I'm not sure.
I'm not sure how linking works either, I always thought that only the actually referenced functions (and of course the hidden, internal states, global variables) are compiled into the executable. Then the exe does the dynamic linking (the parts of the exe that were complied from the libraries which require the include files as the interfaces).
But maybe every defined (or declared? I always confuse these terms) function in the include file gets compiled? MAybe, because some libraries (DevIL for example) says you have to alter some directives to control which parts to compile.
rzzzzz. Did I get it right?
So briefly: the included and linked library does the "access on classes/flags used inside a DLL". I guess there are ways to hook into a DLL without this. Well, good luck with it....
I don't think you can get away with #including and linking libraries, or you are in to some programming hell.
There is (are) the include file(s). You need to include this (these) to be able to use the stuff in the library, which you need to link. The things in the library that you linked and compiled to the .exe are making the dynamic linking of the .dll files.
Am I right about this? I'm not sure.
I'm not sure how linking works either, I always thought that only the actually referenced functions (and of course the hidden, internal states, global variables) are compiled into the executable. Then the exe does the dynamic linking (the parts of the exe that were complied from the libraries which require the include files as the interfaces).
But maybe every defined (or declared? I always confuse these terms) function in the include file gets compiled? MAybe, because some libraries (DevIL for example) says you have to alter some directives to control which parts to compile.
rzzzzz. Did I get it right?
So briefly: the included and linked library does the "access on classes/flags used inside a DLL". I guess there are ways to hook into a DLL without this. Well, good luck with it....
#3szecs
Posted 29 May 2012 - 09:24 AM
Um, I think you are still not quite right. I'm not sure though.
I don't think you can get away with #including and linking libraries, or you are in to some programming hell. I mean the interfaces for the dll are in the libraries most of the time, and the libraries have include files as interfaces which are also needed
There the include file. You need to include this (these) to be able to use the stuff in the library, which you need to link. The things in the library that you linked and compiled to .exe are making the dynamic linking to the .dll files.
Am I right about this? I'm not sure.
I'm not sure how linking works either, I always thought that only the actually referenced functions (and of course the hidden, internal states, global variables) are compiled into the executable. Then the exe does the dynamic linking (the parts of the exe that were complied from the libraries which require the include files as the interfaces).
But maybe every defined (or declared? I always confuse these terms) function in the include file gets compiled? MAybe, because some libraries (DevIL for example) says you have to alter some directives to control which parts to compile.
rzzzzz. Did I get it right?
So briefly: the included and linked library does the "access on classes/flags used inside a DLL". I guess there are ways to hook into a DLL without this. Well, good luck with it....
I don't think you can get away with #including and linking libraries, or you are in to some programming hell. I mean the interfaces for the dll are in the libraries most of the time, and the libraries have include files as interfaces which are also needed
There the include file. You need to include this (these) to be able to use the stuff in the library, which you need to link. The things in the library that you linked and compiled to .exe are making the dynamic linking to the .dll files.
Am I right about this? I'm not sure.
I'm not sure how linking works either, I always thought that only the actually referenced functions (and of course the hidden, internal states, global variables) are compiled into the executable. Then the exe does the dynamic linking (the parts of the exe that were complied from the libraries which require the include files as the interfaces).
But maybe every defined (or declared? I always confuse these terms) function in the include file gets compiled? MAybe, because some libraries (DevIL for example) says you have to alter some directives to control which parts to compile.
rzzzzz. Did I get it right?
So briefly: the included and linked library does the "access on classes/flags used inside a DLL". I guess there are ways to hook into a DLL without this. Well, good luck with it....
#2szecs
Posted 29 May 2012 - 09:22 AM
Um, I think you are still not quite right. I'm not sure though.
I don't think you can get away with #including and linking libraries, or you are in to some programming hell. I mean the interfaces for the dll are in the libraries most of the time, and the libraries have include files as interfaces which are also needed
There the include file. You need to include this (these) to be able to use the stuff in the library, which you need to link. The things in the library that you linked and compiled to .exe are making the dynamic linking to the .dll files.
Am I right about this? I'm not sure.
I'm not sure how linking works either, I always thought that only the actually referenced functions (and of course the hidden, internal states, global variables) are compiled into the executable. Then the exe does the dynamic linking (the parts of the exe that were complied from the libraries which require the include files as the interfaces).
But maybe every defined (or declared? I always confuse these terms) function in the include file gets compiled? MAybe, because some libraries (DevIL for example) says you have to alter some directives to control which parts to compile.
rzzzzz. Did I get it right?
I don't think you can get away with #including and linking libraries, or you are in to some programming hell. I mean the interfaces for the dll are in the libraries most of the time, and the libraries have include files as interfaces which are also needed
There the include file. You need to include this (these) to be able to use the stuff in the library, which you need to link. The things in the library that you linked and compiled to .exe are making the dynamic linking to the .dll files.
Am I right about this? I'm not sure.
I'm not sure how linking works either, I always thought that only the actually referenced functions (and of course the hidden, internal states, global variables) are compiled into the executable. Then the exe does the dynamic linking (the parts of the exe that were complied from the libraries which require the include files as the interfaces).
But maybe every defined (or declared? I always confuse these terms) function in the include file gets compiled? MAybe, because some libraries (DevIL for example) says you have to alter some directives to control which parts to compile.
rzzzzz. Did I get it right?
#1szecs
Posted 29 May 2012 - 09:19 AM
Um, I think you are still not quite right. I'm not sure though.
I don't think you can get away with #including and linking libraries, or you are in to some programming hell. I mean the interfaces for the dll are in the libraries most of the time, and the libraries have include files which are also needed
There the include file. You need to include this (these) to be able to use the stuff in the library, which you need to link. The things in the library that you linked and compiled are making the dynamic linking to the .dll files.
Am I right about this? I'm not sure.
I'm not sure how linking works either, I always thought that only the actually referenced functions (and of course the hidden, internal states, global variables) are compiled into the executable. Then the exe does the dynamic linking (the parts of the exe that were complied from the libraries which require teh include files as the interfaces)
rzzzzz. Did I get it?
I don't think you can get away with #including and linking libraries, or you are in to some programming hell. I mean the interfaces for the dll are in the libraries most of the time, and the libraries have include files which are also needed
There the include file. You need to include this (these) to be able to use the stuff in the library, which you need to link. The things in the library that you linked and compiled are making the dynamic linking to the .dll files.
Am I right about this? I'm not sure.
I'm not sure how linking works either, I always thought that only the actually referenced functions (and of course the hidden, internal states, global variables) are compiled into the executable. Then the exe does the dynamic linking (the parts of the exe that were complied from the libraries which require teh include files as the interfaces)
rzzzzz. Did I get it?