#import directive

[xroot]

The #import directive in C++ generates 2 files, for Component Object Model (COM) interfaces.
1. A smart pointer-type declarations file (???.tlh)
2. A Wrapper implementations for Win32 type library (???.tli)
The two files I was playing with are from msado15.dll (ADO) (msado15.tlh and msado15.tli).
Can someone tell me if any of these two file types can or have been converted to be used in MASM?
Not sure how much work it would take to convert them to an "inc" file but it would seem a possibility.
It would be a lot simpler in MASM if they could be used, simple like how C++, VB and even WinBatch uses COM.
Thanks for any INFO.

[raymond]

This is the only item I can find in the archives on the subject of .tlh and .tli files along with the #import directive.

My son has asked me to write a small app to access a data base. The main application provides an SDK for preparing such add-ons. However, the provided DLL must be "imported" (which I think can be done with LoadLibrary) and that operation is described as follows if done in Visual C++:

The #import clause forces the reading of the SDK library. Based on the data read, the compiler creates two special header files: the library header file, whose extension is .tlh and the library implementation file, whose extension is .tli. These files can be consulted but should never be modified.

My main question at this time is: can those .tlh and .tli files be extracted strictly with assembly code or do I have to learn some other language to recover them and convert them for use with assembly????

Any help would be greatly appreciated.

[MichaelW]

If you needed only a few the DLL's functions then Run-Time Dynamic Linking would be easy, and it would allow you to present a non-programmer user with a nice, simple error message if the DLL or one of the functions could not be found. Load-Time Dynamic Linking would be a more reasonable choice where you needed more than a few functions, and/or where the user could be expected to understand the Windows error messages. POLIB, included in the MASM32 bin directory, can create an import library directly from the DLL:

POLIB name.dll /OUT: name.lib

For the header file, I know of no good way other than a manual conversion, starting with the C/C++ header file(s). As a reference to help you create the header file, you could use POLIB to create a module definition file from the import library:

POLIB name.lib /MAKEDEF: name.def

Or use DUMPPE, also in the MASM32 bin directory, to get a list of the DLL exports (and imports):

DUMPPE name.dll

Note that this is all based on my limited experiences with "normal" DLLs.

[zooba]

"#import" is specifically for COM interfaces; the 'normal' DLL rules don't really apply. It causes the C++ compiler to generate wrapper classes to handle the COM overhead (these are the .tlh and .tli files).

You will definitely need to look into dealing with COM for this. Personally I would use VB or C# if it isn't hugely performance related, or C++ (possibly with inline asm) if it is.

If you are going to use assembly language, you're probably best off trying to translate the .tlh and .tli files (they should be standard C++). I don't know of any tools to help with this.

Good luck.

Cheers,

Zooba :U

[MichaelW]

Interesting. Pardon my ignorance, but how is the DLL different, what sort of functions would it be exporting, and why could these functions not be (reasonably) used from asm?

[japheth]

If you are going to use assembly language, you're probably best off trying to translate the .tlh and .tli files (they should be standard C++). I don't know of any tools to help with this.

http://www.japheth.de/comview.html can create .inc files from COM objects. But I have to agree, C++ is preferable if lots of COM stuff is to be done.

[zooba]

Pardon my ignorance, but how is the DLL different, what sort of functions would it be exporting, and why could these functions not be (reasonably) used from asm?

I'm no COM expert either, but as I understand it, only these functions need to be exported. DllGetClassObject is used to obtain a factory class which effectively returns an object. Function calls on that object go through a virtual function table and so don't need to be exported directly from the DLL.

So, you can access the factory using DllGetClassObject (probably dynamically, ie. LoadLibrary/GetProcAddress) and use the function tables to call the functions you want. The associated MIDL file describes this interface.

COM is not easy. If you can do COM in C++ you're easily in the top 1-2% of developers. VB has for a very long time directly supported COM objects, which makes them indistinguishable from built in objects. C# and VB both make dealing with COM objects much easier than in C++. Assembly is asking for a lot of work for very little performance gain (due to marshalling and other overheads).

(Feel free to correct anything I've misunderstood before too many people listen to me and also get it wrong :bg )

Cheers,

Zooba :U

[MichaelW]

Thanks for the information. I see now that I did not properly understand the question.

[raymond]

Thanks to all for those quick answers. I will look into all that info and see what I can make of it.

The SDK does have a descriptive listing of most structs (probably objects in COM language) used  with the "methods" of the DLL. However, the listed sizes don't seem to match too well with those of records in their related files of the data base. :eek