7.0 -> 7.01 upgrade 
Author Message
 7.0 -> 7.01 upgrade

In comp.lang.Pascal.borland, someone who wished not to give their name
uttered:

Quote:

>I became
>aware that there was apparently a
>7.01 bug fix update which I never got.

>Is there any way to get this upgrade,
>now that Inprise has turned BP7 into
>an unsupported orphan?

From postings here and in bpt: apparently it *is* possible to get it
from Inprise for a sum of $ *but* you need to be a little persistent.

--
Pedt Scragg

No-one is completely useless, they can always be a bad example.



Wed, 18 Jun 1902 08:00:00 GMT  
 7.0 -> 7.01 upgrade

Quote:

>I am the proud owner of Borland Pascal 7.0

>I recently ran up against the infamous
>CRT runtime error 200.

>In the course of surfing the 'net
>looking for info about it, I became
>aware that there was apparently a
>7.01 bug fix update which I never got.

TP 7.01 is a bug fix but it does NOT fix the RTE 200 bug.
If you have Borland Pascal you can edit the CRT source and fix the bug
properly.

Quote:

>Is there any way to get this upgrade,
>now that Inprise has turned BP7 into
>an unsupported orphan?

Do not think Inprise is going to give a fix. Hell no, they even continue
to sell the buggy TP.

Osmo



Wed, 18 Jun 1902 08:00:00 GMT  
 7.0 -> 7.01 upgrade

Quote:


>>I am the proud owner of Borland Pascal 7.0

>>I recently ran up against the infamous
>>CRT runtime error 200.

>>In the course of surfing the 'net
>>looking for info about it, I became
>>aware that there was apparently a
>>7.01 bug fix update which I never got.

>TP 7.01 is a bug fix but it does NOT fix the RTE 200 bug.
>If you have Borland Pascal you can edit the CRT source and fix the bug
>properly.

>>Is there any way to get this upgrade,
>>now that Inprise has turned BP7 into
>>an unsupported orphan?

>Do not think Inprise is going to give a fix. Hell no, they even continue
>to sell the buggy TP.

From what I've seen, Borland (Inprise) references patches but makes no
claim that any of them work.  I'm still trying to figure out why my
version doesn't have the Runtime error 200 bug, but my stuff seems to
work fine on a K6 II/300.  I did make one change to the library
however, to increase the maximum memory to 2048*7*8192 bytes per
program (100+megs).  The limitation is based on how much memory is
allocated when more is needed.

--
For the latest Beta of Huffman Compression Engine II
http://www.webworldinc.com/joejared/WLH7021.zip
Ways to get here from there:
ICQ http://wwp.mirabilis.com/12016722
ftp://webworldinc.com/joejared
http://www.webworldinc.com/joejared
For windows 95 with netbeui loaded //206.135.17.202

 * Origin: Orange, CA, 714-532-15860101 (1:103/301)



Wed, 18 Jun 1902 08:00:00 GMT  
 7.0 -> 7.01 upgrade

Quote:

> TP 7.01 is a bug fix but it does NOT fix the RTE 200 bug.
> If you have Borland Pascal you can edit the CRT source and fix the bug
> properly.

Is how to edit the CRT source, and the necessary changes, in the FAQ?
I have BP7, and would rather edit the CRT source and recompile, than
use someone elses new unit or fix.


Wed, 18 Jun 1902 08:00:00 GMT  
 7.0 -> 7.01 upgrade

Quote:


>> TP 7.01 is a bug fix but it does NOT fix the RTE 200 bug.
>> If you have Borland Pascal you can edit the CRT source and fix the bug
>> properly.

>Is how to edit the CRT source, and the necessary changes, in the FAQ?

You need to do following three changes to CRT.ASM:

DelayCnt        DW      ?
DelayCntHi      dw      ?     ; added for delay bug fix
...

        MOV     CX,55

        ; begin added code for delay bug fix

        sub     ax,1    ; This is for future superhyper-fast machines where
        sbb     dx,0    ; DX:AX=0:0, (=>FFFF:FFFF, for maximum delaycnt)
                        ; no significant effect on others

        push    ax              ; save ax for the second division
        mov     ax,dx
        xor     dx,dx           ; dx:ax := 0:dx
        div     cx              ; ax:=orig dx / 55, dx:=orig dx mod 55
        mov     DelayCntHi,ax   ; save the high part of cnt
        pop     ax              ; dx:ax = orig dx mod 55: orig ax
                                ; now the division is safe

        ; end code for delay bug fix

        DIV     CX

...

        ;XOR     DX,DX         ; commented out for delay bug fix
        mov     dx,DelayCntHi  ; added for delay bug fix

What the above change does it does the division in two parts, first
dividing DX by 55 and storing the result to DelayCntHi, then it proceeds
with the existing code to divide DX:AX where DX is the remainder of the
first division. This way both divisions are safe. When the delay is
called the stored value in DelayCntHi is used for DX instead of zero.

Note that the 8086 DIV instruction is designed so that one can easily
divide arbitrary length number with a 16-bit one, just start by
clearing DX and then fetch the dividend word a time from the most
significant word to AX, do the division, store AX in the result and
fetch the next.

As for why I first subtract one from DX:AX. If the delay loop overruns
then it will exit with DX:AX as zero (on TP 6.0 it exited with the
16-bit counter AX as 65535). Now this would mean that delays would
suddenly drop to zero instead of just becoming a little too fast so I
fixed that as well. The problem would not materialize though until about
20 years from now. (assuming doubling of the speed every two years)

There are other ways to fix it. I made is specifically so that it can be
done by adding lines and not changing any of them (the XOR DX,DX that is
commented out is an exception but it is not strictly mandatory)

Install the RTL source, edit the CRT and then issue MAKE and finally
copy the TPL files where they are used.

Btw does your version have the longint shift bug fixed. (On TP 7.0
longint shifts of over 16 bits were incorrect on 386+). Here is a fix to
SYS\LONG.ASM:

LongShr:

        CMP     Test8086,2

    .386
        test cl,16

        SHRD    AX,DX,CL
        SHR     DX,CL
        RETF

        xor dx,dx
        and cl,1fh
        sub cl,16
        shr ax,cl
        retf

    .8086
...

LongShl:
        CMP     Test8086,2

    .386
        test cl,16

        SHLD    DX,AX,CL
        SHL     AX,CL
        RETF

        xor ax,ax
        and cl,1fh
        sub cl,16
        shl dx,cl
        retf

    .8086

The instructions at lower case were added.

If not then it is good to fix those at the same time.

Quote:
>I have BP7, and would rather edit the CRT source and recompile, than
>use someone elses new unit or fix.

Osmo


Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. BP 7.0 -> 7.01 upgrade

2. Upgrade 7.0 to 7.01?

3. BP 7.0 -> 7.1 Upgrade

4. Update/Patch? 7.0 to 7.01

5. TP 7.0 vs 7.01

6. TP 7.0 vs 7.01 - How to Differentiate

7. BP with Objects 7.0 vs 7.01

8. Re. BP with Objects 7.0 vs. 7.01

9. Turbo Pascal 7.0 patch (7.01?)

10. TP 7.0 & BP 7.01

11. Delphi>>>>>>>

12. Apollo 2.0 -> 2.1 upgrade problem

 

 
Powered by phpBB® Forum Software