As I am new to c++,I wanted know does the function/procedure/routine present within the .dll(dynamic link library) file execute faster then the normal function/procedure/routine present within the same file? or to make my code run faster whether i should use multithreads ?. kindly provide some bloggers link, if you people know please answer this.Thanks in advance.
Well, I would expect that calling a DLL function will have a little overhead, not the other way around as you suggest. According to this Overhead of DLL this overhead is very little, if any.
As you mention multithresding, I think I understand the source of your confusion. There no connection between DLLs and multithreading! DLL calls are synchronized, just as calling functions from within the executable is. If you want to execute them on a separate thread, you just create a separate thread and call the DLL function from there.
Related
I have been trying to get a callstack of the current thread to improve an existing tracing library used in our library code. I want to have file and line numbers or at the very least function/method name, just raw adresses will not do.
The problem I have is that StackWalker and other solutions based on dbghelp.h functions are not thread safe, and I randomly get crashes when using StackWalker even if I use a mutex inside my library. I also tried to use boost::stacktrace, but it would not work and boost is very unpopular in my organisation.
My goal is at first to make it work on Windows, then I would work on a linux/posix implementation which will probably be much easier. I'm not very knowledgable about win32 api, does any of you know of any Api to achive this? In the end, I'd like to make everything open source. I'd also like to make this library dead simple and small, so that anybody can use it.
Thanks!
I am working on a project that makes use of the ffmpeg library within the framework of Qt on an Intel Windows 8.1 machine. My application uses a QProcess to call the ffmpeg.exe with a list of list of arguments that works perfectly. I was just wondering if it would be more efficient to use the ffmpeg source with the C++ code and call functions directly using using libav.h?
When i use the QProcess it creates a separate thread so the rest of my program is unaffected by the process. If i was to use the functions directly from libav.h i would need to create my own QThread and run the function in that.
Any advice would be helpful.
Steve
Here is my advice, first of all I do not know if linking ffmpeg source code directly will require you to use a QThread, it is possible that ffmpeg already manages threads on his own (which would be good), I also do not know precisely if linking directly is going to be more efficient in terms of CPU and RAM.
For sure it's not going to be much more efficient; running the same code in an external process or in another thread are not so different in terms of hardware resources.
Beside that if you are looking for a better and deeper control on what is being played on screen, so for example if linking directly you think you may get some useful functions (like a fast forward or zoom in zoom out) then it could be worth a try.
Bye
I want to print the code of a function in a DLL.
I loaded the dll, I have the name of the desired function, what's next?
Thank you!
Realistically, next is getting the code. What you have in the DLL is object code -- binary code in the form ready for the processor to execute, not ready to be printed.
You can disassemble what's in the DLL. If you're comfortable working with assembly language, that may be useful, but it's definitely not the original source code (nor probably anything very close to it either). If you want to disassemble it, loading it in your program isn't (usually) a very good starting point. Try opening a VS command line and using dumpbin /disasm yourfile.dll. Be prepared for a lot of output unless the DLL in question is really tiny.
Your only option to retrieve hints about the actual implemented functionality of said function inside the DLL is to reverse engineer whatever the binary representation of assembly happens to be. What this means is that you pretty much have to use a disassembler(IDA Pro, or debugger, e.g. OllyDbg) to translate the opcodes to actual assembly mnemonics and then just work your way through it and try to understand the details of how it functions.
Note, that since it is compiled from C/C++ there is lots and lots of data lost in the process due to optimization and the nature of the process; the resulting assembly can(and probably will) seem cryptic and senseless, but it still does it's job the exact same way as the programmer programmed it in higher level language. It won't be easy. It will take time. You will need luck and nerves. But it IS doable. :)
Nothing. A DLL is compiled binary code; you can't get the source just by downloading it and knowing the name of the function.
If this was a .NET assembly, you might be able to get the source using reflection. However, you mentioned C++, so this is doubtful.
Check out this http://www.cprogramming.com/challenges/solutions/self_print.html and this Program that prints its own code? and this http://en.wikipedia.org/wiki/Quine_%28computing%29
I am not sure if it will do what you want, but i guess it may help you.
I have the location/offset of a particular function present inside an executable. Would it be possible to call such a function (while suppressing the CRT's execution of the executable's entry point, hopefully) ?
In effect, you can simulate the Windows loader, assuming you run under Windows, but the basics should be the same on any platform. See e.g. http://msdn.microsoft.com/en-us/magazine/cc301805.aspx.
Load the file into memory,
Replace all relative addresses of functions that are called by the loaded executable with the actual function addresses.
Change the memory page to "executable" (this is the difficult and platform-dependent part)
Initialize the CRT in order to, e.g., initialize static variables.
Call.
However, as the commenters point out correctly, this might only be practical as an exercise using very simple functions. There are many, many things that can go wrong if you don't manage to emulate the complete OS loader.
PS: You could also ask the Google: http://www.cultdeadcow.com/tools/pewrap.html
PPS: You may also find helpful advice in the "security" community: https://www.blackhat.com/presentations/bh-usa-07/Harbour/Whitepaper/bh-usa-07-harbour-WP.pdf
Yes, you can call it, if you will initialize all global variables which this function uses. Probably including CRT global variables. As alternative way, you can hook and replace all CRT functions that callee uses. See disassembly of that function to get right solution.
1) Take a look at the LoadLibraryEx() API. It has some flags that could be able to do all the dirty work described by Sebastian.
2) Edit the executable. Several modified bytes will do the job. Here is some documentation on the file format: http://docsrv.sco.com:507/en/topics/COFF.html
I have a system that runs like this:
main.exe runs sub.exe runs sub2.exe
and etc. and etc...
Well, would it be any faster of more efficient to change sub and sub2 to dlls?
And if it would, could someone point me in the right direction for making them dlls without changing a lot of the code?
DLL really are executables too. They comply to the PE standard which covers multiple common file extensions for windows, like .exe, .dll, .ocx...
When you start 2 executables they each get their own address space, their own memory and such. However when you load an executable and a dll, the dll is loaded into the process space of the executable so they share a lot of things.
Now depending on how your 3 executables communicate together (if they even communicate together), you might have to rewrite some code. Basically the general approach to having dlls is to simply call the dll function from inside your program. This is usually much simpler than interprocess communication
DLLs would definitely be faster than separate executables. But keeping them separate allows more flexibility and reuse (think Unix shell scripting).
This seems to be a good DLL tutorial for Win32.
As for not changing code much, I'm assuming you are just passing information to theses subs with command line arguments. In that case, just rename the main functions, export them from the DLL, and call these renamed "main" functions from the main program.
If your program (main.exe) is merely starting programs that really have nothing to with it, keep doing what you're doing. If sub.exe and sub2.exe contain functionality that main.exe would benefit from, convert them to dlls, so main.exe can call functions in them.
When it comes to efficiency, it depends on how large sub.exe and sub2.exe are. Remember that loading a dll also implies overhead.
There are several factors to take into consideration. For starters, how often do you run that sequence, and how long is the job executed by the other executables? If you do not call them very often, and the job they execute is not very short, the load time itself becomes insignificant. In that case, I'd say go with whatever fits the other needs. If, OTOH, you do call them quite a lot, I'd say make them DLLs. Load them once, and from that point onward every call is as fast as a call to a local function.
As for converting an exe to a dll - it should not be very complicated, but there are some points when working with dlls that require special care: using dllmain for initialization has some limitations a regular main doesn't have (synchronization issues); you'll have to keep in mind a dll shares the address space with the exe; CRT versions discrepencies might cause you grief and so on.
That depends on how often they are run. That if, is the tear-up/tear-down of processes is a significant cost.
Wouldn't it be safer to convert them to dll's to prevent the user from accidentally running sub1 or sub2 without main starting them?