OK, I've plugged in the existing disk video code into my Win32 driver and its limping along. Its not fully debugged yet and it still crashes after playing with it for a little while, but its a good milestone. The following screens appear to be working properly: - intro screen - parameter screens (x, y, z, etc.) - select video mode screen - help screens(*) - tab screen(*) (*) has some display weirdness, but is functional. Its interesting how FractInt deals with video and screen resolutions. FractInt has what you might call the "AutoCad model" for device independence -- a little bit of code is written for each supported video device and glued into the application. The glue allows the application to use a single API abstraction to deal with a video card. The assembly routines in video.asm form the "API" that's used by the C code to interact with the video card. The assembler code in turn depends on BIOS routines for some of its tasks and writes directly into video memory for others. XFractint ditched all of this code and hacked up a single video mode whose pixel dimensions are specified by the -geometry flag. The branch uses a hybrid approach. Each driver is initialized in the application startup process. During initialization a driver can add video modes to the list of supported video modes. This lets each driver provide a set of typical resolutions like 320x200, 640x480, 800x600, etc. It also allows drivers like the full screen DirectX driver to enumerate the full-screen video modes it supports. Ironicly, a full-screen DirectX driver would be most like the feeling of the DOS application since "switching to graphics" most likely involves a change in the scan rate for the monitor giving that familiar "click click" as the monitor switches from text (desktop, really, in Win32) to graphics modes. The driver model I'm putting in has given me some interesting ideas, both forward looking and "retro". In the forward looking direction we have the XNA Game Studio Express framework from Microsoft that lets anyone write applications for the Xbox 360. At the moment, this toolkit only supports C#, so the code would have to be transliterated into C# from C. Essentially FractInt would become one giant class iwth static data members and static methods. In the retro direction, and this would be easier to achieve, I have a number of Tektronix 4105 and 4205 serial terminals. These are terminals with a color text screen and a color graphics screen. A driver could be written to perform all I/O through the terminal via the serial port. Here the irony is that the I/O model of the original FractInt code most closely matches the I/O model of a 1980s terminal :-). -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>