Hi The catch with prime numbers is that to this day there's no algorithm that will find them all in any given interval without resorting to any form of trial and error or anyway without making any comparison against a set of pregress data. Unbelievable as it sounds, that's the current truth. Should you discover such an algorithm it'd earn you both a Nobel and a very fat place in hystory, hands down. Keep trying and keep hoping ; )

I suppose there's no COM expert around right now :) By the way: *bump* I still need help on this. Thanks.

To elaborate on Alan's suggestion... Let's take a big power of 2, such as: 2 ^ 2000 We first re-express it using a power of 10: 10 ^ (2000 * log10 (2)) Which yields: 10 ^ 602.05999132796239042747778944899 But we want it re-expressed in the more useful form of: man * 10^exp, the scientific notation (just in case). We know that x^(a+b) == (x^a) * (x^b), where x=10 and (conveniently) a and b can be the integer and the fractional parts of 602.05999132796239042747778944899 In other words: 10 ^ (602 + 0.05999132796239042747778944899) == (10 ^ 602) * (10 ^ 0.05999132796239042747778944899) We can rearrange it in: 10 ^ 0.05999132796239042747778944899 * 10 ^ 602 Which yields: 1.1481306952742545242328332011881 * 10 ^ 602 And that's the result of 2 ^ 2000: 1.1481306952742545242328332011881e+602 You may calculate this with fixed math, but you won't get as many ULPs and it'll take more time. Either way you're going to get an approximation of the sought value. The above also works with smaller powers. A quick demonstration for: 5^3 = 125 Here: 5^3 = 10 ^ (3 * log10 (5)) 5^3 = 10 ^ 2.0969100130080564143587833158265 5^3 = 10 ^ (2 + 0.0969100130080564143587833158265) 5^3 = (10 ^ 2) * (10 ^ 0.0969100130080564143587833158265) 5^3 = 10 ^ 0.0969100130080564143587833158265 * 10 ^ 2 5^3 = 1.2499999999999999999999999999985 * 10 ^ 2 5^3 = 1.2499999999999999999999999999985e+2 If we account for the rounding error it becomes familiar: 5^3 = 1.25e+2 5^3 = 125 [edited to improve explanation]

Using C++ I want to discover which interfaces can be obtained from calls to QueryInterface() off a given COM interface I didn't write in the first place. This old and brief CodeProject article seemed to provide a solution: How to find the name for interfaces implemented by a COM object[^] But its code fails to find interfaces that I know to be supported for sure. I have only superficial knowledge of COM and could use the advice of experts. Thanks in advance.

*reading* Hmm. Looks like that, to program today, one has to have the knack of the lawyer as well. Can't do this, Don't do that, But this is okay if, Unless, Just watch for, ... :) Jokes aside, now. It would appear that pretty much anything coming not from kernel32 is not to be invoked from anywhere/anystage_of DllMain(). And even so, some kernel functions directly/indirectly cause the loading of more libraries... which is another taboo. Fine. I'm developing for WinXP 32bit. That's the oldest platform I target. In my case my best option is to resort to the APC mechanism. For example the SetWaitableTimer() (exported by kernel32.dll) can be safely called from DllMain(), and *it* can invoke an APC function on completion (completion which can occur 1) immediately, and 2) autonomously - no need for external inputs). It's perfect. Once inside the APC function -> I can do anything I want. I should be on the right track this time ;) But I'll try this out tomorrow. Must sleep now. Thank you very much for the informative links :thumbsup: (vote: 4) Feel free to add anything else you think might help. A good night to you.

Thanks. I'm unaware of specific limitations to observe or -in general- 'good conducts' to keep while inside DllMain(). I'll trust your input, and seek documentation about it later. As for the immediate... ... since the main process' thread is kept suspended and I alone decide when to let it run... ... would it be safe to CreateThread() from inside DllMain() and move all my code in there? Or is CreateThread() another bad practice when in the context of DllMain()? If you know better alternatives I'll listen. Thank you again for the help.

First time on this forum. Hello :) I wish my first post was shorter. And forgive the obscure title. It's hard to nail it short - I don't even know what the actual problem is. Here's a quick description of what happens: 1) My_exe launches a 3rd_party_exe via CreateProcess(). The main process thread is in a suspended state. 2) I WriteProcessMemory() in the 3rd_party_exe process, and copy in it an absolute path, pointing to a dll I wrote. 3) I CreateRemoteThread() to have the dll loaded. It's the trite and dull LoadLibraryA() method everybody knows. This secondary thread is created not suspended. 4) I do stuff... My_exe opens a named and synchronous pipe. My dll inside 3rd_party_exe will connect to it. My_exe writes down the pipe a path pointing to a text file. My dll inside 3rd_party_exe retrieves such path, then closes the pipe. Control is back to My_exe, which disconnects the pipe and closes the handle. No errors. Never an error. 5) My_exe now WaitForSingleObject() that the (remote) thread from point 3 gracefully comes to an end. And it always does. When that thread is done, my DllMain() has returned. I do not unload my dll from the 3rd_party_exe process. I need it to stay loaded. 6) Time to cleanup. With the remote thread closed, the memory I wrote in the process is no longer needed. So I call VirtualfreeEx() to deallocate it. 7) Only now I let the main process thread run (remember? it was kept 'suspended' since CreateProcess()). 8) I do not need to wait for 3rd_party_exe to terminate. My_exe can close. I CloseHandle() the main thread handle and the process handle (from CreateProcess()), in that order. 9) End. What I described works -- *almost* always. I check for errors after every API call. When there's a problem it's VirtualFreeEx() (from point 6) reporting Access Violation (0xc0000005). The puzzling thing is that WriteProcessMemory() is always successful. You see, I wouldn't advance all the way to VirtualFreeEx() otherwise :confused: Any idea what might be causing this? I can repeat this procedure on a number of 3rd_party_exe programs. None crashes, except the one that does (lol, sorry). I thought that perhaps this crashy program is doing something special as it starts... something that prevents me from accessing my own memory (the one from