|
Static Library |
Posted by Florian on May-18-2010 22:30 |
|
Hello,
I'm very interested in the chart library for C++, but we need a static library. The charting library needs to run in a small agent, that is distributed to hundreds of systems. Currently, the agent can only be distributed as a single file - we cannot include additional DLLs.
This will change in the future, but for now this is not possible.
Can this be obtained if we purchase a royalty-free commercial license? Please let me know, thank you! |
Re: Static Library |
Posted by Peter Kwan on May-19-2010 02:03 |
|
Hi Florian,
Currently, we do not provide static libraries, only DLLs. The main reason is because a C++ static library are compiler dependent and compilation flags.
For example, suppose we have a static library compiled using Visual Studio 2005, in Release Mode, using multi-thread static C runtime. It can only work on projects using exactly the same compiler with exactly the same project configuration. For instance, the static library will not work with VS 2003 or VS 2008, and will not work in debug mode, or if one is using a different project configuation.
Because there are many compiler brands, versions, and everyone is using a different project configuration, so it is not practical for us to release static libraries that work with all possible or common compiler brand, versions and project configurations.
Note that even if ChartDirector is using a DLL, it is still possible to distribute an application as a single EXE file for direct execution. I have seen some EXE programs, when executed, will extract the DLLs files and the "real EXE" out from the original EXE, then run the "real EXE" automatically. When the "real EXE" ends, it will delete the DLLs and the "real EXE". To the end-user, he only see the original EXE, and will not see the "real EXE" and the DLLs. Even some programs from Microsoft are using this method, so this method should be feasible.
Hope this can help.
Regards
Peter Kwan |
Re: Static Library |
Posted by Florian on May-21-2010 23:01 |
|
Hi Peter,
Sorry for the delay.
I understand that this is possible by extracting DLLs during runtime, but we haven't done this quite yet and using a static library would simply be easier.
I did see another thread where you guys gave the same answer, I was just hoping that you were providing that upon request.
We have a different vendor that is supplying us with static libraries. I'm not sure how they are doing it, but they simply have a static library that compiles just fine with VS 2005 and 2008.
However, if you aren't receiving many requests for that then I understand that the overhead and additional work required might not be worth it.
We will look into the alternative anyways, as we might want to employ that same functionality with other DLLs as well.
Thank you. |
Re: Static Library |
Posted by Florian on Jun-05-2010 04:02 |
|
I wanted to follow up here real quick, as I have started evaluating the library.
Unfortunately, it might not be that simple. I have to admit that I didn't read your response in detail, I was thinking that you had suggested the "LoadLibrary()" approach, when in fact you were suggesting to wrap the entire exe and its DLLs.
This might not be feasible for us, since our application runs as a service. If the service control manager calls our "wrapper exe", then it would be the wrapper exe, instead of our actual service, that would be running as the service. This might not be possible, since the real service needs to report status updates back to the service control manager (SCM).
Since ChartDirector is implemented in C++, LoadLibrary() would probably be somewhat difficult, though we only need limited functionality (we would only use one type of line chart).
Has anybody used ChartDirectory via LoadLibrary() before? Is there any assistance you can provide?
Thank you! |
Re: Static Library |
Posted by Peter Kwan on Jun-07-2010 14:31 |
|
Hi Florian,
There are many methods. Some methods do not need to use LoadLibrary to load the ChartDirector DLL. The followings are some examples:
(a) If your application is a service, it would need to install itself as a service. There may be an external "installer" application. Some people will create programs that can self install (like running "wrapper.exe /install" will register the service).
In the installation stage, instead of registering the "wrapper.exe", you may extract the real program "myprogram.exe" and the ChartDirector library "chartdir50.dll", and register the "myprogram.exe" instead. The "myprogram.exe" can be linked to "chartdir50.dll" using "chartdir50.lib" (not using LoadLibrary).
One detail I have left out is how "embed" and "extract" the files in "wrapper.exe". You may embed these files as resources in the wrapper.exe. Usually people use resources to embed cursors, icons, bitmaps, dialogs, etc., but they can also be used to embed any arbitrary file. See:
http://msdn.microsoft.com/en-us/library/aa380599(VS.85).aspx
(b) Your real program can be written as a DLL "myprogram.dll", and that DLL may in turn linked to "chartdir50.dll" using "chartdir50.lib" (not using LoadLibrary).
In your executable "wrapper.exe", when it runs, it will extract "myprogram.dll" and "chartdir50.dll" out. (See (a) above on a method to embed and extract the files as resources.) It can then use LoadLibrary to load "myprogram.dll" and run it.
When the OS calls the service control functions in "wrapper.exe", it just passes through the call to "myprogram.dll". Because your "myprogram.dll" only needs a few external functions for service control, so using LoadLibrary should not be tedious.
So in summary, the "wrapper.exe" only needs to extract the files, call "LoadLibrary" to load the "myprogram.dll", and pass through all service control functions.
Alternatively, instead of using "myprogram.dll", you can use "myprogram.exe". In this case, instead of LoadLibrary, you may use CreateProcess to run the "myprogram.exe", and use "stdio redirection" to communicate the service control commands to "myprogram.exe".
Hope this can help.
Regards
Peter Kwan |
|