|Open Object Rexx™: Programming Guide|
|Prev||Chapter 10. Classic Rexx Application Programming Interfaces||Next|
The purpose of this section is to describe any behaviors specific to Object Rexx that the designer of a Windows Scripting Host (WSH) should be aware of. It is assumed that the reader is already familiar with how to do that, or has the appropriate documentation at hand. For further information, see "Windows Scripting Host Engine", in Open Object Rexx: Reference.
Object Rexx is a multithreaded program. (See Concurrency, in Object Rexx for Windows: Reference.) The closest Windows model is the free-threaded model for dealing with multiple threads. The WSH controls are typically apartment-threaded. Therefore, since Object Rexx does not restrict its callers to any particular thread, and it passes on any exterior calls in the thread context in which it was received, then for all practical purposes it should be treated as an apartment-threaded program.
There are several interfaces that a WSH engine can use. Object Rexx does not support all of them; some are supported, but created dynamically. Since the dynamically-supported interfaces will not appear in an OLE viewer, they are listed here.
The following interfaces are fully supported:
While Object Rexx has code for all of the methods of an interface that it supports, all methods may not be implemented. The methods that are not implemented will return E_NOTIMPL.
The following interfaces are supported:
GetDispID - but does not support dynamic creation of properties or methods.
InvokeEx - but does not support dynamic creation of properties or methods.
Object Rexx does not support the WSH Script Debugging facilities. For the best techniques for debugging an Object Rexx script, refer to the section on the Trace keyword in "Keyword Instructions", in Open Object Rexx: Reference.
Object Rexx does not support DCOM.