More info in main readme
onqtam opened this issue · comments
It would be nice to explain how it actually works in the main readme without having to look through the code and perhaps explain how it compares to https://github.com/fungos/cr (or one of the many other solutions out there: http://bit.ly/runtime-compilation-alternatives )
Yes. I'll start adding some more information.
Yeah at a glance there appears to be no limitations? I'm sure there must be though :)
Related to the above, after seeing the linux version of this on reddit I've been thinking about your project off and on for a couple months. (Used to do a lot of PE stuff too, mostly dealing with stubs and obfusicating existing code) But anyway, very useful stuff. I'm not too sure exactly how much new code you're injecting with each change or if there's entire sections written, it's 7am lol forgive me.
I was wondering how much of a memory increase you see for a decent sized function or a small one per change? And how long does it usually take for the entire process to take on average? What do you think about stripping the pdb's used at first compile time for every referenced pdb to only what is referenced, writing it to a new section of the main exe? Although I guess if the changed code references something new then that wouldn't work hmm. (Mainly trying to think of ways of optimizing that process, I'd be using this in a live environment for pushing updates in realtime and pdb's suck for many reasons haha)
Not sure I understand. The PDB is only loaded once on startup to get a complete list of the applications' symbols. From then on out updates to symbols are loaded from the newly compiled OBJ files, which is fast since those need to be mapped anyway.
I see, that's good to know! What about the memory impact? Like how much of an increase in kb are we looking at per change on average per change/injection?
This very much depends on the application your are modifying and how the source code is structured there. The more code in the translation units, the larger the generated object files, the larger is the memory allocated and mapped into the executable. Projects which split there code into many source files therefore see a much lower memory impact compared to those with huge files (if you are modifying those).