| Wabi | |
| Developer: | Sun Microsystems |
| Operating System: | Solaris, AIX, HP-UX, SCO OpenServer, Linux |
| Genre: | Middleware |
| Website: | Wabi™ Software |
Wabi is a discontinued commercial software application from Sun Microsystems that implements the Windows Win16 API specification. Wabi runs applications developed for Windows 3.1, Windows 3.11, and Windows for Workgroups, interpreting and translating x86 instructions where appropriate, but without providing emulation support for DOS or PC hardware.
Wabi was originally released for Solaris, with versions following for AIX, HP-UX and SCO OpenServer. A version for Linux was also released by Caldera.
The technology was originally developed by Praxsys Technologies as the result of discussions in 1990 with Interactive Systems Corporation. The assets of Praxsys were acquired by Sun in the fall of 1992.[1] Originally referenced in publicity as WABI, short for Windows Application Binary Interface,[2] [3] the product was eventually known as Wabi, reportedly to avoid trademark issues.[4] Another connotation given to the name is its meaning in Japanese aesthetics, given as "quiet taste" in SunSoft's own literature, with the original WABI acronym being acknowledged as "a fair description of what Wabi is".[5]
Originally demonstrated by SunSelect, a division of Sun Microsystems, at the 1992 Fall Comdex show, the product was described as leveraging the Windows API to be able to "separate the software from the hardware", allowing RISC workstation vendors such as Sun to provide greater performance running Windows applications than such applications exhibited on conventional Intel-based personal computers. This use of the Windows API meant that Wabi was not able to run DOS applications, unlike other solutions such as the company's existing SunPC product based on technology licensed from SoftPC creator Insignia Solutions.[2]
Announced in May 1993, Wabi was to be offered at no cost to Solaris purchasers during that year.[3] Later in 1993, IBM obtained the right to offer the software on its own RS/6000 workstation range in exchange for granting Sun access to "certain IBM technology to enhance WABI further".[6] Sun announced Wabi 1.1 in April 1994, having shipped only 30,000 copies of Wabi 1.0. Offering "significantly enhanced stability and reliability" over the previous version, Hewlett-Packard and IBM were also to provide the updated software on their own systems. Wabi 2.0 was promised as a further upgrade in the summer of 1994, supporting a larger number of certified applications than the 13 titles of the original release.[7]
By late 1994, Sun had reported shipping 100,000 copies of Wabi bundled at no extra cost with Solaris 2. Meanwhile, HP and IBM offered the product as an optional extra, charging $ and $ respectively.[8] Wabi 2.0 eventually broadened application support to 24 titles, these reportedly accounting for "over 80 percent of the commercial Windows applications market".[9] SCO also offered Wabi as an option for its OpenServer Release 5 products,[10] specifically Wabi 2.0.[11]
Sun improved the product further and released Wabi 2.1 in 1995, introducing multimedia capabilities such as the handling of audio and video, as well as ODBC support in Windows applications. Alongside this, Sun upgraded its version of Merge, offered to run DOS applications, announced a deal with Merge's creator, Locus Computing Corporation, for continued development of that product, and introduced a faster CPU in its SunPC expansion card. The company indicated that with the introduction of Windows 95, anticipating that sufficient demand for Windows 95 applications would be met with an updated version of Wabi supporting such applications within a year of the release of Windows 95.[12] Sun also introduced WabiServer, providing a means of running Windows applications in Wabi on a server, with clients accessing those applications over a network. This permitted X terminals and low-end SPARC systems, including those running SunOS, to take advantage of the software.[13]
Wabi 2.2 was licensed from SunSoft by Caldera in 1996 as part of that company's Linux strategy,[14] releasing the software in November of that year,[15] being sold as a product for various Linux distributions.[16] Wabi development was discontinued in December 1997,[17] with only "sustaining engineering" being performed beyond this date. Wabi 2.2 revision E was the final Sun-issued version of the product, available only for Solaris 2.6.[18]
Other solutions sought to provide similar functionality to Wabi. The Willows Toolkit, previously known as TWIN APIW, provided the Willows Application Programming Interface (WAPI) consisting of a Willows Binary Interface capable of hosting existing Windows applications, the Willows Library implementing the Windows API, and the Willows Driver implementing three functional subsystems performing window management, graphical operations, and access to native system functionality.[19] Wine was also already in development at the time of Wabi's discontinuation, although both Wine and the Willows Toolkit were unable to provide a similar level of experience to that delivered by Wabi at that point in time.[20]
In its initial form, Wabi was intended to be able to run certified applications, these having been tested to establish correct operation, without any need for any Windows software.[4] However, Wabi 2.0 explicitly supported Windows 3.1 itself as a certified application, and an installation of Windows was reported as a helpful measure in addressing the shortcomings of previous versions of the software.[9] Wabi 2.1 added support for Windows for Workgroups 3.11.[5]
To support programs written for the Windows API, Wabi provides library routines for published or documented API calls that perform the equivalent work in the host environment, this being Solaris in the version of the product for Sun's own workstations.[21] In contrast to other approaches, notably Insignia's SoftWindows and related products, hosted applications employ native software components, resulting in Windows applications appearing in their own windows within the X Window System environment, as opposed to appearing in a Windows desktop session confined to a single native window.[22]
Wabi implements the lowest layers of the Windows environment in the form of the user.dll, kernel.dll, and gdi.dll libraries. All other Windows dlls depend on these three modules, so cloning this functionality allows Windows software to execute correctly on a foreign host system. This approach, as opposed to a full replacement, was thought by the engineering team to be the only rational methodology for success given both the size of Microsoft's ever-expanding efforts and the difficulties of the emulation being precise enough to run commercial software.
Wabi was released for Solaris SPARC, x86 and PowerPC systems,[23] as well as on PowerPC systems running AIX,[24] PA-RISC systems running HP-UX,[25] and on x86 and SPARC systems running Linux.[16] To run an x86 Windows environment on SPARC and other RISC systems, a code translation layer dynamically converts x86 instructions upon first use into SPARC or other native instructions.[26]
DOS and PC hardware emulation are not provided by Wabi, but Caldera'a version of the software permitted the use of a DOS emulator, provided by the DOSEMU package, to allow the Windows Program Manager to launch a DOS command session from its MS-DOS Prompt icon.[27]
Since Wabi implemented and thus depended on the usage of "published, well-known" Windows API calls by applications, it remained sensitive to instances of undocumented API usage by applications with "intimate knowledge of the Windows environment" that would refuse to run correctly.[21] Despite the use of techniques that accelerated Windows applications when run under Wabi when comparing a Solaris on Intel system with one running Windows on identical hardware,[22] users reported that application performance varied, with some applications performing too slowly.[7]
Meanwhile, an impression had been established that undocumented Windows calls were being exploited by application developers, Microsoft in particular, to gain a form of competitive advantage. Indeed, in response to claims to this effect, prompted by the publication of a book, Undocumented Windows, Microsoft confirmed that its own applications did use such calls, claiming that since such practices were widespread, no advantage had been gained.[28] Following industry experience with the DOS API as a de-facto standard, with multiple implementations and supported by multiple environments, and with efforts such as Wabi seeking to support the Windows API across multiple environments, an argument was made for considering both DOS and Windows, or at least their APIs, as "sufficiently generic, and sufficiently important, to deserve something like ANSI standards committees".[29]
In conjunction with its development of the Wabi software, Sun initiated the Public Windows Interface effort to create such a public standard, enlisting several other companies including systems vendors such as IBM, ICL and Toshiba, operating systems vendors such as SCO and Unix System Laboratories, and application developers such as Corel and WordPerfect Corporation. Sun's Scott McNealy claimed that Sun had effectively "documented the Windows API for Microsoft", submitting it to X/Open for consideration as an industry standard.[30] Developed from public specifications and maintained by an international standards organisation, such a standard was regarded as being free from the assertion of Microsoft's copyright and patents.[31]
Sun had reportedly but unsuccessfully sought some form of licensing arrangement with Microsoft for access to Windows technologies in early 1993.[32] Microsoft's Bill Gates claimed in response to Sun's initiative that the same information was already available in "a $9 book at the local bookstore", nevertheless considering a legal response after reviewing the released Wabi product.[33] In response to the threat of this initiative and Wabi, Microsoft "launched a preemptive strike" by licensing Windows source code to Insignia Solutions, leading to the release of its SoftWindows product.[22] This was part of a broader licensing effort seeking to appeal to selected companies looking to run Windows solutions on Unix systems.[30]
Despite Sun's contention that there was no intellectual property breach, the Public Windows Interface effort was obstructed by Microsoft lobbying directed towards various standards bodies, effectively curtailing this standardisation attempt.[34]