>The difference is in how you use it. A Win32 DLL must be DECLAREd for VFP to use it. The DECLARE statement also defines what the interface looks like (you have to explicitly define in your code what the interface looks like).
>
>With COM late binding, the DLL must be registered (an entry is placed in the system registry) that specifies the name, GUID, directory holding the DLL, and some other things. VFP then goes to the registry, get's the location, and reads the interface at runtime either from the type library (TLB) or the DLL itself. Note that you don't have to defne the interface in your code. You then use CREATEOBJECT() to use it.
>
>Also, under Win32, you just make function calls. With COM, you instantiate an object and call methods or access properties. IMO, COM is a much cleaner interface and easier to use, but then the nasty details of how to implement all this stuff is hidden from us.
>
>If you try to use a COM DLL with DEFINE or a Win32 DLL with CREATEOBJECT(), you'll get an error.

No argument about the latter but 'If you try to use a COM DLL with DEFINE you'll get an error" ?

Firstly I assume, if you're talking VFP. you mean DECLARE (and you declare each function individually - not the DLL)
But all COM dlls have to export, for example, IUnknown and you can access that using DECLARE - so why not any other function that the writer of the COM object chooses to expose ?

I've never tried it but what's prevents someone writing a COM DLL (that can be instantiated in VFP or used via Interop in .NET) but also exports functions that can be used via DECLARE in VFP or DLLImport in NET?

Best,
Viv

>
>
>>Isn't a COM DLL just a DLL that implements the COM interface? I didn't think there was anything governing what other methods it might expose....