Most, if not all, of the products in this FAQ take one of three approaches to providing platform independence. The two most common approaches are the "layered" and the "emulated" user interface but an up-and-coming approach is "API emulated" interface.
Products using a layered interface access native, third party, GUI-building toolkits to provide the look-and-feel compliance for each particular GUI. Layered user interfaces have the advantage that, since they depend on other products which concentrate on a single GUI, they have to provide less software (and, hence, are usually less expensive) than emulated interfaces. Layered interfaces are also more likely to get the native look-and-feel correct on all platforms. Most of the PIGUI products in this FAQ fit in this category.
In an emulated user interface, the PIGUI's resultant code produces low-level calls and all the look-and-feel compliance is handled by the PIGUI software itself (e.g., for OpenWindows support, the software would *NOT* produce an XView program that must be compiled with the XView toolkit; the software would produce code that interfaces directly with X intrinsics). To provide an emulated user interface, a vendor has to develop a lot of extra code for look-and-feel support. Emulated user interfaces have the advantage that someone on a Motif workstation, for example, can see how the Macintosh-style UI will look (since the look-and-feel is part of the product). Emulated interfaces have the opportunity to provide a faster GUI than does a layered interface; in addition, it does not require you to purchase (or learn how to use) other kits to build GUI software.
A third approach to platform independence is emulating one of the supported target's APIs (usually, the Microsoft Windows API) to target other GUIs. With one of these products, one would program using the emulated API and the code would be (to the extent to which that the product provides portability) portable to other GUIs.