Click above to get retro games delivered to your door ever month!

  If you want your program to run on a wide variety of PCs and PS/2s, you
  must design compatibility into the program. As the various IBM video
  subsystems have evolved, programmers have developed several approaches to
  compatibility. These include

  .  Installable programs

  .  Self-installing programs

  .  Hardware-independent programming environments

  We've already mentioned how many software vendors provide video
  compatibility by distributing software that has its video output routines
  in separate, installable modules: Before the software can be used, the
  video routines must be linked to the rest of the application. This lets
  you write programs that take full advantage of each video subsystem's
  capabilities without sacrificing compatibility.

  However, the installation process can be cumbersome, both for a programmer
  who must write the installation program and for an end-user who must
  install video routines properly. You can eliminate the installation
  process if you make your application self-installing. The key to doing
  this is to incorporate a routine in your program that identifies which
  video subsystem the program is running on. The program can then tailor its
  own video output to the capabilities and limitations of the video
  hardware.

  You can use several different programming techniques to identify the video
  subsystem. In PS/2s, ROM BIOS offers a service that reports the video
  hardware configuration (see Chapter 9), but in the PC/XT/AT family you
  must rely on improvised hardware identification techniques documented in
  the hardware technical manuals.

  Once a program has determined the video hardware configuration, it can
  produce appropriate output. For example, a program running on a Monochrome
  Display Adapter can use only one video mode with monochrome attributes. If
  the same program were running on a color subsystem, it could run with
  color attributes in text modes. If the program needed to produce graphics
  output, it could select a graphics mode with the highest possible
  resolution based on its identification of the video subsystem.

  In the simplest case, your program can use whatever video mode is in use
  when the program starts up. ROM BIOS interrupt 10H, service 0FH reports
  the current video mode number. If you're not using an assembly-language
  interface to the ROM BIOS, however, you may find it easier simply to use
  the program on the following page to inspect the ROM BIOS status variable
  at 0040:0049H that contains the video mode number.

  10 DEF SEG = &H0040
  20 VIDEO.MODE = PEEK(&H0049)

  You can avoid video hardware dependence in your programs if you use an
  operating environment like Digital Research's GEM or Microsoft Windows.
  These environments shield your program from the idiosyncrasies of video
  hardware by providing a set of consistent, hardware-independent
  subroutines to perform video I/O. The problem, of course, is that the
  end-user must also have a copy of the operating environment to be able to
  run your program.

  Whatever approach you take to video compatibility, be sure to consider
  several compatibility criteria. These criteria are not completely
  consistent with each other, reflecting the internal inconsistency in the
  design of the IBM personal computer and the variety of display formats
  that can be used. Still, there are overall guidelines for compatibility,
  which we'll outline here.

  First, text-only display output increases compatibility. Many PCs are
  still equipped with Monochrome Display Adapters, which cannot show graphic
  output. If you are weighing a text-versus-graphics decision in the design
  of a program, there are two factors to consider. On one hand, as many
  programs have dramatically demonstrated, you can create very effective
  drawings using only standard IBM text characters. On the other hand, it is
  more and more common for computers to include graphics capability. So, in
  the future, text-only output will probably lose its importance, and you'll
  be able to use graphics in your programs without worrying about
  compatibility.

  Second, the less your programs depend on color, the wider the range of
  computers with which they will be compatible. This does not mean that you
  need to avoid color for compatibility; it simply means that for maximum
  compatibility, programs should use color as an enhancement rather than as
  an essential ingredient. If programs can get along without color, they
  will be compatible with computers that use monochrome displays, including
  PCs with Monochrome Display Adapters, as well as Compaq Portable computers
  with built-in monochrome displays.

  In general, you must weigh the advantage of broad compatibility against
  the convenience and simplicity of writing programs for a narrower range of
  displays. Our own experience and judgment tell us that far too often
  programmers err by opting for a narrower range of displays, thereby
  greatly reducing the variety of computers their programs can be used on.
  Be forewarned.