Dear COM World, I propose we work on some projects that automate several COM translations. Most of my work on the Web Browser project has been slowed because of: 1. Translating Interfaces 2. Translating GUIDs 3. Writing tables/IDLs 4. Running around regedit 5. Silly typos in the above translations All of these functions can then be placed on Ernie's COM menu in QEditor. Xtreme
Posted on 2001-02-09 12:44:00 by Xtreme
Actually, as a part of my upcoming Visual Assembler tool, I have had ideas to help COM writing easier... one of the tools I wanted to get around to writing (of necessity for some of my GUI stuff) is the ability to read a type library and generate an Assembly wrapper around it. I've already done one in parts for another language. This would do two things: first, it could expose the Interfaces, and objects and such, you would still have to know IUnknown and IDispatch... or, in the case of my ADO/OLE DB Translation for Database Access, it could hide the COMplexity and make it so you just call asmConnection.Open ... without all the interface stuff.. in otherwords, a slower wrapped verstion, but it would produce a suitable wrapper so you don't need to worry about all the Interface pointers and stuff. This isn't easy, but it's doable and is necessity if I want COM support in my Visual Assembler. However, I'm no expert in COM like Ernie and some others. I'm just expert in other ereas, such as development tool development. _Shawn
Posted on 2001-02-09 13:39:00 by _Shawn
X: That's a quite ambitious list you have. I once began trying to crack type lib info, but stopped to get some more basic work done after a couple of months of not very productive work (well, most of oaidl.inc came from that effort). Let's look at your list: 1. Translating Interfaces - can be done by reading info in the typelib. Or cheating and copying out of OleView. See sean's inconsequential pages for a C app to read them. (http://ript.net/~spec/ COM Automation Type Info) If you're not good at this by hand using copy and paste, you don't understand it well enough to code it. It's a fairly fast process for me, couple of mins for an average interface. Counting how many params it has takes the longest. 2. Translating GUIDs - simple string manipulation, ripe for a VB solution. Next free day I get (after I get the docking thing done) I'm gonna code an ASM CreateGUID applet. 3. Writing tables/IDLs - It already exists. It's called MSVC. Start an ATL app, define the interfaces with it's wizzard, then close it. Before you delete it all, steal the .idl and the .rgs files from it. Interface Def Language isn't very hard, really worth getting the feel for it to reproduce it by hand. For interfaces, see #1 4. Running around regedit - Just replace HKCR with HKLM while checking the registrar script. HKLM is much smaller, easier & quicker to search. Any you don't miss anything extraneous. 5. Silly typos in the above translations - no comment Shawn: Offhand I don't see the advantage to a wrapper. Why not just automate definining the actual interface and use it direct in asm?
Posted on 2001-02-09 14:16:00 by Ernie
Ernie: Actually, Sometimes I don't want to deal with all the Interface Pointers directly. There are a few times when I'd rather have that maganged behind the scenes... VB is a good example of that approach. Nonetheless, I haven't written it for assembly. Let me get my DSL back so I can post the first Beta and then write the GUI, and I'll look into all the COM stuff after that. You're right tho, there may not be an immediate advantage if it clogs up with potentially unused wrapper code. It'll require thought. _Shawn
Posted on 2001-02-09 16:20:00 by _Shawn
Real men don't use wrappers. ;-)
Posted on 2001-02-09 18:29:00 by Ernie
I know how to do this stuff manually. * But I'm NOT nearly as fast as my 1GHz processor * We need dlls and add-ins to do the grunt-work for us. After all, we need to free ourselves so we can progress to other areas. A brain like Erine's needs to move on to greater things! Xtreme This message was edited by Xtreme, on 2/10/2001 4:10:40 AM
Posted on 2001-02-10 03:52:00 by Xtreme
Surely that would be ignoring the principles on which most assembly programmers base their work, That being that what a program does and how it does it are of equal importance. If you use Dll's then you aren't assured of highly efficent code or indeed bug free code. Also if you don't understand the basics then you don't realy know whats going on. How many time do people who use perprogrammed routines actually double the work load because they may, for example want to carry out a specific task but the routines written only proform it in conjuction with another task, you would then have to use the routine and undo the second task it carried out and waste processing power. Why use assembly at all, if your happy to do that use VC++ or VB.
Posted on 2001-02-10 18:41:00 by Zadkiel
Zadkiel, You miss the point that we would be writing these dll's. Now go someplace else to do your VB bashing. E
Posted on 2001-02-11 02:22:00 by Ernie
I'm speaking of DLLs that plug into qeditor and generate code for us. For example: ; {AFFD6F83-9D30-11d4-A324-444553540000} sCLSID_MyGUID TEXTEQU <{0AFFD6F83H, 09D30H, 011D4H, \ {0A3H, 024H, 044H, 045H, 053H, 054H, 000H, 000H}}> CLSID_MyGUID GUID sCLSID_MyGUID Our computers can do it much faster that we can! Xtreme
Posted on 2001-02-11 02:54:00 by Xtreme
What is preventing this from being done in a macro?

CLSID_MyGUID GUID 
I'm just begining with the under side of COM. I've used it from the other end before :) Thanks for the docs Ernie. Take care, bitRAKE
Posted on 2001-02-11 09:12:00 by bitRAKE
Actually, the following: CLSID_MyGUID GUID is almost legal MASM, and has been since Icz put the GUID structure into windows.inc. However, the trouble is getting the GUID into a reuseable format. To be completely reuseable, a GUID need be defined as a text equate, then later IF REQUIRED converted into the pattern of 16 bytes of .data memory. Hence all those nasty textequates in my .inc files. Automating this translation isn't so bad. Just go to "Tools", "Change Editor Settings" and add this to QE: Convert GUID,AsmGUID.DLL Of course, you first need build a dll that exports the QE interface. Hopefully my other tuts have led you to add a "Build DLL" setting to QE. Just drop the following into a file named "AsmGUID.def": LIBRARY AsmGUID EXPORTS QePlugIn That's it. Oh, you want the program too? (AsmGUID.asm)

;-------------------------------------------------------------------------------
;
;  GUID to ASM format translator
;  copyright Feb 11, 2001 by Ernest Murphy
;  all commercial rights reserved, for educational use only
;
;-------------------------------------------------------------------------------
;
;  will convert:  "{AFFD6F83-9D30-11d4-A324-444553540000}"
;
;            to:  "sSomeGUID TEXTEQU <{0AFFD6F83H, 09D30H, 011d4H, {0A3H, 024H, 044H, 045H, 053H, 054H, 000H, 000H}}>"
;
;
;  cautions: It is VERY LITERAL, with zero error checking. Must first highlight entire 
;               GUID before calling. If any mistakes noticed in translation, hit CTRL-Z
;               and try again.
;
;-------------------------------------------------------------------------------
.386
.model flat,stdcall
option casemap:none

;-------------------------------------------------------------------------------
include \masm32\include\windows.inc
include \masm32\include\user32.inc
include \masm32\include\kernel32.inc
include \masm32\include\masm32.inc

includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib
includelib \masm32\lib\masm32.lib

;-------------------------------------------------------------------------------
.data
BufIn           BYTE    "******************************************************"

s1              BYTE    "sSomeGUID TEXTEQU <{0", 0
s2              BYTE    "H, 0", 0
s3              BYTE    "H, {0", 0   
s4              BYTE    "H}}>", 0



;-------------------------------------------------------------------------------
.code

DllEntry proc hInstance:HINSTANCE, reason:DWORD, reserved1:DWORD
    mov  eax,TRUE
    ret
DllEntry ENDP


QePlugIn PROC hInst, hMain:DWORD, hEd:DWORD, hTool:DWORD, hStat:DWORD
    LOCAL Cr:CHARRANGE, cBufIn:DWORD, hHeap:DWORD, pBuffer:DWORD
    LOCAL pBufIn:DWORD, iBufIn:DWORD
    LOCAL tBuf1[50]:BYTE, tBuf2[50]:BYTE
    LOCAL OutBuf[50]:BYTE
    
.code
    mov pBufIn, OFFSET BufIn
    mov iBufIn, OFFSET BufIn
    invoke SendMessage, hEd, EM_GETSELTEXT, 0, pBufIn

    mov OutBuf, NULL  ; zero output string
    invoke lstrcpy, ADDR OutBuf, ADDR s1
    add iBufIn, 1
    invoke lstrcpyn, ADDR tBuf1, iBufIn, 9
    invoke lstrcat, ADDR OutBuf, ADDR tBuf1

    invoke lstrcat, ADDR OutBuf, ADDR s2
    add iBufIn, 9
    invoke lstrcpyn, ADDR tBuf1, iBufIn, 5
    invoke lstrcat, ADDR OutBuf, ADDR tBuf1

    invoke lstrcat, ADDR OutBuf, ADDR s2
    add iBufIn, 5
    invoke lstrcpyn, ADDR tBuf1, iBufIn, 5
    invoke lstrcat, ADDR OutBuf, ADDR tBuf1

    invoke lstrcat, ADDR OutBuf, ADDR s3
    add iBufIn, 5
    invoke lstrcpyn, ADDR tBuf1, iBufIn, 3
    invoke lstrcat, ADDR OutBuf, ADDR tBuf1

    invoke lstrcat, ADDR OutBuf, ADDR s2
    add iBufIn, 2
    invoke lstrcpyn, ADDR tBuf1, iBufIn, 3
    invoke lstrcat, ADDR OutBuf, ADDR tBuf1

    invoke lstrcat, ADDR OutBuf, ADDR s2
    add iBufIn, 3
    invoke lstrcpyn, ADDR tBuf1, iBufIn, 3
    invoke lstrcat, ADDR OutBuf, ADDR tBuf1

    invoke lstrcat, ADDR OutBuf, ADDR s2
    add iBufIn, 2
    invoke lstrcpyn, ADDR tBuf1, iBufIn, 3
    invoke lstr
Posted on 2001-02-11 11:29:00 by Ernie