Protected Mode Programming vs. Real

wmu...@dmg.ml.com (William Mudge)

Delphi Developer

Wed, 18 Jun 1902 08:00:00 GMT

Protected Mode Programming vs. Real

Regardless of how you compile your program for distribution I strongly recommend that you
develop it using protected mode. You may find the run-time scrutiny annoying at first but you'll
produce more robust code in less time. Memory management or addressing mistakes in real mode
may not cause trouble right away. The same oversights in protected mode often cause immediate
aborts with an error code 216. The underlying defect is often easier to find under these circumstances.

Duncan Murdo

Delphi Developer

Wed, 18 Jun 1902 08:00:00 GMT

Re:Protected Mode Programming vs. Real

Quote

In article <DB9LrA....@tigadmin.ml.com> wmu...@dmg.ml.com (William Mudge) writes:
>Regardless of how you compile your program for distribution I strongly recommend
>that you
>develop it using protected mode. You may find the run-time scrutiny annoying at
>first but you'll
>produce more robust code in less time. Memory management or addressing mistakes
>in real mode
>may not cause trouble right away. The same oversights in protected mode often
>cause immediate
>aborts with an error code 216. The underlying defect is often easier to find
>under these circumstances.

I think the points in favour of pmode development are valid, but there are
also advantages to real mode development, and I think the best practice is a
mix of both. For example, the IDE de{*word*81} works only in real mode. The heap
is smaller, and that may make a difference in how your program runs. It's
much easier to detect heap leaks when running in real mode.

Duncan Murdoch

Mr Anders L

Delphi Developer

Wed, 18 Jun 1902 08:00:00 GMT

Re:Protected Mode Programming vs. Real

Quote

William Mudge (wmu...@dmg.ml.com) wrote:

: Regardless of how you compile your program for distribution I strongly recommend that you
: develop it using protected mode. You may find the run-time scrutiny annoying at first but you'll
: produce more robust code in less time. Memory management or addressing mistakes in real mode
: may not cause trouble right away. The same oversights in protected mode often cause immediate
: aborts with an error code 216. The underlying defect is often easier to find under these circumstances.

But it is real troublesome that stepping thru the code is not supported.
It is a great tool in verify what's going on (right or wrong)

Other Threads

1. Protected mode VS Real mode ???

2. Protected mode vs. Real mode

3. CONVERTING A PROGRAM FROM REAL TO PROTECTED MODE

4. Real Mode from Protected Mode: Accessing an RMode TSR from PMode

5. Vesa unit for all 256 and 65K color modes (protected,real mode)

6. Real mode Interrupts and pointers in Protected Mode

7. Real mode > protected mode, BGI error :-(

8. Detecting Protected/Real mode

9. real /protected mode

10. protected and real mode ?