COM View, Revisited

[Zen]

If you've ever tried to write any COM code in MASM, you are probably familar with Japheth's old Website (which no longer exists). It had an enormous amount of really useful COM-related macros and example code for a number of COM Server variations (and an ActiveX Control).
You can still find Japheth's site here: http://web.archive.org/web/20140909003608/http://japheth.de/

...Anyway, I had this terrific idea awhile back,...to recreate COMView and add some functionality (automating the process of writing a COM Client for an existing COM Class on your local computer). Japheth used to give away the source code for COMView (yes, it was written in Assembly Language),...and, I had downloaded it along time ago, and, somehow, managed to lose it.   
...So,...I have written an application in MASM assembly that partially recreates the functionality of the original COM View. My intention was to extend the functionality so that you would be able to select a registered COM Class (from your computer) and automate the process of creating a COM Client based on just having the InprocServer DLL to work with. If you know anything about COM, I'm sure you can see the potential problems right away.
The COM Library will only return a pointer (address) to the COM Class's Virtual Function Table when you instantiate it with CoCreateInstance.
...After that,...you're on your own,...
So, here are the problems:

• You must be able to correctly prototype the COM Class interfaces (converting a C-style VTable to a MASM include file).
• And,...you must have some idea of how the interface's member functions operate, and what reasonable values to supply to it, to get it to work correctly.

The application included in the Zip file below creates a List View control and enumerates all the CLSIDs on your computer that have InprocServer32 SubKeys, displaying the CLSID, the readable COM Class Name (if it exists), and the location of the COM DLL InprocServer on your computer (both 32-Bit and 64-Bit Versions).
If you double-click on an item in the List View, a child window pops up that displays all the Registry entries of that selected COM Class in a TextBox (so you can copy the information to use in a Google search, or whatever,...).

EDIT: I have removed the original version that was provided as a zip file at the end of this post because there is an updated version included several posts below (PHASE TWO).

[K_F]

Looks useful.. I could play with this - thanks

[Zen]

Some basic info:
On my computer, running Windows Seven Professional, the List View contains (after enumeration) more than 5,600 registered COM Classes (all that have the InprocServer32 SubKey).
The vast majority of these components are copyrighted by Microsoft,...and, so, the potential exists that these components have online documentation (MSDN), and, probably header files exist for them in the SDK.
Many of these classes are well-known: DirectX, Microsoft Office, the .NET Framework classes, Windows Media Player,...and, the online documentation is extensive. Quite a few of them are totally mysterious, though, and you will find nothing informative on the Internet about them,...
...Also,...if you search Japheth's old site (address above in first post), you will find a utility named: h2incx, which converts C header files to Masm-style include files.
...And,...as I'm sure everyone here knows: Vortex has many FREE and incredibly useful utilities available on his website: Vortex's Utilities, Tools, and Toys

The Component Object Model Specification, 1995,  Microsoft Corporation

[Zen]

Well,...I'm making progress with the concept. I've added some functionality to the original COM View type application.
Now, the application not only enumerates all the CLSID InprocServer32s on your system,...double-clicking on any item produces a child window with a text box that displays all the Registry entries under that COM Class CLSID (these values can easily be copied). Also, I've added an Open File dialog, that allows you to open any file on your system. It then invokes CreateFileMapping and MapViewOfFile, and checks to see if the file is a valid COFF/Portable Executable, by reading values from the file's headers. Then various RVAs and offsets and section base addresses are saved to memory, and this information is displayed in a child window. Also, there is a dialog box that accepts a string version of a CLSID, converts this to an actual CLSID, and instantiates the COM Class using a Class Moniker (this seems to be quite reliable). The beginning of a procedure to map the Virtual Function Table exists, and the various pointers to the VTable and the implementations of IUnknown are saved to memory and then displayed in a child window.

This is a work in progress. I'm creating the foundation,...and, the code can be extended in anyway imaginable,...

It's FUNKY,...but, it works,...

PHASE TWO IS COMPLETE.

EDIT: There is an updated (new and improved) version of this application available in the last post of this thread.

[TouEnMasm]

Good start point.
The big work wiil be the translate of the .idl files,COMView was able to do that.
Look at oleview and midl who do it very well(provide header file .h) and give you many answers.

[Zen]

The big work wiil be the translate of the .idl files, COMView was able to do that.

...Dang,...I didn't know that,...but, anyway,...I don't have the IDL files. I don't have even SDK C-style header files. All I really have are the paths to the InprocServer32 DLLs (and, their associated CLSIDs). What I have are the COM Server DLLs.

[mabdelouahab]

Begin by extracting the TypeInfo's from the DLL, You can use LoadTypeLibEx , LoadRegTypeLib , IProvideClassInfo::GetClassInfo ...

[Zen]

EDIT: Well, I have fixed some errors in the previously posted version of COM Core Flux Warp. It now displays all the .NET Framework Classes that are registered for COM Interop, and there is a new function that checks for interfaces implemented by any COM Class instantiated with the Class Moniker. I also fixed several buffer overruns.
...I think this will be as far as I will go,...in terms of posting source code for this application here at the MASM Forum,...

...All further development will be done for my personal warped, nefarious purposes,...

[greenozon]

Hi Zen!
I was looking for updated original COMView tool (by Japheth) and suddenly found your tool.

so I've got the latest ver
71ef141e89f75fa080964228eb2b085b *Updated COM Core Flux Warp.zip
and I've followed your steps from readme -

When you first launch it, it does nothing. You must select:
'Preliminary Operations' from the Menu, and then select, 'Create List View', and, 'Scan Registry CLSIDs' in sequence
to get the application to execute its routines. Scan Registry CLSIDs takes awhile to execute (about ten seconds)

but I'm not able to see it coming on my PC...
time to wait for a couple of minutes... (powerfull PC, 6 cores, 3GHz....etc)

here is what I've got so far - http://prntscr.com/988xwf

so the quesiton is - does the tool supports even huger number of records (~10K as in my case)

[Zen]

Hi, GREENOZON,
I structured the way the application works as I was developing it (by adding completed components to the the main app), so, it seems weird.
Anyway, the image you provided the link to looks perfectly normal. When you launch the application, you must select 'Create List View' from the menu, which you obviously did. Then when the empty List View displays, you must select, 'Scan Registry CLSIDs' from the menu. If you read the source, you will see that the 'Scan Registry CLSIDs' routine does NOT execute unless the 'Create List View' routine has returned successfully (it updates a Data Structure,...I think, ZENSTATE,...and the beginning of the 'Scan Registry CLSIDs' checks that this variable has been updated). It is, admittedly, a cumbersome and unnecessary step, and, I added it just so that if the user repeatedly selects either 'Create List View' or 'Scan Registry CLSIDs' from the menu after they have already executed, the routines just return without doing anything.
...The answer to your question,.. "Does the tool supports even huger number of records (~10K as in my case)", is yes,...it should. If you read the source code ("ListViewFuncs.inc"), you will see that the 'Scan Registry CLSIDs' routine is composed of a number of code loops embedded in other code loops,...and, the element that terminates the large loop (that iterates through all the CLSIDs, is that on the final iteration, the Registry API, RegEnumKeyEx returns, ERROR_NO_MORE_ITEMS, at which point the application makes a Log File entry: "RegEnumKeyEx returned ERROR_NO_MORE_ITEMS."). Search the Log File for that phrase, and if you can't locate it, then the function terminated for some error (which should also be noted in the Log File). 
If you want to understand what the program is doing when it fills the List View, read the "ScanRegInprocSrvrs" code, which is located in the source file, "ListViewFuncs.inc".
It's possible that the "ScanRegInprocSrvrs" will fail unexpectedly (although I have not seen this happen on Windows Seven),...if this happens, there will be some descriptive entry in the Log File identifying the error.
I know, the Log File records alot of information (most of it useless),...but, if you read through it, you will find phrases describing whether the various routines executed successfully, or failed,...and the reason for the failure will be noted.

If you still have problems, post again,...and, I will make some suggestions,...

[GoneFishing]

ZEN,
Yesterday I  tested your app and  noticed  its unstable behavior.
I'll post more details if you're going to improve it