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

  Unfortunately, DOS does not provide much in the way of video output
  services. In fact, the available DOS services are limited to a
  character-only, "glass teletype" interface that is rapidly becoming an
  anachronism in these days of high-resolution color graphics.

  To achieve attractive, high-performance video output, you must rely on the
  ROM BIOS or on direct programming of the video hardware. As we have seen,
  IBM has maintained a fairly consistent programming interface to its video
  hardware, so many programmers make a practice of bypassing DOS and using
  lower-level video programming techniques.

  But when you bypass DOS, you encounter a problem: Two different programs
  can't reliably share the video hardware. Consider what can happen, for
  example, if you write a program that configures the video hardware in a
  way that conflicts with the configuration used by a memory-resident
  "pop-up" program like SideKick. If your program runs in a video mode that
  the pop-up program doesn't recognize, the pop-up program's output may
  appear incomprehensible on the screen. Worse, the pop-up program may
  reconfigure the video subsystem for its own purposes and leave your
  program's video output in limbo.

  The problem is amplified in multitasking operating environments, such as
  Microsoft Windows or OS/2, where programs generally share access to the
  screen. In these environments, a program can bypass the operating system
  and gain complete control of the screen only if the operating system
  suspends video output from all other concurrently executing programs. Thus
  a program that ties up the video hardware can delay the multitasking
  execution of background programs.

  The designers of OS/2 and Microsoft Windows attacked this problem by
  providing a sophisticated gamut of video output services. These video
  output services not only resolve conflicts between programs that want to
  access the video display, but they also provide very good performance. To
  get the best video performance in the world of DOS, however, you must
  either resort to ROM BIOS calls and direct hardware programming or else
  rely on the video output services provided by your programming language
  (which themselves bypass DOS).

  When trying to decide which method to use, you should consider the
  probable lifetime of your programs and the range of machines they might be
  used on. For a PC-specific game program with an expected life of a few
  months (common for games), you have little reason to worry about these
  issues. This is not the case for a generalized business or professional
  application, which should be usable for many years and in many
  environments. Make your choice and place your bets.