Author:halw

Date:2009-08-05T20:29:52.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@279 abb3cda0-5349-4a8f-a601-0c33ac3a8c38

documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/coclass.wiki

@@ -1,13 +1,13 @@
 [[Property:title|Coclass]]
 [[Property:weight|3]]
 [[Property:uuid|7f91f9ce-e042-1d48-9d01-f9b794269ec4]]
-We have seen that interfaces can be perceived as views of a component. This conceptual representation actually maps the implementation of an EiffelCOM component since the coclass inherits from the interfaces and implements their deferred features. Indeed, interfaces are deferred classes with all features accessible from outside deferred. The coclass is an Eiffel class that inherits from these interfaces and implements all the features. This design is not specific to Eiffel though and can be found in other languages as well. The coclass defines the behavior of the interface functions. <br/>
+We saw earlier that [[COM Interfaces]] can be perceived as views of a component. This conceptual representation actually maps the implementation of an EiffelCOM component. This is because the coclass inherits from the interfaces and implements their deferred features. Indeed, interfaces are deferred classes with all features accessible from outside deferred. The coclass is an Eiffel class that inherits from these interfaces and implements all the features. This design is not specific to Eiffel though, and can be found in other languages as well. The coclass defines the behavior of the interface functions. <br/>
 
 ==Class Object==
-We have seen that interfaces are accessed through interface pointers. But how does a client get hold on one of these? 
+Also, we have seen that interfaces are accessed through interface pointers. But how does a client obtain one of these? 
 The answer lies in the class object. The name of this module should really be coclass factory since its goal is to spawn instances of the coclass on request. Class objects are accessed by COM whenever a client request a new instance of the associated component. COM loads the class object and asks it to provide the interface pointer requested by the client. 
 
-The way a class object is loaded in memory (this process is called activation) depends on the location of the component (See [[The Component Location|Location]]  for a description of the possible locations of a component). If the component is an in-process server then the class object is called directly through the functions exported from the DLL. If the component is an out-of-process server then it provides COM with a pointer to the class object. In both cases, once the component is loaded, COM has access to the class object and can call it would a client request a new instance of a component. 
+The way a class object is loaded in memory (this process is called activation) depends on the location of the component (See [[The Component Location|Location]]  for a description of the possible locations of a component). If the component is an in-process server, then the class object is called directly through the functions exported from the DLL. If the component is an out-of-process server, then it provides COM with a pointer to the class object. In both cases, once the component is loaded, COM has access to the class object and can call it, should a client request a new instance of a component. 
 
 [[Image:com-1|Component Creation]]  
 

documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/com-concepts.wiki

@@ -2,7 +2,7 @@
 [[Property:link_title|COM Concepts]]
 [[Property:weight|1]]
 [[Property:uuid|9cb19fc1-3d26-5752-6232-ea23f2668c32]]
-COM is a binary standard that describes how the component can communicate with the outer-world. The component communicates through well defined interfaces. Each interface is a specification of a group of properties and methods, and it does not contain the implementation of these routines but only their specification (signatures). The actual implementation lies in the coclass. There can be different implementations of a same interface in different coclasses. Finally, each coclass can be instantiated using a class object or class factory. These three notions will be discussed further in the forthcoming paragraphs. 
+COM is a binary standard that describes how a component can communicate with the outside world. The component communicates through well-defined interfaces. Each interface is a specification of a group of properties and methods. Importantly, the interface does not contain the implementation of the properties and methods, only their specifications (signatures). The actual implementation lies in the [[Coclass|'''coclass''']]. There can be different implementations of a same interface in different coclasses. Finally, each coclass can be instantiated using a class object or class factory. These three notions will be discussed further in the forthcoming paragraphs. 
 {{seealso|<br/>
 [[EiffelCOM Wizard|EiffelCOM wizard]]  <br/>
 [[EiffelCOM Library| EiffelCOM library]]  <br/>

documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/com-interfaces.wiki

@@ -1,13 +1,13 @@
 [[Property:title|COM Interfaces]]
 [[Property:weight|2]]
 [[Property:uuid|1dbc3fb2-cf0b-b129-1102-ba01e26d8f74]]
-Interfaces are at the heart of any COM component. Interfaces are described in the definition file of a component. They consist of a group of semantically related functions that can be accessed by the clients of the component. Although they are a specification, they also have a physical representation. A client can request a pointer on an interface and access the component functions through that pointer. Interfaces are the only possible way to access functions from a component. They enforce information hiding by providing only the public functions to the client.
+Interfaces are at the heart of any COM component. Interfaces are described in the definition file of a component. They consist of a group of semantically related functions that can be accessed by the clients of the component. Although they are a specification, they also have a physical representation. A client can request a pointer on an interface and access the component functions through that pointer. Interfaces are the only possible way to access functions from a component. They enforce information hiding by ensuring that clients can access only the component's public functions.
 
-Interfaces also define the type of a component. Each interface corresponds to a specific view of the component. It can be compared to polymorphism in the Object Oriented world. Whenever an interface from a component is requested, only the functions defined on that interface are accessible as if the component was polymorphically cast into an object of the type of that interface. 
+Interfaces also define the type of a component. Each interface corresponds to a specific view of the component. In a way, this can be compared to polymorphism in the object-oriented world. Whenever an interface from a component is requested, only the functions defined on that interface are accessible, as if the component were polymorphically cast into an object of the type of that interface. 
 
-The COM specification requires that any interface provides access to all interfaces on the same component. All interfaces should include a specific function called '''QueryInterface''' that will provide a pointer on any other interface of the component. Interfaces are identified with a globally unique identifier (GUID) guaranteed to be unique in time and space. Since this function has to be on every interface, it has been abstracted into a specific interface called '''IUnknown''' which all other interfaces must inherit from. 
+The COM specification requires that any interface provide access to all interfaces on the same component. All interfaces should include a specific function called '''QueryInterface''' that will provide a pointer on any other interface of the component. Interfaces are identified with a globally unique identifier (GUID) guaranteed to be unique in time and space. Since this function has to be on every interface, it has been abstracted into a specific interface called '''IUnknown''' from which all other interfaces must inherit. 
 
-The two other functions exposed by '''IUnknown''' are '''AddRef''' and '''Release'''. These functions should be called respectively when a client gets a reference on an interface or when it discards that reference. These two functions define the lifetime of the component: each interface keeps track of clients keeping a reference on them and when no clients have references anymore, the component can be unloaded from memory. You might start worrying thinking that this business of reference counting will imply lots of headaches, memory leaks, etc. and you would be right should you choose a low-level language to implement your components. Fortunately, you will never have to implement or use these functions in Eiffel: all the processing related to IUnknown is provided by the EiffelCOM runtime. Calls to '''QueryInterface''' are done "behind the scene" and only when needed. The lifetime of the component is also taken care of by the EiffelCOM runtime. 
+The two other functions exposed by '''IUnknown''' are '''AddRef''' and '''Release'''. These functions should be called respectively when a client gets a reference on an interface or when it discards that reference. These two functions define the life-cycle of a component at runtime: each interface tracks clients by keeping a reference on each of them. When there are no client references anymore, the component can be unloaded from memory. You might worry that this business of reference counting will the source of problems such as memory leaks. You would be right, should you choose a low-level language in which to implement your components. Fortunately, you will never have to implement or use these functions in Eiffel: all the processing related to IUnknown is provided by the EiffelCOM runtime. Calls to '''QueryInterface''' are done "behind the scene" and only when needed. The component life-cycle is also taken care of by the EiffelCOM runtime. 
 
 {{seealso|<br/>
 [[EiffelCOM Wizard|EiffelCOM wizard]]  <br/>

documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/component-location.wiki

@@ -3,15 +3,18 @@
 [[Property:uuid|083c0120-2eda-9353-ceae-f63e7f407341]]
 <div> 
 ==Types of Components==
- ActiveX, DirectX, OCX, COM+, ADO+, ASP etc. who never heard of these technologies? They all represent yet another use of the COM standard. This paragraph will focus on categorizing COM components according to their own properties as well as the context in which they are used. The categorization will define how the EiffelCOM wizard should be used to wrap or create a component. </div>The first criteria that defines the type of component is from where it will be accessed: will the component be loaded in the client process or will the component be a remote server for a distributed application? In the former case, the component is compiled as a Dynamic Link Libraries (DLL) while in the latter case it is a standard executable. <div> 
+Certainly you've heard of ActiveX, DirectX, OCX, COM+, ADO+, ASP, and other Microsoft technologies. These are all technologies that use the COM standard. This paragraph will focus on categorizing COM components according to their own properties as well as the context in which they are used. The categorization will define how the EiffelCOM wizard should be used to wrap or create a component. 
+The first criterion that defines the type of component is its origin: will the component be loaded in the client process or will the component be a remote server for a distributed application? In the former case, the component is compiled as a Dynamic Link Libraries (DLL) while in the latter case it is a standard executable. 
+
 ==In-process Components==
-Typical instances of DLL components are found in technologies such as OCX, ActiveX, or ASP. These are small, downloadable binaries that will be loaded and executed in a container. The container acts as a client of the component. The EiffelCOM wizard provides the ability to wrap such components by providing access to its interface to any Eiffel container. It is also possible to create a new In-process component in Eiffel. 
+
+Typical instances of DLL components are found in technologies such as OCX, ActiveX, or ASP. These are small, downloadable binaries that will be loaded and executed in a container. The container acts as a client of the component. The EiffelCOM wizard provides the ability to wrap such a component by providing access to its interface to any Eiffel container. It is also possible to create a new In-process component in Eiffel. 
 One main difference with out-of-process components (other than the nature of the module, DLL versus executable) is the way in-process components are activated. In the case of out-of-process components, the component will specify COM when it is ready to receive calls from client. In the case of an in-process server the call is coming directly from COM: COM first loads the DLL into the client process and then calls the exported function DllGetClassObject to access the component class object. The other three exported functions of an in-process component are DllRegister to register the component in the Windows registry, DllUnregister to unregister the component from the registry and finally DllCanUnloadNow which gets called by COM whenever it tries to unload the component from memory. These four functions must be accessible from outside the DLL for the in-process component to work properly. 
-</div><div> 
+ 
 ==Out-of-process Components==
-These components are standard executable acting as servers that can be accessed locally or over a network. Typically used in a three tier client server architecture, the major difference with in-process servers (other than the module type - executable instead of DLL) is their lifetime. In-process components are typically loaded to achieve a specific task and unloaded just after while out-of-process components are servers supposed to run continuously. The EiffelCOM wizard allows to build clients for such servers in Eiffel. It also provides the ability to create such servers. </div>
+These components are standard executable acting as servers that can be accessed locally or over a network. Typically used in a three tier client server architecture, the major difference with in-process servers (other than the module type - executable instead of DLL) is their lifetime. In-process components are typically loaded to achieve a specific task and unloaded just after while out-of-process components are servers supposed to run continuously. The EiffelCOM wizard allows to build clients for such servers in Eiffel. It also provides the ability to create such servers. 
+
 {{seealso|<br/>
-[[EiffelCOM Wizard|EiffelCOM wizard]]  <br/>
 [[EiffelCOM Library| EiffelCOM library]]  <br/>
 [[EiffelCOM: Introduction| Introduction]]  <br/>
 [[Generalities|Generalities]]  <br/>

documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/eiffelcom-introduction.wiki

@@ -1,11 +1,12 @@
 [[Property:title|EiffelCOM: Introduction]]
 [[Property:weight|0]]
 [[Property:uuid|adadc51d-3dec-320a-9405-0842eacca4f7]]
-This chapter covers enough information about COM for Eiffel developers to use the EiffelCOM wizard in an effective way. It does not cover all of COM since it would require an entire book but presents the main concepts needed to understand how to build an EiffelCOM system. 
+This chapter attempts to cover enough information about COM for Eiffel developers to use the EiffelCOM wizard in an effective way. It does not cover all of COM ... that would (and does) require volumes. Still, this chapter presents the main concepts needed to understand how to build an EiffelCOM system. 
 
-Briefly said, the Component Object Model is a Microsoft binary standard that establishes how two binary units can access each other at runtime. Such binary units can run in the same process, in different processes on the same machine, or even on different machines. Components can be implemented in any language as long as the compiler produces COM standard compliant binaries. 
+Briefly stated, the Component Object Model is a Microsoft binary standard that establishes how two binary units can access each other at runtime. Such binary units can run in the same process, in different processes on the same machine, or even on different machines. Components can be implemented in any language as long as the compiler produces binaries compliant with the COM standard. 
+
+The advantages of such an approach include an increased reusability (binary reuse), a better version management (COM standard implies that new component versions are compatible with the older ones), and a built-in runtime environment. The binary reuse aspect of COM, augmented with the software quality of Eiffel, offers the developer a platform for increased productivity. 
 
-The advantages of such an approach include an increased reusability (binary reuse), a better version management (COM standard implies that new component versions are compatible with the older ones) and a built-in runtime environment. The binary reuse aspect of COM added with the source reuse ability of Eiffel offer the developer an ideal platform to increase considerably their productivity. 
 
 {{seealso|<br/>
 [[EiffelCOM Wizard|EiffelCOM wizard]]  <br/>

documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/index.wiki

@@ -4,8 +4,7 @@
 [[Property:uuid|32e79152-1e8f-43cd-e014-a83aab18e440]]
 ==About COM and Eiffel==
 
-{{seealso| '''See Also''' <br/>
+{{seealso|[[EiffelCOM Library| EiffelCOM library]]  }}
-[[EiffelCOM Library| EiffelCOM library]]  }}