|
i inject my code to .net exe file similar PE exe file. but it (.net exe file) is corrupted!!!!
Zo.Naderi-Iran
|
|
|
|
|
Hello everyone,
In COM Marshalling, if we marshall an interface from one apartment to another, then in the foreign apartment (where the interface pointer is marshalled to) the interface pointer points to the proxy object other than the original object.
My questions is, proxy object is only binding to the interface from Wnidows registry, how does the proxy object binds to the original coclass object (i.e. when we call methods in the proxy object, it is able to call the original coclass object)?
thanks in advance,
George
|
|
|
|
|
I'm not sure what you mean by "binds". If you mean how does it communicate to the real COM object then the answer is it depends:
- If the object is in a different process then PRC is used.
- If the COM object is apartment threaded and in the same process then windows messages are used.
Steve
|
|
|
|
|
Sorry for my bad English, Steve!
My question is, how could the proxy object finds which is the original coclass obejct to communicate with? Is there hard coded CLSID for the original coclass object in proxy object?
regards,
George
|
|
|
|
|
Proxy's and stubs are for interface s, not coclass es. If you look in the registry under the HKEY_CLASSES_ROOT\Interface\{Your IID} key you'll see a ProxyStubClsid32 key. In some cases you may use the CoRegisterPSClsid[^] method instead.
Steve
|
|
|
|
|
Sorry for my bad English expression, I understand proxy is for interface, not for original coclass. Suppose in the following scenario,
1. in apartment A, there is a coclass object called CA, which implements interface IA;
2. we marshall interface IA from apartment A to apartment B, and the marshalled interface is IB;
3. IB points to proxy object, say PB;
4. when we are in apartment B, and call method through IB, and PB is called and PB will communicate with original coclass object CA through interface IA.
My question is, in step 4, how could proxy object PB know which coclass object (CA in this case) it should communicate with?
regards,
George
|
|
|
|
|
It's not a matter of which coclass but rather which interface . As to how does it knows which interface it's simple, it’s the one you marshalled.
Steve
|
|
|
|
|
Thanks Steve,
I think you mean when we call from the marshalled interface, it could find the related proxy object, correct? But the actual function is executed in the original object and returned back from proxy object to client, my question is how could proxy object know which is the original coclass object which it will send call parameters to and retrive return result from?
regards,
George
|
|
|
|
|
George_George wrote: my question is how could proxy object know which is the original coclass object which it will send call parameters to and retrive return result from?
The proxy knows nothing about coclass es, all it knows about is interface es. When you marshal the interface you obviously supply a pointer to the interface to be marshalled, and you also supply its IID : this is all the information COM needs from you to hook things up.
Steve
|
|
|
|
|
Thanks Steve,
The IID is both the interface which proxy implements and also the original coclass implements.
But if we only provides the IID, how could proxy knows which original coclass implements the IID and call the original coclass?
regards,
George
|
|
|
|
|
George_George wrote: But if we only provides the IID, how could proxy knows which original coclass implements the IID and call the original coclass?
You don't just supply the IID ; as I said in my previous post you provide a pointer to the interface to be marshalled and its IID . When you have an interface pointer you don’t need to know what coclass it belongs to call its methods.
Steve
|
|
|
|
|
Thanks Steve,
During marshalling, the interface to the original coclass object is passed in, say IA, and it is marshalled to IB in the other apartment. But when we are in the other apartment to call (I agree if in the source apartment, IA knows the address of coclass object) but we are using IB, not IA in the other apartment, how could IB know where it should deliver function call to?
regards,
George
|
|
|
|
|
You marshal the interface from the apartment it "lives" in to another apartment. When doing so you pass a pointer to the interface and its IID, as mentioned previously. So you've told COM the address of the interface and the IID, and it obviously knows things such as the threading models of the source and target apartments (you tell it when initialising COM). You've told COM all it needs from you to generate a proxy which is hooked up to the right interface. I don't understand which part you're having trouble understanding.
Steve
|
|
|
|
|
Thanks Steve,
Now I understand your points. Let me confirm with you,
1. In the source apartment, the interface pointer contains address to the original coclass object;
2. The pointer to the original coclass object is marshalled, and unmarshalled to another interface in the destination apartment;
3. Since the interface to original coclass object contains address information to the original object, during unmarshalling, the unmarshalled pointer also got the address information to the original coclass object and the address information will be maintained by proxy object;
4. The proxy object knows the interface it implements (IID) and the address information of the original pointer which points to the original coclass object.
Correct understanding?
regards,
George
|
|
|
|
|
George_George wrote: 1. In the source apartment, the interface pointer contains address to the original coclass object;
Obviously calling a method on an interface pointer will affect the COM object you got it from. The phrase "address to the original coclass object" a little simplistic, but if you like to think of it this way there's no harm.
George_George wrote: 2. The pointer to the original coclass object is marshalled, and unmarshalled to another interface in the destination apartment;
Forget about coclasses: it's all about interfaces.
George_George wrote: 3. Since the interface to original coclass object contains address information to the original object, during unmarshalling, the unmarshalled pointer also got the address information to the original coclass object and the address information will be maintained by proxy object;
Again, calling a method on an interface pointer will affect the COM object you got it from. This should not come as a surprise.
George_George wrote: 4. The proxy object knows the interface it implements (IID) and the address information of the original pointer which points to the original coclass object.
Let's take the case where you marshal an interface from a single threaded apartment (A) to another single threaded apartment (B) in the same process. In this case normal window messages are used to communicate between apartments behind the scenes. When B calls a method on the proxy it’s sends a message to A. When A pumps the message it calls the function on the interface. Note that the method is called by the apartment where the object "lives" and so from that end it’s no different to a normal interface call.
Steve
|
|
|
|
|
Thanks Steve,
You made a really good sample, in your sample, my question is,
Stephen Hewitt wrote: When B calls a method on the proxy it’s sends a message to A.
How did B knows it will send a message to A? From which step B will get the information of where (to A in your sample) to send message to?
regards,
George
|
|
|
|
|
George_George wrote: How did B knows it will send a message to A? From which step B will get the information of where (to A in your sample) to send message to? [Smile]
The proxy knows how to communicate to A because A is responsible for its creation and provided all the necessary information in doing so.
Steve
|
|
|
|
|
Thanks Steve,
From your great and patient help, I think I am clear about the situation now. Let me confirm with you,
- proxy object only know how to communicate with the source interface (which is marshalled from) to the original coclass object, not knowing how to communicate with the original coclass object itself;
- since proxy object is created from the source interface (which is marshalled from), the proxy object could have information (e.g. address information) about where to contact the source interface.
regards and have a good weekend,
George
|
|
|
|
|
Hi All
How can i read USB Device Data.i want to read data which is present in USB Device.Example- Pendrive have a file vc.txt and vc5.txt and i want to read these data through VC++2005 code.So how can i do that..Plz help me
|
|
|
|
|
This may be helpful
<a href="http://www.beyondlogic.org/">interfacing</a>[<a href="http://www.beyondlogic.org/" target="_blank" title="New Window">^</a>]
|
|
|
|
|
Thx's for reply
but it is not useful for me.Sir if possibel then give me some example link or code..
Thx's in advance
|
|
|
|
|
the previous once code link to http://www.beyondlogic.org/usbnutshell/usb7.htm#PIC16F876Example[^]
or
You can first use the GetLogicalDrives API function to find which logical drives are present in a system, then use GetDriveType to determine whether a disk drive is a removable, and finally use FindFirstFile and FindNextFile to get file list in a specific remove disk. Here is sample code, hope it helps. Notice: in the sample code, It just lists all files in the root directory, if you’d like to list files in subdirectories, you can make small modifications on the code.
Code Snippet
#include<windows.h>
#include<iostream>
BOOL FileList()
{
DWORD dwDrives=GetLogicalDrives();
if(0==dwDrives)
{
return FALSE;
}
DWORD dwCount=0;
char chDriveLabel='A';
char szRootpath[5]={0,0,0,0,0};
while(dwDrives !=0)
{
if ((dwDrives & 1) != 0)
{
sprintf(szRootpath,"%c:\\",chDriveLabel);
if(DRIVE_REMOVABLE==GetDriveType(szRootpath))
{
WIN32_FIND_DATA FindFileData;
HANDLE hFind;
std::cout <<"Files in " << szRootpath << std::endl;
szRootpath[3]='*';
hFind=FindFirstFile(szRootpath,&FindFileData);
if (INVALID_HANDLE_VALUE == hFind)
{
return FALSE;
}
do
{
if (!(FindFileData.dwFileAttributes &
FILE_ATTRIBUTE_DIRECTORY))
{
std::cout << FindFileData.cFileName << ":";
}
}while (FindNextFile(hFind, &FindFileData) != 0);
FindClose(hFind);
}
}
dwDrives = dwDrives >> 1;
chDriveLabel++;
}
}
For detail information of GetLogicalDrives, you can refer to
http://msdn2.microsoft.com/en-us/library/aa364972.aspx
For detail information of GetDriveType, you can refer to
http://msdn2.microsoft.com/en-us/library/aa364939.aspx
For detail information of FindFirstFile, you can refer to
http://msdn2.microsoft.com/en-us/library/aa364418.aspx
For detail information of FindNextFile, you can refer to
http://msdn2.microsoft.com/en-us/library/aa364428(VS.85).aspx
Hope this helps!
|
|
|
|
|
Thx's I am going through this..After that i will tell you..
|
|
|
|
|
Sir when i add this(BOOL FileList()) code on exiting code then i am geting two error.Error like this
[code]
(1) error C2664: 'GetDriveTypeW' : cannot convert parameter 1 from 'char [5]' to 'LPCWSTR'
(2)
rror C2664: 'FindFirstFileW' : cannot convert parameter 1 from 'char [5]' to 'LPCWSTR'
[/code]
Plz help me
|
|
|
|
|