diff --git a/documentation/current/eiffelstudio/eiffelstudio-guided-tour/compiling-and-executing-system.wiki b/documentation/current/eiffelstudio/eiffelstudio-guided-tour/compiling-and-executing-system.wiki index 4118ac0a..5061e19e 100644 --- a/documentation/current/eiffelstudio/eiffelstudio-guided-tour/compiling-and-executing-system.wiki +++ b/documentation/current/eiffelstudio/eiffelstudio-guided-tour/compiling-and-executing-system.wiki @@ -40,8 +40,10 @@ The system doesn't do anything exciting, but let's execute it anyway. Find the e It would be OK too to use the neighboring icon to the left, "Run without breakpoints", since we haven't set any breakpoints. Click either icon to execute the system. This little application doesn't use graphics or anything fancy but simply creates some objects and displays some information. Output done using the default Eiffel I/O (from the EiffelBase classes ANY and STANDARD_FILES ) goes to a console. On Unix/Linux and VMS it's the window from which you started EiffelStudio. On Windows it's by default a new console window that comes up when and if the system does its first output operation, and stays up: - [[Image:index-6]] [[general/guided_tour/studio/index-6.png|(link)]] -The message " Press Return to finish the execution " would not appear if you executed the system from outside of EiffelStudio, for example from a command line. Its purpose within EiffelStudio is clear: to let you see the console output; without it, the console would go away at the end of execution. (None of this applies to Unix/Linux/VMS since there is no new console window to get rid of.) + +[[Image:index-6]] + +The message " Press Return to finish the execution " would not appear if you executed the system from outside of EiffelStudio, for example from a command line. Its purpose within EiffelStudio is clear: to let you see the console output; without it, the console would go away at the end of execution. (None of this applies to Unix/Linux/OpenVMS since there is no new console window to get rid of.) If before closing the console window you look at the main EiffelStudio window (by moving away the console window) you will notice that it looks different from before, since it now shows the fields useful in monitoring execution and debugging. But we'll look at this later. For the moment just dismiss the console by following the advice to " Press Return ": hit the Return or Enter key. diff --git a/documentation/current/method/eiffel-tutorial-et/et-hello-world.wiki b/documentation/current/method/eiffel-tutorial-et/et-hello-world.wiki index 15e9626b..4162a8a7 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-hello-world.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-hello-world.wiki @@ -71,7 +71,7 @@ To build the system and execute it: * Click the "Compile" icon. * Click the "Run" icon. -Execution starts and outputs Hello World on the appropriate medium: under Windows, a Console; under Unix or VMS, the windows from which you started EiffelStudio. +Execution starts and outputs Hello World on the appropriate medium: under Windows, a Console; under Unix or OpenVMS, the windows from which you started EiffelStudio. diff --git a/documentation/current/method/eiffel-tutorial-et/et-static-picture-system-organization.wiki b/documentation/current/method/eiffel-tutorial-et/et-static-picture-system-organization.wiki index 68822659..cd42257d 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-static-picture-system-organization.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-static-picture-system-organization.wiki @@ -3,7 +3,7 @@ [[Property:weight|-11]] We now look at the overall organization of Eiffel software. -References to Eiffel Software's libraries appearing in subsequent examples include: '''EiffelBase''', the fundamental open-source library covering data structures and algorithms; the '''kernel library''', a subset of EiffelBase covering the most basic notions such as arrays and strings; and '''EiffelVision 2''', an advanced graphics and GUI library providing full compatibility across platforms (Unix, Windows, VMS) with native look-and-feel on each. +References to Eiffel Software's libraries appearing in subsequent examples include: '''EiffelBase''', the fundamental open-source library covering data structures and algorithms; the '''kernel library''', a subset of EiffelBase covering the most basic notions such as arrays and strings; and '''EiffelVision 2''', an advanced graphics and GUI library providing full compatibility across platforms (Unix, Windows, OpenVMS) with native look-and-feel on each. ==Systems== diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/coclass.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/coclass.wiki index b46c07f4..c635528c 100644 --- a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/coclass.wiki +++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/coclass.wiki @@ -3,14 +3,16 @@ 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.
==Class Object== - We have seen that interfaces are accessed through interface pointers. But how does a client get hold on one of these? +We have seen that interfaces are accessed through interface pointers. But how does a client get hold on 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. - [[Image:com-1|Component Creation]] + +[[Image:com-1|Component Creation]] + The code for the class object is generated by the EiffelCOM wizard so that Eiffel programmers will not have to worry about it. -{{seealso| '''See Also'''
+{{seealso| [[EiffelCOM Wizard|EiffelCOM wizard]]
[[EiffelCOM Library| EiffelCOM library]]
[[EiffelCOM: Introduction| Introduction]]
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/deeper-com.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/deeper-com.wiki new file mode 100644 index 00000000..f11a4011 --- /dev/null +++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/deeper-com.wiki @@ -0,0 +1,31 @@ +[[Property:title|Deeper into COM]] +[[Property:weight|6]] +The next paragraph gives some details on the COM internals. The understanding of these details are not required to use the EiffelCOM wizard but might help making better decisions when designing new EiffelCOM components. + +==Apartments== +The first interesting subject that requires more in-depth cover is the execution context of a component. Components can be run in the same process as the client but can also run in a separate process even on a different machine. +This superficial description only take into accounts processes. What happens if a component uses multithreading to achieve it tasks? In a case of a remote server, this scenario does not seem too esoteric. The problem is that a server does not (and should not) know in advance what its clients will be. It cannot assume that the client will be able to take advantage of its multithreading capabilities. Conversely a multithreaded client should not rely on the server ability to handle concurrent access. + +The solution chosen in the COM specification is to define an additional execution context called an apartment. When COM loads a component it creates the apartment in which the component will run. Multiple instances of a multithreaded component will leave together in the same apartment since asynchronous calls will be handled correctly and there is no need to add any synchronization layer. On the other hand, single threaded component will be alone in their apartment and any concurrent calls coming from clients will be first synchronized before entering the apartment. These two behaviors define two different kinds of apartments: Multi Threaded Apartments (MTA) and Single Threaded Apartments (STA). +
[[Image:com-2|Apartments]]
Apartments solve the problem of concurrency by removing the necessity of knowing the multithreaded capability of a component and its clients. Multithreaded clients can always make asynchronous calls and depending on whether the component handles concurrent access or not, they will be forwarded or first synchronized. There can be multiple instances of STA running in one process while there will be at most one MTA. +==Marshaling== +At this point you might wonder how calls can "cross" the apartments boundaries. Components from a STA can make calls to components running in a MTA and vice versa. These apartments might be running in different processes or even on different machines. The approach chose in the COM specification is using the proxy and stub patterns. +The idea is to trick the client of an interface by providing an interface proxy in its apartment. The proxy include exactly the same function as the interface itself but their implementation will just forward the call to the actual interface. The client has no idea whether the entity it is dealing with is the actual interface or just a proxy. One of the main interest of that approach is that the client implementation is independent from the location of the component. + +Last explanation is not totally accurate: the call will not be forwarded to the actual interface but to its stub. The stub is the counterpart of the proxy, it represents the client for the interface. The interface doesn't know either whether it is communicating with the actual client or a stub. Although it is not totally true that the component implementation is independent from the location of the client, the stub pattern still helps keeping code identical for the implementation of the interface themselves. The implementation of a component will still be different whether it is an in-process or out-of-process component since it will have to be a DLL in one case and a executable in the other. The design of the interfaces might also differ since out-of-process servers will tend to avoid too many round trips. +
[[Image:com-3|Cross Apartment Calls]]
There is one proxy/stub pair per interface. The proxy or the stub is loaded dynamically only when needed. This proxy/stub pair constitute the marshaller. The reason for having a single name for two different things come from how MIDL generates its code. MIDL will produce files for one DLL in which both the proxy and the stub will be included. This DLL is the marshaller.
+==Summary== +This brief introduction to the Component Object Model should be enough to get started with the EiffelCOM wizard. It specifies the main characteristics that define the type of a component and that need to be given to the wizard along with the definition file.
+{{seealso| +[[EiffelCOM Wizard|EiffelCOM wizard]]
+[[EiffelCOM Library| EiffelCOM library]]
+[[Generalities| Generalities]]
+[[Deeper into COM| Deeper into COM]]
+[[COM Interfaces| COM Interfaces]]
+[[Coclass| Coclasses]]
+[[The Component Location| Component Location]]
+[[Access Type| Access Type]] }} + + + + diff --git a/documentation/current/why-eiffel/why-your-next-project-should-use-eiffel.wiki b/documentation/current/why-eiffel/why-your-next-project-should-use-eiffel.wiki index 684be96b..0e7c86e8 100644 --- a/documentation/current/why-eiffel/why-your-next-project-should-use-eiffel.wiki +++ b/documentation/current/why-eiffel/why-your-next-project-should-use-eiffel.wiki @@ -31,7 +31,7 @@ The next few sections give a glimpse of the technical contributions of Eiffel, o Eiffel has plenty of these. It has been around for more than a decade. Eiffel is available from several commercial and open-source providers. The number of licenses sold is in the tens of thousands. Reusable library classes are in the thousands. -The platforms covered range from Unix (all of Unix, the famous and the arcane) and Linux to VMS, OS/2, Windows 3. 1, Windows NT, Windows 95/98. +The platforms covered range from Unix (all of Unix, the famous and the arcane) and Linux to OpenVMS, OS/2, Windows 3. 1, Windows NT, Windows 95/98. Particularly impressive is the growth of Eiffel usage in education. Eiffel is quickly becoming the language of choice for teaching modern software technology, including, increasingly, introductory programming. A dozen of excellent textbooks are now available from Prentice Hall, Addison-Wesley, Macmillan and others, with about as many announced just for the coming months.