In the beginning, there was the Z-Machine, and it was good.
Well, sort of. By the mid 1990s, the Z-machine was starting to show its age. Though capable of producing games several times the size of anything Infocom ever released, increasing numbers of people were smacking their heads against its limitations in memory, either because of megalithic games, or because the Inform language, by providing a more general and more powerful library, uses more space than Infocom's games.
It was eventually decided that, rather than implementing another ad hoc extension to the Z-machine, it would be a good idea to create an entirely new virtual machine format. This format, created by Andrew Plotkin, was dubbed Glulx.
In the mean time, a number of people had expressed the desire to improve the multimedia capabilities of the Z-machine. Though the version 6 format provides for complicated screen models and provides a graphics capability, difficulties in implementing the version 6 standard led to a restriction in the availability of compatible interpreters. At the time of this document, only two modern interpreters, Frotz and Zip2000, support the V6 screen model with any degree of accuracy. Both interpreters are limited in their availability; Frotz's v6 support is poor except under MS-DOS (a new release of the interpreter, called Windows Frotz 2002, provides extremely good V6 support under Windows, but is still alpha software, and lacks many of the conveniences of other modern interpreters) and Zip2000 is only available for RiscOS. Moreover, the memory model used by version 6 of the Z-Machine is not easily compatible with assumptions made by the Inform compiler; its maxium size is limited to 320k unless a patched version of the compiler is used. With the increase in popularity of Hugo and the advent of HTML TADS, the multimedia capabilities of the Z-Machine, which had been ignored for so long as to have been forgotten, were seen as a deficit (At the time of writing, only one Inform game, aside from proof-of-concept demos, makes any use at all of Inform's multimedia abilities).
In order to give Glulx the potential to support the kind of multimedia and interface abilities desired, Glulx uses an API called Glk (also by Andrew Plotkin) for its input and output. The immediate side effect of this design is that, for any system which has a Glk port, the Glulx interpreter can also be ported with a near-trivial effort.
Glk, though very clever, and useful in many respects, places a large number of restrictions on what sorts of things are available, for the sake of maintaining portability. For example, windows are not allowed to overlap, and text cannot be rendered in an arbitrary color. (Additionally, though mouse input is supported, it is not possible to determine the position of the mouse, except when a mouse button is pressed. The mouse is assumed, for the sake of portability, to have only one button, whereas the Version 6 of the Z-Machine allows for the possibility of a mouse with as many as thirteen buttons) Indeed, it is not possible to fully implement the version 6 screen model in Glk.
In Glulx, the Glk screen model is accessed via the @glk opcode. With John Cater's 'infglk.h' wrapper library, users of Glulx Inform can perform Glk operations via the Glk API function calls, and is generally considered a "must-have" extension for anyone interested in Glk programming under Glulx Inform. However, the standard library makes no attempt to provide the casual user with a high-level framework for manipulating Glk.
Which is why GWindows exists.