>P.S. I want to add a "Glosary of therms" to my home page and hope it'll
>grow soon and fast
>        ...so if you're interested to help me please send the therms
>that you know (directly!) in

>>I was wondering which mode should I use - real or protected.
>>What are the difference,advatages and the disadvantages ?

>Hi,
>your message was wonderful: filled with tons of "&nbsp"...
>Real mode programs are smaller and they require no additional support,
>protected mode apps need a loader+extender (rtm.exe) but they can use extended
>memory, not only 1M (640K...) and the direct DOS memory access is harder.

>Borland said, their protected mode compilers work faster. Maybe this applies
>to other DPMI stuff, too.

>In article <68v8rq$i1...@gentiana.datanet.hu>, BandiT <apa...@mol.hu> wrote:
>>Peter Moraliyski  (huibm...@ibm.net) wrote:

>Do not assume. Protected mode is per se slower as loading pointers
>takes much longer.

>>Do not assume. Protected mode is per se slower as loading pointers
>>takes much longer.

>This is only true on 286 and 386 processors.  processors. According to my TASM
>quick reference guide, a LDS/LES/LFS/LGS instruction on a 486 (and presumably
>above) takes the same time (6 or 12 cycles, depending on operand) in both real
>and protected mode. Loading pointers is slower on 286's (7~ vs 21~) and 386's
>(7~ vs 22~).

>>IMO one should use Real mode unless memory is an issue. However, one
>>should write in such a way that converting to DPMI is easy (like just
>>recompiling). Of course one can make two versions like Borland did with
>>TP and TPX (In Turbo Pascal only)

>Yes, real mode is just fine for small apps that don't use much memory, but I
>would still develop a DPMI version for debugging purposes, as protected mode is
>much better at finding those obscure bugs that often go unnoticed in real mode.

> Jay

>[...]

>> Yes, real mode is just fine for small apps that don't use much memory, but I
>> would still develop a DPMI version for debugging purposes, as protected mode is
>> much better at finding those obscure bugs that often go unnoticed in real mode.

>> Jay

>Hi Jay,

>Can you give us more information on all these obscure bugs, and how PMode
>is better at finding them?

> In article: <68vl4u$...@kruuna.Helsinki.FI>  ronka...@cc.helsinki.fi (Osmo
> Ronkanen) writes:

> >In article <68v8rq$i1...@gentiana.datanet.hu>, BandiT <apa...@mol.hu> wrote:
> >>Peter Moraliyski  (huibm...@ibm.net) wrote:

> [...]

> >>Borland said, their protected mode compilers work faster. Maybe this applies
> >>to other DPMI stuff, too.

> >Do not assume. Protected mode is per se slower as loading pointers
> >takes much longer.

> This is only true on 286 and 386 processors.  processors. According to my TASM
> quick reference guide, a LDS/LES/LFS/LGS instruction on a 486 (and presumably
> above) takes the same time (6 or 12 cycles, depending on operand) in both real
> and protected mode. Loading pointers is slower on 286's (7~ vs 21~) and 386's
> (7~ vs 22~).

> > However, when the extra memory it allows becomes an
> >issue then it is faster than solutions using XMS or disk.

> Yes. There is also the overlay issue, which often slows down large real mode
> programs considerably. Sometimes the extra memory available to protected mode
> apps can improve performance very considerably.

> > One thing in which DPMI is clearly slower is starting up.

> Yes. The RTM.EXE DLL has to be loaded and initialized, and the DPMI16BI.OVL DPMI
> server as well if there is no DPMI server presently loaded on the host system.

> >IMO one should use Real mode unless memory is an issue. However, one
> >should write in such a way that converting to DPMI is easy (like just
> >recompiling). Of course one can make two versions like Borland did with
> >TP and TPX (In Turbo Pascal only)

> Yes, real mode is just fine for small apps that don't use much memory, but I
> would still develop a DPMI version for debugging purposes, as protected mode is
> much better at finding those obscure bugs that often go unnoticed in real mode.

> -- Jay

>  --------------------------------------------------------------------------
> | Jason Burgon - author of Graphic Vision, TV-Like GUI for 256 Colour SVGA |
> | g...@jayman.demon.co.uk   ftp://SimTel/msdos/turbopas/gv4svga1.zip         |
> | ***NEW VERSION OF GV AVAILABLE FROM*** -> http://www.jayman.demon.co.uk  |
>  --------------------------------------------------------------------------

>Jason Burgon wrote:

>[...]

>> Yes. There is also the overlay issue, which often slows down large real mode
>> programs considerably. Sometimes the extra memory available to protected mode
>> apps can improve performance very considerably.

>[...]

>I find no difficulties writing "large" programs with overlays.

>First, you learn how to write compact code. This skill helps in many ways
>besides allowing you to do more with less. Since you don't have so much
>source to wade through, it is easier to see what you are doing and to
>modify or troubleshoot your code.

>Third, use OVERXMS to put the overlay in XMS ram. Retrieving it is faster
>than hard disk, and you don't have the problem with SmartDrive demoting
>your overlay and replacing it with more recent files.

>In article <83753747...@jayman.demon.co.uk>,
>Jason Burgon  <Ja...@jayman.demon.co.uk> wrote:

>>According to my TASM quick reference guide, a LDS/LES/LFS/LGS instruction
>>on a 486 (and presumably above) takes the same time (6 or 12 cycles,
>>depending on operand) in both real and protected mode. Loading pointers is
>>slower on 286's (7~ vs 21~) and 386's (7~ vs 22~).

>What do you mean with "depending on operand"? LES only takes memory and
>calculating EA takes constant time.

>Jason Burgon wrote:

>[...]

>> Yes, real mode is just fine for small apps that don't use much memory, but I
>> would still develop a DPMI version for debugging purposes, as protected mode
>> is much better at finding those obscure bugs that often go unnoticed in real
>> mode.

>> Jay

>Hi Jay,

>Can you give us more information on all these obscure bugs, and how PMode
>is better at finding them?

>I am forever trying to move a 255-character string into a string[80] :)

>>In article <83753747...@jayman.demon.co.uk>,
>>Jason Burgon  <Ja...@jayman.demon.co.uk> wrote:

>>>According to my TASM quick reference guide, a LDS/LES/LFS/LGS instruction
>>>on a 486 (and presumably above) takes the same time (6 or 12 cycles,
>>>depending on operand) in both real and protected mode. Loading pointers is
>>>slower on 286's (7~ vs 21~) and 386's (7~ vs 22~).

>>What do you mean with "depending on operand"? LES only takes memory and
>>calculating EA takes constant time.

>I think it means you can have something like "LES DI,[BX]" as well as "LES
>DI,[SomeAddress]. The exact entry from the TASM Quick Ref for LDS is as follows:

>Opcode Instruction    486  386     286     86    Description
>C5 /r  LDS r16,m16:16 6/12 7,pm=22 7,pm=21 16+EA Load DS:r16 with ptr from mem

>Note that the 486 entry uses the normal "register/memory" operand timing
>notation, whereas the 386 and 286 entries use the RealMode,ProtectedMode="
>notation. This could be a typo, but it's a rather blatent one if it is.

>> Moving to segment register (like MOV
>>ES,AX) takes 3 on real and 9 on protected mode according to my source
>>(an opcode list I downloaded). That is 6 cycle overhead in PM.

>Yes this is what my (self-amended) entry in my TASM QR says as well. This
>operation is used rarely though. ie it will be a very small percentage of
>program time used doing this.

>>Are you
>>sure that it is not 6 in RM and 12 in PM? (my source is silent on LES
>>etc. ln PM).

>No, I can't put my hand on my heart and say I'm (or Borland's reference to be
>more precise) correct. It could be a typo.

>>Common sense says that there must be overhead. When one changes segment
>>register in protected mode the processor has to load the data on segment
>>limits and access rights. Unless there is some kind of caching for the
>>data then there must be overhead.

>I would agree, but common sense and Intel processors are uncomfortable bed
>fellows. :-)

>Even if all segment loads are slower in PM, this can be offset (at least in
>large apps) by the fact that you don't need to use overlays, which means you
>don't have to force far calls. A near call/return is much faster than a far call
>(3 or 5 compared to rm=18,pm=20 on a 486).

>The only slowdown I've perceived is when a PM application is repeatedly calling
>the underlying DOS/BIOS via the DPMI. Calling DOS/BIOS functions is of course
>much slower in protected mode. Again though, this slowdown is not percievable in
>many applications because of the relatively low number of DOS/BIOS calls made by
>the program.

>Tech note 1
>===========

>The above is only guaranteed to work if your PM application sets the
>System.HeapLimit variable to 0. This means each heap memory allocation is
>assigned its own selector, with a limit the same size as the memory requested.
>HeapLimit sets the size of BP's sub-allocation block size, and is set to 8192 by
>default. This means the memory manager requests 8K memory blocks from the DPMI
>server, then sub-allocates small application memory requests from these 8k
>allocations. This makes for faster memory allocations, but negates the benefit
>of PM to a large extent (as does the "flat" memory model now in common use by
>32-bit compilers). Therefore HeapLimit should normally only be set to 0 for
>debigging purposes.

>BP can only allocate about 2000 data selectors. Any more than this and it
>crashes! It's quite easy therefore to run out of selectors when your application
>has set HeapLimit to zero, since a new selector is allocated for every heap
>memory allocation (including creating objects with "New").