Alex Martelli wrote: > Larry Bates <[EMAIL PROTECTED]> wrote: > >> recently learned that you can ship COM as either an .EXE or a .DLL (nobody >> has yet let me know why). > > The "why" is pretty obvious -- you may want to be able to instantiate a > COM object either in-process, or in its own separate process, depending > on that object's nature. For example, a complete application that when > running exposes COM objects to let other processes drive/script it will > be an EXE file since it can also run independently. > > In general I'm no big fan of MS's design, but COM, despite its > imperfections, was in fact seriously good (Don Box's "Essential COM", an > excellent book, went just into enough depth to let a developer really > appreciate that, IMHO). I'm using the past tense because MS has been > trying to kill COM for a while now (but I notice that "Essential COM", > while 10 years-old, is _still_ in stock at Amazon -- so, I guess that so > far MS's attempts haven't _quite_ succeeded yet:-). > > > Alex
I guess I was the only one it wasn't "obvious" to <grin>. I've always written my COM servers as .EXE files even though they cannot be run independently. What I find is "odd" is that I can create a .DLL or an .EXE of my COM server and after I register it, my application doesn't appear to know the difference. The difference seems to be hidden from the actual application and doesn't affect it (at least that I can determine). I also think COM works quite well and I've found it much easier to use than C-style DLLs that many vendors ship as their API. Most of what I've learned came from Mark/Andy's Python Programming on Win32 and trial-and-error so my knowledge is quite limited. Thanks for the info. Larry -- http://mail.python.org/mailman/listinfo/python-list