|
I would need to see the code for the thread you spawn and the code which spawns it. Do you realize that you can't just use an interface pointer created in one thread in another thread without marshaling it to the new thread? Are you performing marshalling?
Steve
|
|
|
|
|
I have just realised that that is probably what I have done wrong. At the moment I am trying to find out how to implement Marshaling. My first attempt is this
long hr = CoMarshalInterThreadInterfaceInStream(IID_IStream,NULL,&_stream);<pre>which is returning -2147024809.
|
|
|
|
|
Here's one way to do it:
------------------------
IStream *pMarshalData;
HRESULT hr = CoMarshalInterThreadInterfaceInStream(IID_IStream, pStream, &pMarshalData);
if ( SUCCEEDED(hr) )
{
// Spawn your new thread here. Pass it the pMarshalData pointer.
}
// In the spawned thread somewhere.
IStream *pStream;
HRESULT hr = CoGetInterfaceAndReleaseStream(pMarshalData, IID_IStream, reinterpret_cast<void**>(&pStream));
if ( SUCCEDED(hr) )
{
// Use pStream.
pStream->Release();
}
------------------------
The astute reader may notice that we're using "pMarshalData" in another thread without marshalling. This is OK as the object returned by this API is free threaded.
Steve
|
|
|
|
|
Using your suggestion
IStream *pMarshalData;
HRESULT hr = CoMarshalInterThreadInterfaceInStream(IID_IStream, NULL, &pMarshalData);
if ( SUCCEEDED(hr) )
{
}This is returning -2147221008.
|
|
|
|
|
That is not my suggestion. This was:
HRESULT hr = CoMarshalInterThreadInterfaceInStream(IID_IStream, pStream, &pMarshalData);
pStream is your stream. As my sample code shows you have to unmarshall at the other end before you can use your stream.
Steve
|
|
|
|
|
_stream is my stream, the only difference is that it is a class member.
-- modified at 8:17 Saturday 22nd April, 2006
Eek, sorry, I just noticed what you mean. I incorrectly pasted the wrong code snippet, the second paramater should not be NULL it should be _stream. After trying the first time I changed the paramaters a little, my appologies.
|
|
|
|
|
Problem solved, I was neglecting to call CoInitialize(). Thanks for your help.
|
|
|
|
|
Well I thought I had this working, but it seems that the CoGetInterfaceAndReleaseStream function is entering into an endless loop and not returning. This is of course causing any following code not to be executed, and later my WaitForMultipleObjects does just that and waits.
_stream = NULL;
HRESULT hr = CoGetInterfaceAndReleaseStream(_marshal,
IID_IStream, (void **)&_stream);
if ( FAILED(hr) )
{
return;
}Is it possibly related to the initial flags when opening the stream? I have tried changing them but it only leads to the stream failing to open.
|
|
|
|
|
waldermort wrote: Is it possibly related to the initial flags when opening the stream?
I'd say no.
He's something for you to try. Place the following debugging code after you spawn your thread and marshal the stream:
MSG m;
while ( GetMessage(&m, NULL, 0, 0) )
{
DispatchMessage(&m);
}
If this code stops CoGetInterfaceAndReleaseStream from hanging it is probably because your STA apartment isn't playing by the rules and running a message pump.
Steve
|
|
|
|
|
Wow, you really know your stuff. You were right adding the code after spawning the thread stopped it from hanging. So I guess my question is, why is it not playing by the rules? I thought that when COM creates an STA it also creates a message loop.
|
|
|
|
|
waldermort wrote: I thought that when COM creates an STA it also creates a message loop
You created this STA - it's up to you to run message loops - It can be no other way as COM has no way of knowing when it's safe to do so.
When you marshal the stream pointer to the other thread what you're really doing is setting up a communication channel from the worker thread to the main thread. When you call a stream function in the worker thread COM has to get the main thread to call into the stream object and the worker thread waits till the main thread makes the call. Once the main thread is done it sends the data to the worker thread and both continue on their merry ways. But how can COM know when it's safe to hijack the main thread and make a call into the stream on behalf of the worker thread? It's different for all the threading models but for a STA this happens when you run a message pump. To make all this happen COM needs to setup a proxy in the worker thread and a stub in the main thread. This is what COM was trying to do when your code hung. More specifically it was trying to get the main thread to do its part and setup the stub but it needs it to run a message pump.
Also, as you may see based on this description, even though you have multiple threads any call into the stream from the worker thread actually gets the main thread to do the work. You may actually lose performance. Do you really need multiple threads?
Steve
|
|
|
|
|
Stephen Hewitt wrote: Do you really need multiple threads?
The stream I am reading can be broken into 8 sections (it's a 1mb file). To read the whole stream without threading takes appx. 18 seconds. I'm hoping to increase this speed by reading each section in a thread. I have coded it in such a way that whether to use threads can be defined before the file is opened.
|
|
|
|
|
Well, I must say enabling the use of threads was a waste of 2 days. Performance went from 18 seconds to just over 30 seconds. The only alternative I can see is to copy the main stream into a buffer and split it into the individual sections. Which would a total waste of time and memory.
|
|
|
|
|
waldermort wrote: long hr =
Some advice. Use HRESULT not long.
Steve
|
|
|
|
|
In my program ,I create other top frame (it's a topest frame):
pFrame = theApp.m_pDrawDocTemplate->CreateNewFrame(this, NULL);
theApp.m_pDrawDocTemplate->SetDefaultTitle(this);
pFrame->SetParent (NULL);
theApp.m_pDrawDocTemplate->InitialUpdateFrame(pFrame, this, TRUE);
but I can't run step debug in the view of the new frame .
this is all
-- modified at 5:18 Saturday 22nd April, 2006
|
|
|
|
|
Hi Coders
I'm looking for a code obfuscator and/or an encrypter for native C++ code to make decompiling and reverse engineering more difficult. There seem to be lots of obfuscator programs for Java and .Net code but I haven't found any for C++. Are they unnecessary when using pure native code? Do you know any obfuscators for native code I should look at?
Regards
Jeremy
|
|
|
|
|
Insert the lines like "temp = temp++ - foo(temp++) - temp++;" throughout your code. Not only people, even compilers will get obfuscated by that! 
|
|
|
|
|
JSadleir wrote: I'm looking for a code obfuscator and/or an encrypter for native C++ code to make decompiling and reverse engineering more difficult. There seem to be lots of obfuscator programs for Java and .Net code but I haven't found any for C++.
Just use Boost libraries. Then your code is obfuscated automatically.
JSadleir wrote: Are they unnecessary when using pure native code? Do you know any obfuscators for native code I should look at?
When you compile your C++ source code it cannot be reconstruced like in Java and C#. In case you deliver the source code you may use a (commercial) obfuscator - especially when you need to hide poor code quality. 
-- modified at 7:08 Saturday 22nd April, 2006
Here is one commercial offering:
http://www.semanticdesigns.com/Products/Obfuscators/CppObfuscator.html?Home=CppTools[^]
|
|
|
|
|
|
You seem to be confused about what obfuscation means. Obfuscating your C++ code will not change the machine code that is generated by the compiler, only the source code used to create the program. The person reverse engineering your code would not know if you obfuscated the original code or not.
There have been methods used to attempt to defeat reverse engineering of code (at the machine code level), but the ultimate result is that your program is slower and more difficult to debug. Any one who is determined to reverse engineer your code will be able to do it, because the best you can do is make it more difficult to do it. The reason for that is that nothing is hidden at the machine level.
A sophisticated decompiler may be able to take the machine code and produce a source code file from it. The resulting code will look nothing like the original code and may not even be in the same language as the original code. It will generate variable names like 'var1' or 'intVar1', because it will not know what the variables are intended to represent, that is also true of function names.
You have no choice but to depend on people to obey the law. That does not mean that it is always illegal to reverse engineer someone else’s code (regardless of what the licenses say), it just means that you can only do it for legal reasons. To figure out how it works so you can duplicate it and make a profit is not one of the legal reasons for reverse engineering code.
INTP
Every thing is relative...
|
|
|
|
|
Thanks John - That makes it a lot clearer - Regards Jeremy
|
|
|
|
|
You are welcome! Normally I would not comment further, it is just that I am surprised that no one pointed it out before me. What I said about attempts to obfuscate code at the machine level was true. Why they even bothered mystifies me, because it is impossible on the face of it.
Now doing obfuscation for entertainment is another thing, some years ago a programming publication had a regular contest and the best one I read was a love letter. That is when you read it, you where reading a love letter. I do not remember the actual output (something to do with love), but it worked perfectly.
INTP
“Testing can show the presence of errors, but not their absence.”
Edsger Dijkstra
|
|
|
|
|
Thanks again John - I'll keep that in mind - Regards Jeremy
|
|
|
|
|
Okay, so for recent contests look here:
http://www0.us.ioccc.org/main.html[^]
People that start writing code immediately are programmers (or hackers), people that ask questions first are Software Engineers - Graham Shanks
|
|
|
|
|
Speaking seriously, you can build your application with multiple dll files and call functions across different dlls. If I remember correctly, Microsoft used a similar technique in their Win95/98 to hide undocumented functionality of their OS (some kind of dll stubs). It is usually pain in the place to reverse engineer code that makes calls to other binaries.
I am not 100% sure but I remember reading somewhere that there are ways of calling a function in dll without exporting its name, just by its binary address (offset) in the file if you know the function signature. This way a person hacking your code can't get much information from dumpbin utility and can't call your function unless he/she can guess all parameter types correctly. Which is not an easy task.
Another way is to write a code that overwrites its own binary, but then your antivirus software may start complaining about your program.
As a bottom line though, I would think that it'll create more trouble for you than to a person hacking your code. Think twice if it is worth your time.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
