I'm currently attempting to developing a small application / dll that will read a remote directshow filter graph and glean information from it for display in a "now playing" style plugin or script. After a few days of reading and subsequent testing, I realized that after getting the filter graph address from the ROT I was failing to convert it from the IUnknown interface pointer to IFilterGraph until I had registered "proppage.dll" which came with Windows SDK.
So what I am asking is, is there no other way to glean any information from a remote filter graph without having to register proppage.dll?
You can't call a COM interface from another address space unless you marshall the interface pointers and parameters/return values to and from the other process. For COM, you need to register a marshalling object for each interface that you want to be able to use cross-process. The standard implementation for that is in proppage.dll.
I don't think there is a simple way to access the interface without providing marshalling. If you don't want to use proppage.dll, you can build marshalling code from the IDL files supplied with the SDK and compile that into your own app.
G
Related
I have a legacy Win32 application (WndProcs, etc) that needs to consume a COM object. With the use of a little ATL headers and some smart pointers that was a snap, however what I'm currently struggling with is how best to sink the events coming off that COM object?
My current working plan has been to build a second COM object (as a dll) that handles all the sinking and uses windows messages to communicate with the legacy application. This is "ok" but there's a lot of cruft moving messages back and forth to make the legacy application do what I want.
Is there a readily accessible way to get the Win32 legacy application to sink COM events directly vs running through the second "sinker" com object?
Before I go to far down this process I wanted to see if anyone else ran across this before and had a working solution.
Thanks!
Stumbled across this excellent write up by the always brilliant Raymond Chen.
http://blogs.msdn.com/b/oldnewthing/archive/2013/06/12/10425215.aspx
As WhozCraig indicated above, all I needed was the Interface pointer and to setup the Advise, handle the Invoke.
Nice and clean.
Thanks!
I have an application developed in VB 6.0. I don't have access to its code. This application also exposes its functionality through certain API provided in its dlls. Is there a way for me to check what methods of the API the consumers of this application's API are calling across anywhere the API is deployed. I want a C# program to just sit in that target environment and intercept the calls made to that API and report it back to my service via a service. I wont be modifying the API or the code calling the API. Is this possible in C# or would I need to go with C++?
Update
Lets say for sake of simplicity, that its a simple VB application developed in VB 6 called SimpleAPP, and it has a button that displays records in a grid. It does this by calling a component CMPA.dll with a public method GetRecords(string ID) which returns an Array of records. I have another few applications called CustomerApp.exe and AnotherCustomerApp.exe which also have a reference to CMPA.dll and they both calls this same method to get the records. Now, I want to develop a program called Interceptor.exe that will actually sit in the environment where CustomerApp and AnotherCustomerApp is deployed and will log internally which of these two applications called that CMPA dll's public method GetRecords and also log what parameter it sent in and what results were retrieved.
I had to google to find the library that was on the tip of my tongue.
That googling turned up some interesting articles: a new to me 1999 Microsoft Research article called “Intercepting and Instrumenting COM Applications” and an Microsoft Systems Journal article from january 1999 that I do remember, “Building a Lightweight COM Interception Framework”.
The library you want is probably Microsoft Detours. I have only used it from C++, not from C#, and I have only used it for intercepting calls to Windows API functions, not COM methods, so I can’t guarantee that it’s well suited. But it's not exactly rocket science to interface these two languages, if needed.
If Detours doesn’t turn out to fill your needs, then look at the articles cited. Quite possibly they resulted in some framework you can use. And otherwise they have the information you need to build your own. You might then also check out if ParkPlace ever made what you want. There was once great interest in “cross concern“ functionality, and ParcPlace did some of the most interesting research, as I recall.
I'd like to keep track of the ActiveX controls created by some process. To simplify the problem, I'd first like to monitor the current process only. I want to do this so that I can check whether any ActiveX control supports IOleWindow and if so, whether a given HWND belongs to that ActiveX control (so that I can map HWNDs to ActiveX controls).
Does anybody have experience with this? My first idea was to use API hooking to monitor CoCreateInstance invocations, but I read that this doesn't work in all cases. Some Google research revealed http://www.pocketsoap.com/sf/activation.html which talks about installing a custom class factory - how would this work?
You may find you can find out what you need to know using the UI Automation and Active Accessibility APIs:
http://msdn.microsoft.com/en-us/library/dd317978(VS.85).aspx
If you are sure you need to do this, be aware of the following. CoCreateInstance is essentially a convenience function, which wraps CoGetClassObject and IClassObject::CreateInstance.
If you are going to use that technique you will therefore have to hook CoGetClassObject too, as the process may use it directly.
And of course there is no law saying any library or DLL cannot provide it's own convenience functions which bypass the COM registry altogether. The registry itself is a convenience - if you know where the DLL is you can use LoadLibrary, GetProcAddress to find DllGetClassObject and retrieve the class object without involving the COM libraries, and indeed without the DLL being registered at all.
I ended up hooking CoCreateInstance and CoGetClassObject to track all COM objects being created.
Is there a ready-to-use API (C / C++) in Windows Mobile ecosystem that I could use to generate a GUID? I am looking for simple one-shot API to do this. If there is a need to write a whole algorithm or use some extra 3rd-party modules, I will do away without this.
Background. To display notification to the user I use SHNotificationAdd, which requires a GUID for it. Examples in MSDN and other sources show that GUID is hard-coded. However, I want to wrap the SHNotification* within a class that blends well within the overall design of my application. MSDN is very shy on details on what SHNOTIFICATIONDATA->clsid represents. The "class" mentioned raise more questions than it answers.
Use CoCreateGUID() for Windows Mobile...
You don't need to generate a GUID for SHNOTIFICATIONDATA.
You only set the clsid if you want WM to notify a COM object that implements IshellNotificationCallback interface.
Quote from MSDN:
When loading up the SHNOTIFICATIONDATA
structure, you can specify either the
notification class (clsid), the window
to receive command choices (hwndSink),
or both. If you specify the clsid,
your COM component must implement
IshellNotificationCallback. If you
specify the clsid and an hwndSink,
both COM and Window Message-style
callbacks will be generated.
I've never personally used the COM callback, I always use the windows message callback. It's a lot easier to setup and use and you don't need to generate a GUID.
You could also use UuidCreate (which CoCreateGuid eventually calls).
I wrote a device controller (rs232) and it is being used successfully, however users want to view data and control the device (or perhaps communicate through my program) from Excel. I dismissed DDE as an option and found that RTD (IRtdServer) is probably a good start (though no way to send data back to the "server" from the real time data client).
I found these resources for the RTD part:
http://support.microsoft.com/?id=327215
and
http://support.microsoft.com/?id=327215
This is a multi-threaded app and I had already added the ability to have multiple listeners on the com port so that I could update multiple clients. I will add the COM interface to the EXE.
But what I need after that is some way of controlling my app/proxying commands to the device through my app from Excel.
What would be the best way to do that?
Perhaps another COM interface and calling it from VBA or something? I am not familiar with using scripting from Excel, so perhaps someone can provice sample code or links that show both the code for a COM object and the accompanying VB(A?) code?
Keep in mind that this is an unmanaged C++ application and it cannot be converted to managed or C# right now. Alternatives using C# are welcome as well, but that is a long-term rewrite.
Thanks
EDIT
I have an alternative to adding COM support into the existing EXE. I think it is more flexible to add a two-way communications (cross platform - maybe boost or corba or just straight IP based with my own message protocol)
A COM server (or two) can wrap that communications channel - whatever it is. This doesn;t really affect my question at all - I still would like to know the options for controlling an external EXE from Excel.
EDIT
Not having to roll out .NET to customers is also an big plus. many of these devices are on PCs that are pretty old and have perhaps NT or XP on them and I don't relish increasing my setup/install package from 700KB to the ridiculous .NET install size...
Option #1:
Create a small COM server - make sure its interfaces are suitable for scripting with the built Visual Basic engine in Excel. (e.g. use simple types and BSTRS).
Write Excel VB Macros to (1) add your own tool bar to excel and (2) call your COM server.
You can also add buttons and other UI elements to sheets and hook them them up to VB macros.
Option #2:
I realize that you do not want to use C# - but automating office, and talking to COM objects is really, really easy in C# with Visual Studio Tools for Office (VSTO). You shoul really look into this option - If done correctly, it shouldn't mean re-writing any of your existing code. Just use C# and VSTO as a bridge between Excel and your RTD server. As with VB, its straight froward to connect UI elements in Excel to C# and then to your RTD server.
Calling a COM object from VBA is straightforward. This SO Question and my answer give an example of how to create a COM object. Calling exposed methods is as you would expect:
object.ExposedMethod(optional params...);