Hi Jules, I’m working on an application where I would need to call a certain function on each thread startup, thus I’d need some kind of hook:
void myThreadCreateHook(void)
{
// Do all kinds of nasty stuff... ;)
}
void Application::initialise(const String& commandLine)
{
Thread::setThreadCreateHook(myThreadCreateHook);
[...]
}Thoughts ?
/R
I can’t really see the point… If these threads are in your own code, you can just make them call your function directly. And if they’re not in your own code, why would you want to know when they get started…?
Let’s say ThreadPool, it creates its own ThreadPoolThread objects. Well I could call the function at start of runJob(), or run() for Thread derivates, thing is I need to do this for ALL kinds of possible thread objects. A hook would make life so much more easy. I really hate duplicating code, you know… 
Surely instead of Thread, you’d just use a base class…
[code]class ThreadWithHook : public Thread
{
virtual runHooked() = 0;
void run()
{
doHook();
runHooked();
}
};[/code]
…?
Or maybe explain the real reason why you’re trying to get all these callbacks, and maybe there’s something else we could do that’d be useful. I really don’t like the idea of a global hook for all threads, because some threads are none of your business, and finding out when they start can’t possibly be of any use.
Will all due respect, since it is my application, ALL threads are my business. But OK, this is why: An Anti-Reverse Engineering Guide - CodeProject
which would need to be called whether I create the threads explicitly or implicitly.
Hey…that’s a pretty nifty link 
Very useful link robiwan.
I really have to question this standpoint. JUCE is a library for developers of applications, and as such should not try to hide or unneccesarily complicate stuff for developers (like for instance MFC, which is a key issue why I hate MFC and consequently don’t use it). When I make an application, whether using JUCE or not, every little bit of it IS my business.
Don’t be on fire.
If your only platform is Win32, then you can easily hook ::CreateThread function itself, no need of Juce for this (and API hooking is very easy, search for my login xryl669 on codeproject for examples).
In all case, what you are asking is:
There is no anti-debugging system that works (think of people running your software in a VM running itself under a debugger, or people with a JTAG probe on a CPU, etc…). You should spend time on improving your software so it is ahead of its competitors, instead of wasting protections trick that’ll piss of your official customers, waste your precious time, and let competitors get the lead.
Maybe you took my comment about “none of your business” in the wrong way… I didn’t mean it to sound snarky, all I meant was that when I encapsulate a bunch of private code, I’m saying “this stuff is internal, leave it alone!”, and that should also include threads. Just in the same way that I’d find it odd if it was possible to attach a hook every time I create an object, I don’t like the idea that every thread I create could be messed about with by some external code that has no idea what the thread is actually designed for.
But TBH for your anti-debugging plan, surely the best way to use that would be to put your licensing/security code in a special non-debuggable thread, and leave all the others alone? That way the hackers might waste a lot of time before they notice that there’s anything funny going on, whereas if there were no visible threads at all, they’d probably figure it out straight away…
Ok, I do understand your viewpoint and I see it as valid. But I still hold the position that the choice in the end should be up to me as a developer. But maybe a thread hook is a bad example…
The idea has crossed me, and might very well be a much better approach.
Believe me I know, but it is a requirement of the application, so I have to do something to at least make it harder…
