Microsoft's Component Object Model [L1 ] ...
tcom offers both client and server COM functionality.
optcl ...
TclScript also is COM-aware.
COSH ...
In beginning programming with a new client-server protocol, it's often wise to rely on well-established, standard servers, and concentrate on client-side programming. With COM, this means launching any of several popular Win* applications, and interrogating them as COM servers (or "performing COM automation" on them-- the Win* vocabulary is slightly different from what might otherwise be expected). The starting point for referring to a COM server is through its programmatic identifier (ProgID). Here are a few example ProgID's, any of which might be used in, for instance, tcom with
set application [::tcom::ref createobject $ProgID]
Netscape.Network.1 [http://developer.netscape.com/docs/manuals/communicator/OLE/ole2net.htm]
FrontPage.Editor.Document
Word.Document (note that WordPad is ''not'' a COM server)
InternetExplorer.Application
Excel.Application
Excel.Application.8
PDF.PdfCtrl.1
Word.Application
DSOleFile.PropertyReader
How does one discover the API for a COM-exporting application of interest? One place to start is by Googling "$app_name object model". The (full) help for most Microsoft applications includes this information, often disguised as instructions on use of Visual Basic for Applications or VBScript. Also, one can often start the application in question, and select Tools/Macros/Visual Basic Editor, then View/$app Explorer, and the API should be within a click or two more.