Hey Ernie,

I was surfin your web page looking for why my Colib is giving me this error:

Microsoft (R) Macro Assembler Version 6.14.8444
Copyright (C) Microsoft Corp 1981-1997. All rights reserved.

Assembling: D:\masm32\JProject2\CGmem\Loadpic\LoadPic.asm
Microsoft (R) Incremental Linker Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

colib.lib(DllGetClassObject.obj) : error LNK2001: unresolved external symbol _ClassMap
LoadPic.exe : fatal error LNK1120: 1 unresolved externals
Link error

When i try to compile your COM Graphic example. (Still dont know why, (( I have SP2 from Hutch's Page )) )

I was hoping somewhere on your page you'd list your latest version of CoLib. When i click on the link:
Trying to make a shortcut icon? Go down to the COM section and read the Accessing COM Objects from Assembly tutorial.

I got A Norton Antivirus warning that the .doc file downloaded has the W97M.Thus.A Virus!

Thought you should know.. And ah.. if you know what the above error is eluding towards, I would also be greatfull...

Thanx a ton..
Posted on 2001-09-03 18:57:22 by NaN
Ok.. this is very quickly becoming annoying... I've Downloaded the SP2 again, (just incase).. and replaced everything.. still nothing..

I recompiled the Colib.lib, first commenting out the 'externdef' for classmap.. The build produces an error (no surprises), then i put it back and rebuild the lib, and presto all is well!. But I go back to the example file and try to build it, i still get the same error.

Im completely lost on this...

Posted on 2001-09-03 19:37:04 by NaN
Well Persistance rules...

I still dont understand the problem here.... as The COM model is crazy to fully follow (ole, oaidl, colib, etc)... But from experiment i found that i DONT even need the colib.inc and colib.lib at all in Ernie's example file..

by removing the include's, Uncommenting the IID_IPicture definition, and placing a ".data" before it, Commenting out the Macro ";DeclareGuid IID_IPicture", the program builds and runs perfectly!

Im no com expert.. but things sound fishy to me. The DeclareGuid Macro works fine, its just that by including CoLib to use this macro, i get this annoying problem that comes with it!

Anyways, Ernie, I would be very happy to hear your take on this,

Posted on 2001-09-03 20:11:07 by NaN
I had a very simmilar problem when I was using DX8 in masm... I now use in FASM, so my problems are a little different... I just don't get some of MS stuff.

In the Icz example for a window, I made all the data global by putting it in the .data section instead of using the LOCAL thing. The window crashed every time. I tried putting a .data section in the middle of WinMain PROC and every thing worked fine...

I don't get it...
Posted on 2001-09-03 22:16:19 by Kenny
I just found out about the virus on my site. It seems to be just that one file, but I have to check how far it's spread.

That's what I get for working on my gf's conmputer. It's her second virus infection.

Anyway, Norton says nothing nasty will happen until Dec 13th, and only that day. And since I've not had 2 spare minuits in weeks...

Re ClassMap errors, that's somthing CoLib 1.1 fixed. CoLib 1.0 DEMANDED it be there, 1.1 is much more relaved about it. And yes, all I'm using is the GUID macro.

Somehow you must be pointing to the orgional lib.
Posted on 2001-09-03 23:43:03 by Ernie
Ok... Here is the facts.

    [*]I complelely erased every reference to COM off my computer.
    [*]I downloaded SP2 from hutch's page
    [*]I Unpack and the Unzip CoLib 1.1, and copy it into \masm32
    [*]Now i have a DIR: D:\masm32\com
    [*]Recompile your test progie
    [*]I Get THE SAME ERROR!! :rolleyes:

    Need more proof: (this is the file, pointed by the path of colib.inc)
    ; CoLib.inc Common data, structures, functions and macros
    ; to be used as a template for in-process com server objects
    ; version 1.1
    ; Copyright (c) 9/28/00 Ernest Murphy
    ; revised 3/3/01 to simplify object creation and remove ObjectData.m_pEntry0
    ; revised 3/1/01 to add DeclareVariant and remove m_ObjectSize from ObjectData
    ; (now just requires SIZEOF ObjectData)
    ; revised 1/8/01 to include AggItem STRUCT (formerly in DllGetclassObject.asm)
    ; For educational use only. Any commercial re-use only by written license

    As well the includelib path points to the colib.lib in its proper location.

    I personally DONT think its in here specifically. I think the proplem resided in this file:
    ; colibrary procedure DllGetClassObject
    ; -------------------------------------------------------
    ; This procedure was written by Ernest Murphy 9/27/00
    ; revised 1/8/01 to reposition .data structs to other libs
    ; Copyright (c) 9/28/00 Ernest Murphy
    ; For educational use only. Any commercial re-use only by written license
    ; -------------------------------------------------------
    .model flat, stdcall ; 32 bit memory model
    option casemap :none ; case sensitive

    include mini_win.inc ; 'just enough' of windows.inc (speeds build)
    include \masm32\include\kernel32.inc
    include \masm32\include\oleaut32.inc
    include \masm32\include\ole32.inc
    include \masm32\include\masm32.inc
    include \masm32\COM\include\oaidl.inc

    include colib.inc

    externdef ClassMap:DWORD
    externdef IID_IClassFactory:DWORD

    ;PUBLIC vtIClassFact
    PUBLIC Pos
    PUBLIC pResEnd


    ClassFactoryClassMap EQU CFClassMap

    CFClassMap ClassItem { pIID_IClassFactory, NULL, NULL, \
    NULL, SIZEOF CFmembers }

    CFIMap EQU CFInterfaceItem1

    CFInterfaceItem1 InterfaceItem { pIID_IClassFactory, OFFSET vtIClassFact }

    vtIClassFact IClassFactory \
    { NDQueryInterface,
    LockServer }

    CFmembers STRUCT DWORD
    m_pClassItem DWORD NULL
    CFmembers ENDS

    ; declare the ClassFactory object structure
    ; this is only run-time instanced
    ClassFactObject STRUCT DWORD
    ObjectData0 ObjectData { } ; base values
    CFMembers CFmembers { } ; info on the object to impliment
    ObjectEntry0 ObjectEntry { } ; non-delegating Unknown
    ObjectEntry1 ObjectEntry { } ; IClassFactory
    ClassFactObject ENDS

    Pos DWORD 0
    pResEnd DWORD 0


    DllGetClassObject PROC PUBLIC rclsid:DWORD, riid:DWORD, ppv:DWORD

    ; COM server dll main export
    ; Creates a Class Factory object to create a requested coclass
    ; EXAMPLE:
    ; invoke DllGetClassObject, ADDR clsid, ADDR iid:DWORD, ADDR pv
    ; Uses: eax, ecx, edx
    LOCAL pFactory:DWORD, pClassItem:DWORD, retval:DWORD

    ; compare the CLSID given us to the ones we can build
    ; we can ONLY build a Class Factory object to build the objects
    ; in our Class Map. All others get rejected

    mov pFactory, NULL ; define our pointers
    ; walk the class map and see if we make this class object
    mov ecx, OFFSET ClassMap
    mov pClassItem, ecx
    mov eax, (ClassItem PTR [ecx]).m_clsid ; get first class clsid
    .WHILE eax ; check if Classitem.m_riid != NULL = END_OF_MAP signal
    invoke IsEqualGUID, rclsid, eax
    .IF !eax
    add pClassItem, SIZEOF ClassItem
    mov ecx, pClassItem
    mov eax, (ClassItem PTR [ecx]).m_clsid
    ; found a supported class
    ; make a new Class Factory object
    ; create a Class Factory
    invoke AllocObject, ADDR pFactory, ADDR CFClassMap, NULL, NULL
    mov eax, E_OUTOFMEMORY
    ;now set the custom data (the reference
    ; to the Class Item we can create)
    mov eax, pFactory
    mov eax, (ObjectEntry PTR [eax]).m_pBase
    mov ecx, pClassItem
    mov (ClassFactObject PTR [eax]).CFMembers.m_pClassItem, ecx
    coinvoke pFactory, IUnknown, QueryInterface, riid, ppv
    ; use the QI hresult to determine the success of this procedure
    mov retval, eax
    ; and release our helper pointer
    invoke NDRelease, pFactory
    mov eax, retval
    ; if we got here we didn't find a matching CLSID
    DllGetClassObject ENDP


    Where a more up-to-date version exists on you machine, but is not bundled to Hutch's web site... Because this file definitely makes reference to some externdef ClassMap:DWORD.

    To make this more concrete, i even got the old MS Find going, and searched the entire hard drive for any TEXT STRING "ClassMap" (not case sensitive).

    I found out that :

    ScriptTxt.asm (wont compile for the same reason)
    The documentation sugest a change made, but not clear. And the old "classmap" public def is commented out.
     ; as of CoLib 1.1, ClassMap is no longer required
    ; PUBLIC ClassMap ; thanks to Maurice MONTGENIE for pointing out this ommision
    ; ; (Resolves a LINK problem in that DllGetClassObject IS linked,
    ; ; but not called. That object needs this definition)
    ; ; (When colib2 is released and we can delete this again)
    ; ClassMap DWORD NULL ; also needed with the PUBLIC up there

    AsmCtrl.asm (will compile!)
    It has a ClassMap public definition, but its different in appearance, building a DWORD definition think...
    PUBLIC      ClassMap

    .LISTALL ; NOW let's list everything


    ; describe the objects inside the DLL
    ClassMap ClassItem \ ; class map instance
    OFFSET AsmCtrlTypeLibInfo, OFFSET AsmCtrlIMap, \
    OFFSET CreateAsmCtrl, OFFSET DestroyAsmCtrl, \
    OFFSET AsmCtrlInitData, SIZEOF AsmCtrlObject }

    MyCom2.asm (Will Compile)
    Again for the same reasons mentioned above..
    PUBLIC ClassMap                             ; need to export ONLY the ClassMap


    ; describe the classes inside the DLL
    OFFSET MyCom2TypeLibInfo, OFFSET MyCom2IMap, \
    CreateMyCom2, NULL, NULL, SIZEOF MyCom2Object }

    At this point, im pretty sure im not pointing to the origional lib. It apprears the fixes you and Maurice MONTGENIE have not fully been updated, as some of your examples feel they need it, and some dont. And on the SP2, the Dont's - dont compile!

Posted on 2001-09-04 14:07:39 by NaN
Sorry to say I don't have some super secret perfect copy of CoLib on my drive. I just downloaded SP2 off hutch's site and compiled LoadPic.asm just fine.

How about trying to mess up the folder name where you think CoLib is, and recompile. If it finds the lib, you have it in another place too (most likely on your path).
Posted on 2001-09-04 18:15:27 by Ernie
Posted on 2001-09-04 19:58:45 by NaN
As far as I know, it's hutch and icz maintaining windows.inc, not
microsoft. Thus, it's not a newer version of windows that breaks
stuff, it's something that was wrong (or has gone wrong) in windows.inc :).
Posted on 2001-09-04 20:08:04 by f0dder