Introduction to the Development of com components by masm32 [1] [2] [3]

Author: combojiang
Time: 2007-12-: 09
Chain: http://bbs.pediy.com/showthread.php? T = 56328

Statement: This post reference site: http://ourworld.compuserve.com/

[1] basic knowledge
Component Object Model (Com) is widely used in windows operating systems. Com is complex because of a large number of technical details. However, this complexity makes calling com components very simple. Com and the application adopts the server/client architecture. Next we will introduce the compilation and calling of com components in the next two articles.

Com programming is currently a hot topic in program development. Various programming languages provide good support for component programming. However, except for assembly languages, assembly language development components have no advantages. However, the compilation and development knowledge helps us understand the working principle of com components. Okay. Let's talk about it in a few minutes and start introducing it :)

All inc header files must meet the following requirements:

1) masm32's loose type definition Convention will continue to be used. That is to say, the parameters can be defined as their basic types, which are representative of DWORD.

2) No code can be created in the header file, which only contains the definition information. If the header file must contain the code, it must be defined as a macro.

3) struct should be defined according to their C prototype.

4) The GUID structure is defined in the windows. inc file. The GUID value should be defined by the textequ macro, so that no code is generated directly.

5) the interface definition is divided into two steps:
1. A general macro generates a general interface structure.
2. Use the interface name to modify the method name of the structure itself.
This method can effectively avoid namespace conflicts and facilitate interface definition Structure Inheritance.

6) use the coinvoke macro to call COM interface functions.

 

GUIDS
EXAMPLE:

SIID_IUnknown TEXTEQU <{000000000 H, 00000 H, 00000 H,
{0C0H, 000 H, 000 H, 000 H, 000 H, 000 H, 000 H, 046 H }}

Can be used to define
IID_IUnknown GUID sIID_IUnknown

 

Interface:
Because of the loose type check in MASM32 prototype conventions, this mainly checks the number of function parameters during compilation. Therefore, you can easily define interface functions, as shown below. The following table uses the values to represent the number of function parameters.

Comethod1Proto typedef proto: DWORD
Comethod2Proto typedef proto: DWORD,: DWORD
Comethod3Proto typedef proto: DWORD,: DWORD,: DWORD
Comethod4Proto typedef proto: DWORD,: DWORD
Comethod4Proto typedef proto: DWORD,: DWORD

The function pointer is as follows:
Comethod1 typedef ptr comethod1Proto
Comethod2 typedef ptr comethod2Proto
Comethod3 typedef ptr comethod3Proto
Comethod4 typedef ptr comethod4Proto
Comethod5 typedef ptr comethod4Proto

IUnknown interface: The IUnknown interface is a basic interface, and all other interfaces are derived from it. The original function definition is as follows:

_ VtIUnknown MACRO CastName: REQ
; IUnknown methods
& Amp; CastName & _ QueryInterface comethod3?
& CastName & _ AddRef comethod1?
& CastName & _ Release comethod1?
ENDM

IUnknown STRUCT
_ VtIUnknown IUnknown
IUnknown ENDS

It is expanded as follows:

IUnknown STRUCT
IUnknown_QueryInterface comethod3?
IUnknown_AddRef comethod1?
IUnknown_Release comethod1?
IUnknown ENDS

IClassFactory Interface
IClassFactory is derived from IUnknown. Its structure begins with the IUnknown method, and two methods are added later.

_ VtIClassFactory MACRO CastName: REQ
; IUnknown methods
_ VtIUnknown CastName
; IClassFactory methods
& CastName & _ CreateInstance comethod4?
& CastName & _ LockServer comethod2?
ENDM

IClassFactory STRUCT
_ VtIClassFactory IClassFactory
IClassFactory ENDS

Expand as follows:

IClassFactory STRUCT
IClassFactory_QueryInterface comethod3?
IClassFactory_AddRef comethod1?
IClassFactory_Release comethod1?
IClassFactory_CreateInstance comethod4?
IClassFactory_LockServer comethod2?
IClassFactory ENDS

Coinvoke macro

;---------------------------------------------------------------------
; Coinvoke MACRO
; PInterface pointer to a specific interface instance
; Interface the Interfaces struct typedef
; Function which function or method of the interface to perform
; Args all required arguments
; (Type, kind and count determined by the function)
;
Coinvoke MACRO pInterface: REQ, Interface: REQ, Function: REQ, args: VARARG
LOCAL istatement, arg
FOR arg, <args>; run thru args to see if edx is lurking in there
IFIDNI <& arg>, <edx>
. ERR <edx is not allowed as a coinvoke parameter>
ENDIF
ENDM
Istatement CATSTR <invoke (Interface PTR [edx]). & Interface>, <_>,< & Function, pInterface>
IFNB <args>; add the list of parameter arguments if any
Istatement CATSTR istatement, <, >,< & args>
ENDIF
Mov edx, pInterface
Mov edx, [edx]
Istatement
ENDM
;---------------------------------------------------------------------
For example, the QueryInterface method is called as follows:

Coinvoke GMM, IUnknown, QueryInterface, ADDR IID_SomeOtherInterface,
ADDR ppnew

HRESULTS
The Return Value Type of any com interface function is an hResult, which is 4 bytes long. The returned value is in the eax register. You can use this value to determine whether the function call is successful.

. IF! SIGN?
; Function passed
. ELSE
; Function failed
. ENDIF
Next, we define a macro to simplify it:
. If succeeded; TRUE if SIGN bit not set
. If failed & n