BP7 RTL - SE.ASM - bug or not?

Robert Prins

Delphi Developer

Fri, 16 Jul 2004 04:38:27 GMT

BP7 RTL - SE.ASM - bug or not?

Hi all,

From private correspondence:

Quote

> I see from your email that you are familiar w/ Ralf Brown stuff,
> but Yes se.asm DOES have an error in win/dpmi.

> See below, se.asm can be "snipped" from this email at the indicated
> line below. In case the "text" format of this email "upsets it", the
> fixed se.asm is also ATTACHED to this email in SE.ZIP. See the
> FIRST 2 lines of SE.ASM, then either add ";" to comment, or delete
> those lines.

> The dpmi / windows stack variables NEED to be in their proper
places.

> At the BEGINNING of EVERY win 3.x and DPMI16 DATA segment these
> variables MUST appear in the PROPER order, but Borland got it very
> wrong, which means that ALL their DPMI16 / win3x programs, INCLUDING
> the IDEs are defective!

> You have to recompile ALL dpmi/win progs w/ this version of se.asm.

> Errors:
> Borland put "pStackMin" at DS:0E should be DS:0C
> Borland put "pStackBot" at DS:0C should be DS:0E

> Look for this, down in the file:
> pStackMin EQU (WORD PTR DS:0CH) ;BUGFIX original was pStackBot
> pStackBot EQU (WORD PTR DS:0EH) ;BUGFIX original was pStackMin

> NOTE: When you fix this, I'd greatly appreciate a copy of se.asm
> that contains YOUR overlay & emulator patch logic, I will need an
> update of THIS so I can recompile MY bp7.01 w/ the overlay & other
> changes YOU make.

Can anyone confirm that this is indeed a bug in SE.ASM?

Thanks,

Robert
--
Robert AH Prins
pr...@bigfoot.com

Wolfgang Ehrhar

Delphi Developer

Sat, 17 Jul 2004 05:15:01 GMT

Re:BP7 RTL - SE.ASM - bug or not?

On Sun, 27 Jan 2002 20:38:27 -0000, "Robert Prins"

Quote

<pr...@onetel.net.uk> wrote:
>Hi all,
>From private correspondence:

[snip]

Quote

>> The dpmi / windows stack variables NEED to be in their proper
>places.

>> At the BEGINNING of EVERY win 3.x and DPMI16 DATA segment these
>> variables MUST appear in the PROPER order, but Borland got it very

Nonsense, because the important segments with preallocated descriptors
(Seg0040, SegB000 etc) do NOT have this structure.

BTW I would like see a spec where this order is written down.

Quote

>> wrong, which means that ALL their DPMI16 / win3x programs, INCLUDING
>> the IDEs are defective!

>> You have to recompile ALL dpmi/win progs w/ this version of se.asm.

Complete nonsense! (It seems to imply that all BP7 DPMI/WIN are buggy,
which is ridiculous!).

Quote

>> Errors:
>> Borland put "pStackMin" at DS:0E should be DS:0C
>> Borland put "pStackBot" at DS:0C should be DS:0E

pStackBot is used only once in all ASM source files. pStackMin is used
twice in the RTL: first in dapp.asm, and here it doesn't matter if it
would be swapped with pStackBot because both are initalized to the
same value:

MOV SS:pStackBot,AX ;Set stack bottom
MOV SS:pStackMin,AX ;Set stack low water mark

The other place is in the stack checking routine for {$S+} code
located in errc.asm.

I am using for about 8 years a debug unit which uses this
logging feature of the {$S+}-procedure to print out the stack
usage in an exit procedure. I never observed any anomalies
resulting from a "wrong" definition of pStackmin, excerpt:

{$ifdef DPMI}

{Ref: RTL se.asm/errc.asm}

procedure HSUsage;
var
MS,SS:word;
begin
SS := SSeg;
MS := MemW[SS:$E];
writeln(#13#10'Stack - used: ',MemW[SS:$C]-MS,
', free: ',MS-MemW[SS:$A]);
end;

{$else}
...

[snip]

Wolfgang

--
In order to e-mail me a reply to this message, you will have
to remove PLEASE.REMOVE from the address shown in the header.

Other Threads

1. Bug in TPL60N19 (Norbert Juffa's RTL replacent for TP6 RTL)

2. MISSING FILE SE.ASM

3. I need SE.ASM!!!

4. Calling RTL routines in asm...end statements

5. Which known BP7 bugs did BP7.01 fix ?

6. RTL of BP7.01

7. BP7 RTL Pb.

8. BP7 RTL

9. BP7 RTL Source code

10. GPF caused by WMEM.ASM in BP7