I need some information about Static Library creation, Actually i was created static library with .h(header files) files, But i want to hide some .h(header files) from my library which are not visible to others. Could u please provide any solution..
Yes, there is a possibility and I have done this very recently.
Please refer this website which shows how to expose the header files.
Note: You should not import your private headers in your public headers. You'll get some compilation errors while compiling the library in other projects.
Lets assume you have two headers,
XYZ.h (public)
XYZInternal.h (private)
You have to import XYZInternal.h in XYZ.m file to avoid the header not found error and of course to hide the existence of the private header/class.
Related
If I'm reading correctly, (https://github.com/Microsoft/microsoft-pdb), pdb's contain debug information. If you were to release one to the customer alongside the exe, would it impose a risk that customers or end-users being able to find out the source code?
I'd probably think it's possible if you attach a Visual Studio to the process, I haven't tried myself but I'm fairly sure you wouldn't need the source code somewhere stuffed away in order to use the pdb to see the entry points and eventually the entire route some data would have taken.
If so, is there a way to prevent the end user to prevent doing this?
There is no way for you to prevent a user from finding out what your program does, if the user has enough knowledge.
Even without PDBs, a technique called reverse engineering could be used to find out what your program does. Programs like IDA Pro are really good at it. Programming languages like C# and Java that use an intermediate language are almost delivered in source code. Tools like dotPeek can show decompiled source code and it's unbelievable how close it is to real source code.
Regarding PDBs, there are public PDBs and private PDBs. You would usually give the public PDBs to the public (as the name suggests) and keep the private PDBs for internal debugging purposes. It's possible to convert private PDBs (which contain more information) to public PDBs using a tool called PDBCopy (use the -p parameter).
Simplified, you can think like this: public PDBs contain information about methods that have the public keyword (or equivalent, depending on your programming language), private PDBs have information about all methods (protected, internal, private and whatever keywords there are).
PDBs do not contain source code; they only contain a link to the file that was used at compile time. That way, people could figure out the local file structure of the build server, which might be considered as a security risk. IMHO, it's acceptable.
Personally I would not worry too much about giving away public PDBs. Even Microsoft does it for Windows. And you can figure out the local directory structure of Microsoft's build server ;-)
For example, the file combase.pdb (with symstore hash 10EDC6786A36FBF7D9EE585F00212CB41) contains (among others)
d:\os\obj\x86fre\onecore\com\combase\dll\objfre\i386\combase.def
onecore\base\appmodel\common\removedirectorytree.cpp
pdb not containing source code. it containing names of symbols (functions, class, global variables) and information about source file names/lines (how convert RVA to file/line) . so pdb not give to user your source code, but give say names of your source files with full path in your file system and
all internal symbol names
I use c++ on Visual studio 2008.
I am using a 3rd party library (BCG) in my application. I need to make a change to the access specifier (from protected to public) of a BCG class' member variable. The question is: is it safe to change the access specifier only in the header file, which is included in my application, without regenerating the dll file? It is possible to do it, and on the surface, it seems to work fine. However I am not sure whether it is safe.
I am trying to derive from a class used in that third party library and in order to achieve what I want, I need to access a protected variable from another class. I want to have the least damaging change (for future integration) so I want to avoid changing the dll file.
Instance member access doesn't involve any fix-up of symbols in the linker. Instead, the identity of members compiles down to offsets against the object pointer, so name-mangling and other linkage questions don't enter into it. This is why it seems to be working for you.
Modifying the headers describing classes that are published by a DLL you can't rebuild is obviously dangerous behavior, in general, so proceed with caution.
I have a statically linked library (SLL) which contains resources such as bitmaps, icons, cursors, etc. And functions in the SLL use those resources. And these exported functions are used by my executable. The problem which I was facing earlier was that the resources were not getting included in the executable while linking. However, I got that resolved thanks to another post in StackOverflow which suggested to link the generated .res file as well.
However, I wanted a cleaner solution - wherein I just link the .lib file and the resources get included as well. I did a dumpbin on the .lib file and it seems to contain all the resource data, but while linking those resources are not included in the final binary.
I suspect that lib.exe generates an output with a mangled resource section name (something like .rsrc$01 and .rsrc$02) which the linker does not recognize as a valid resource section name and hence the confusion.
There's a similar question here: VC++ resources in a static library
Seems like your options are to parse the resources so that the library itself provides access to them, or have the library 'build' the resources when it is used.
How can I turn off static checks on my Linq2Sql code?
You can suppress checks on static code by marking the class(es) in question with [ContractVerification(false)].
If your generated classes are partial you can create another file with another part(ial) in it and add it there, so it doesn't get overwritten when the code is regenerated.
How can I share source code between 2 projects in MS Visual Studio 2008 (I'm programming in C++)?
In my case, I have the code for the main game project and now I want to make a simple model editor that uses the game's code, so that whenever I change/add some code in one project it will be updated in the second one.
A common method for doing this, (you'll see it everywhere in open-source packages), is to bundle all the headers into an 'include' folder and all the source into a 'source' folder.
Now in whatever project needs the code, you go to, 'Project Properties->c/c++->General->Additional Include Directories'. Then add the path to the 'include' directory. Finally, add the source/headers to your project, now both projects reference the exact same files, which are in a nice tidy shared location.
You can also build the shared code as a static library or better yet (IMO) a DLL. This involves creating a new project, and learning a little bit about the linker in VS 2008, but really nothing too complicated. This also has the advantage (in the case of a DLL) that the two projects don't re-compile the same code, but rather it is compiled once and used twice.
You can move the required classes into a separate library project and then references this from the second project. Any changes will be automatically picked up.
(I'm not a C++ developer, however the above works for C# projects, I would assume it works for C++ projects too)
You basically have two options:
Create a static library. In this, all the code in the library will be exported and visible to who ever links to this library.
Create a DLL: here, you can define what classes and methods you would like to export and use those.
Lets say you have a class called classA which is defined in classA.h and implemented in classA.cpp and you want to use this same class from two different applications (application B and application C).
Using method 1, you would create a static library by going to file->new win32 project and in the box that pops up, choose application settings and make it a "Static Library". Then in this static library you add both your classA.h and classA.cpp.
To use this static library in application B or C, goto the references and add a reference to the static library project that you just created. then include classA.h in your application (don't forget to set the additional include directories path) and you are good to go.
The approach is very similar for a DLL as well, the difference here would be that you can choose what parts of your code in the DLL are exported (ie visible to outside callers).
From an overall point of view:
With the static library approach, your code will be compiled into both the applications.
With the DLL approach, there will be just one copy of the shared code (in the DLL which will be a separate file) and this will be loaded as required.