$32.2 PORTABILITY AND PLATFORM ADAPTATION 1067 Graphical libraries Platform-independent library (Vision) architecture (See a similar archi tecture for concur- WEL MEL PEL rency:page 970.) (Windows) (Motif) (Presentation ■■■■■■■■■1■■■ Manager) To make things more concrete the figure shows the names of the corresponding components in ISE's environment,but the idea is applicable to any graphical library.At the top level (Vision)there is a portable graphical library;at the bottom level you find specialized libraries,such as WEL for Windows,adapted to one platform only. See "AN APPLICA- WEL and other bottom-level libraries can be used directly,but they also serve as the TION:THE HANDLE platform-dependent component of the top level:Vision mechanisms are implemented TECHNIQUE”,24.3. page 817. through WEL on Windows,MEL on Motif and so on.This technique has several advantages:for the application developers,it fosters compatibility of concepts and techniques;for the tool developers,it removes unneeded duplications,and facilitates the implementation of the top level (which relies on clean,abstract,assertion-equipped and inheritance-rich O-O libraries such as WEL,rather than interfacing directly with the C level,always a dangerous proposition).The connection between the two levels relies on the handle design pattern developed in an earlier chapter. Application developers have a choice of level: If you want to ensure portability,use the higher layer.This is also of interest to developers who,even ifthey work for a single platform,want to benefit from the higher degree of abstraction provided by high-level libraries such as Vision. If you want to have direct access to all the specific mechanisms of a platform (for example the many "controls"provided by Windows NT),go to the corresponding lower-layer library. The last comment touches on a delicate issue.How much platform-specific functionality do you lose by relying on a portable library?The answer is necessarily a tradeoff.Some early portable libraries used an intersection (or "lowest common denominator")approach,limiting the facilities offered to those that were present in native form in all the platforms supported.This is usually not enough.At the other extreme the library authors might use the union approach:provide every single mechanism of every supported platform,using explicit algorithms to simulate the mechanisms that are not natively available on a particular platform.This policy would produce an enormous and redundant library.The answer has to be somewhere in-between:the library authors must decide individually,for every mechanism present on some platforms only,whether it is important enough to warrant writing a simulation on the other platforms.The result must be a consistent library,simple enough to be used without knowledge of the individual platforms,but powerful enough to produce impressive visual applications.§32.2 PORTABILITY AND PLATFORM ADAPTATION 1067 To make things more concrete the figure shows the names of the corresponding components in ISE’s environment, but the idea is applicable to any graphical library. At the top level (Vision) there is a portable graphical library; at the bottom level you find specialized libraries, such as WEL for Windows, adapted to one platform only. WEL and other bottom-level libraries can be used directly, but they also serve as the platform-dependent component of the top level: Vision mechanisms are implemented through WEL on Windows, MEL on Motif and so on. This technique has several advantages: for the application developers, it fosters compatibility of concepts and techniques; for the tool developers, it removes unneeded duplications, and facilitates the implementation of the top level (which relies on clean, abstract, assertion-equipped and inheritance-rich O-O libraries such as WEL, rather than interfacing directly with the C level, always a dangerous proposition). The connection between the two levels relies on the handle design pattern developed in an earlier chapter. Application developers have a choice of level: • If you want to ensure portability, use the higher layer. This is also of interest to developers who, even if they work for a single platform, want to benefit from the higher degree of abstraction provided by high-level libraries such as Vision. • If you want to have direct access to all the specific mechanisms of a platform (for example the many “controls” provided by Windows NT), go to the corresponding lower-layer library. The last comment touches on a delicate issue. How much platform-specific functionality do you lose by relying on a portable library? The answer is necessarily a tradeoff. Some early portable libraries used an intersection (or “lowest common denominator”) approach, limiting the facilities offered to those that were present in native form in all the platforms supported. This is usually not enough. At the other extreme the library authors might use the union approach: provide every single mechanism of every supported platform, using explicit algorithms to simulate the mechanisms that are not natively available on a particular platform. This policy would produce an enormous and redundant library. The answer has to be somewhere in-between: the library authors must decide individually, for every mechanism present on some platforms only, whether it is important enough to warrant writing a simulation on the other platforms. The result must be a consistent library, simple enough to be used without knowledge of the individual platforms, but powerful enough to produce impressive visual applications. WEL (Windows) MEL (Motif) PEL (Presentation Manager) Platform-independent library (Vision) Graphical libraries architecture (See a similar archi￾tecture for concur￾rency: page 970.) See “AN APPLICA￾TION: THE HANDLE TECHNIQUE”, 24.3, page 817