difference between TURBO PASCAL & BORLAND PASCAL
Sandrine AVRIL
I just changed from Turbo Pascal to Borland Pascal and experienced some
problems with that (side effects ?), like differences in the default
initialization value for global variables (TRUE in TP vs FALSE in BP).
It also seems (it is actually the reason why I upgraded...) that the
DELAY() function has been corrected in BP and is now able to handle
nower days processor speed (>133MhZ).
I discovered all that "by chance" and I'd like to know if anybody is
aware of a way to know all the differences between the two products (not
the marketing ones :-), but the tricky ones...) or a FAQ that I could
refer to.
Thank you in advance for any help.
Sandrine
Jan Kohout
> Hi ,
>
> I just changed from Turbo Pascal to Borland Pascal and experienced some
> problems with that (side effects ?), like differences in the default
> initialization value for global variables (TRUE in TP vs FALSE in BP).
Variables "integer" type are inicialized to 0, which is False.
> It also seems (it is actually the reason why I upgraded...) that the
> DELAY() function has been corrected in BP and is now able to handle
> nower days processor speed (>133MhZ).
Bug is _not_ repaired here (see FAQ how to repair it)
> I discovered all that "by chance" and I'd like to know if anybody is
> aware of a way to know all the differences between the two products (not
> the marketing ones :-), but the tricky ones...) or a FAQ that I could
> refer to.
>
One of difference is, that for compiling BP uses _all_ the memory
available on the computer (EMS), not only 640 kB. In reality it means
you can compile higher number of files. Also it uses DPMI, but I don't
know what it is.
I don't know if TP can compile into protected mode and Windows mode (and
BP can do that).
> Thank you in advance for any help.
>
>
> Sandrine
>
>
>
Bye
Honza
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
|^^^| Jan Kohout (HoK)
/ o \ e-mail : xkoh...@fi.muni.cz
< \_____/__ http://www.fi.muni.cz/~xkohout2
\ / \ snail : Armenska 1, Brno, Czech Republic
\_______/ tel : 00420 - 5 - 47 24 08 29
| |
/|\ /|\
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Help to remove death from our roads - drive on the pavement
Stefan Goehler
> problems with that (side effects ?), like differences in the default
> initialization value for global variables (TRUE in TP vs FALSE in BP).
> DELAY() function has been corrected in BP and is now able to handle
> nower days processor speed (>133MhZ).
> aware of a way to know all the differences between the two products (not
> the marketing ones :-), but the tricky ones...) or a FAQ that I could
> refer to.
libaries are built up from the same sources. TRUE and FALSE are
definitely the same in BP and TP. Why should they be different?
That you have a fixed crt library does simply say that you haven't
bought this product, but downloaded it somewhere. Any comments?
Bye,
Stefan
--
---
**********************************************
Stefan Göhler, Germany - stefan....@gmx.de
http://sourcenet.home.pages.de
If my reply lasts > a week, please inform me
**********************************************
Pedt Scragg
with
>Hi ,
>
>I just changed from Turbo Pascal to Borland Pascal and experienced some
>problems with that (side effects ?), like differences in the default
>initialization value for global variables (TRUE in TP vs FALSE in BP).
If you have gone from TP6 to BP7 then you will see this as TP/BP7
initialises all variables to 0 (which means false for boolean values)
TP6 and earlier do not do this initialisation so you get whatever was in
memory at this location previously.
>It also seems (it is actually the reason why I upgraded...) that the
>DELAY() function has been corrected in BP and is now able to handle
>nower days processor speed (>133MhZ).
No. This is one thing Borland did not fix. There are fixes available -
there's a list at http://www.geocities.com/SiliconValley/2926/tp.html
>I discovered all that "by chance" and I'd like to know if anybody is
>aware of a way to know all the differences between the two products (not
>the marketing ones :-), but the tricky ones...) or a FAQ that I could
>refer to.
Not aware of a page that lists all the differences. The FAQ's
concentrate on the How-To for coding and links to useful resources.
--
Pedt
Joe Fischer
: I just changed from Turbo Pascal to Borland Pascal and experienced some
: problems with that (side effects ?), like differences in the default
: initialization value for global variables (TRUE in TP vs FALSE in BP).
It is a good practice to initialize all variables,
even if you know the defaults are what you want.
And this also avoids a problem with differences
in results of a program between compiled, and running
in the IDE, which may not reinitialize each time.
Joe Fischer
Frank Peelo
Sandrine AVRIL wrote in message
<36F929B9...@soleil.biomerieux.fr>...
>Hi ,
>
>I just changed from Turbo Pascal to Borland Pascal and experienced
some
>problems with that (side effects ?), like differences in the default
>initialization value for global variables (TRUE in TP vs FALSE in
BP).
I suppose you were going from a pre-TP7 version of Turbo Pascal?
Global variables would not have been initialised. I don't have old TP
to hand, but maybe a non-0 boolean would be regarded as True. The
chances of that would be 255 times more likely than the boolean being
0, so you might have thought they were always initialised to True, but
you should not rely on it. In fact, you're better off not relying on
variables being initialised at all, except for "typed constants".
>It also seems (it is actually the reason why I upgraded...) that the
>DELAY() function has been corrected in BP and is now able to handle
>nower days processor speed (>133MhZ).
This would be consistent with the assumption that you are upgrading
from an old TP, where the delay started getting small when the CPU got
fast. But BP7 has its own problems, when you get up to 200 MHz or
thereabouts, when programs using CRT bomb with run-time error 200;
stick around in this group and you'll hear more of this bug!
So - which version of TP were you upgrading from? And how did you
upgrade - CD from Borland?
FP
Rich Pasco
> Variables "integer" type are inicialized to 0, which is False.
Not so. Variables are not automatically initialized at all, in either
Turbo or Borland Pascal. You get whatever value the previous program
happened to leave in memory.
- Rich
Rich Pasco
> Variables "integer" type are inicialized to 0, which is False.
To which I replied:
> Not so. Variables are not automatically initialized at all, in either
> Turbo or Borland Pascal. You get whatever value the previous program
> happened to leave in memory.
Since several people have posted that TP7 and BP7 do in fact initialize
variables to 0, I ask, how do you know that? I checked the Language
Guide but it says (p.59) that the only way to pre-initialize a variable
is to declare it as a "typed constant."
The fact that an uninitialize variable seems to usually have value 0
is interesting but doesn't really prove anything; it could just be
coincidental.
- Rich
Jochen Heyland
the majort difference between TP7 and BP7 is that BP7 can can write
protected mode programs and windows programs (though I don't recommed
that latter). TP7 only allowed for a real mode target. As far as the
delay problem is concerned - I;m pretty sure that BP7 programs die on a
computer > 233 MHz but there are patches out there to fix the problem.
Neither Tp7 not BP7 specifies initialization of global or local
variables. In BP7, they actually get filled with #0 but since it's not
documented I would recommend no counting on it either way.
Hope this helps,
Jochen
Sandrine AVRIL wrote:
>
> Hi ,
>
> I just changed from Turbo Pascal to Borland Pascal and experienced some
> problems with that (side effects ?), like differences in the default
> initialization value for global variables (TRUE in TP vs FALSE in BP).
> It also seems (it is actually the reason why I upgraded...) that the
> DELAY() function has been corrected in BP and is now able to handle
> nower days processor speed (>133MhZ).
> I discovered all that "by chance" and I'd like to know if anybody is
> aware of a way to know all the differences between the two products (not
> the marketing ones :-), but the tricky ones...) or a FAQ that I could
> refer to.
>
Osmo Ronkanen
>
>Since several people have posted that TP7 and BP7 do in fact initialize
>variables to 0, I ask, how do you know that?
That initialization is done only in real mode.
>
>The fact that an uninitialize variable seems to usually have value 0
>is interesting but doesn't really prove anything; it could just be
>coincidental.
Of course one could read the source:
InitTurbo:
MOV DX,SEG DATA ;Initialize DS
MOV DS,DX
MOV PrefixSeg,ES ;Save PSP segment
XOR BP,BP ;End of stack frame chain
CALL ClearDSeg ;Zero fill data segment
CALL Check8086 ;Determine CPU type
Osmo
Osmo Ronkanen
Jochen Heyland <jo...@bigfoot.com> wrote:
>Hi Sandrine,
>the majort difference between TP7 and BP7 is that BP7 can can write
>protected mode programs and windows programs (though I don't recommed
>that latter). TP7 only allowed for a real mode target. As far as the
>delay problem is concerned - I;m pretty sure that BP7 programs die on a
>computer > 233 MHz but there are patches out there to fix the problem.
BP has RTL source so one does not have to use patches, one can fix it
properly.
Osmo
Rich Pasco
> BP has RTL source so one does not have to use patches, one can fix it
> properly.
Then why hasn't anyone put forth a "proper" fix to the CRT unit
Initialization / Run-Time-Error 200 problem?
- Rich
Osmo Ronkanen
I have posted the changes what are needed for the CRT.ASM. I cannot post
the fixed version as that would be a copyright violation.
Osmo
Rich Pasco
> I have posted the changes what are needed for the CRT.ASM.
Wonderful! I must have missed your post here, among all the "please-
help-me-do-my-homework" type posts. Is the information on a web site
or somewhere else it's easy to recover?
> I cannot post
> the fixed version as that would be a copyright violation.
I understand. All I need to know is what to change and how to recompile
once it's been applied.
- Rich
Osmo Ronkanen
>Osmo Ronkanen wrote:
>
>> I have posted the changes what are needed for the CRT.ASM.
>
>Wonderful! I must have missed your post here, among all the "please-
>help-me-do-my-homework" type posts. Is the information on a web site
>or somewhere else it's easy to recover?
>
First locate the following line in CRT.ASM:
DelayCnt DW ?
Then add the following after it:
DelayCntHi dw ? ; added for delay bug fix
Then locate the actual division:
MOV CX,55
DIV CX
Now add the following _between_ the lines:
; begin added code for delay bug fix
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 the cnt
pop ax ; dx:ax = orig dx mod 55: orig ax
; now the division is safe
; end code for delay bug fix
This will work up to some 200 GHz machines. After that the delays will
drop to zero.
And finally locate the part where the DelayCnt is used:
@@1: MOV AX,DelayCnt
XOR DX,DX
Now simply comment the XOR line out and add:
mov dx,DelayCntHi ; added for delay bug fix
>> I cannot post
>> the fixed version as that would be a copyright violation.
>
>I understand. All I need to know is what to change and how to recompile
>once it's been applied.
The recompiling is done simply with command "make" when you are in the
RTL directory. Then you need to copy the TPL files from the RTL\BIN to
where you use them.
Osmo
Marcus Morris
>The fact that an uninitialize variable seems to usually have value 0
>is interesting but doesn't really prove anything; it could just be
>coincidental.
Yes - if the language guide says "undefined" then it's "undefined" -
even if it IS a zero today. Never rely on "undocumented features".
--
Marcus Morris - South Croydon, LONDON, UK (Mar...@ntos.demon.co.uk)
Dr John Stockton
14:47:32 in news:comp.lang.pascal.borland, Osmo Ronkanen
<ronk...@cc.helsinki.fi> wrote:
>>> properly.
>>
>>Then why hasn't anyone put forth a "proper" fix to the CRT unit
>>Initialization / Run-Time-Error 200 problem?
>>
>
>the fixed version as that would be a copyright violation.
Agreed.
What is needed is a public-domain script-driven file-copying program
with public source code (which could even be put in a FAQ) that, in one
pass, does two things; it deletes, replaces, and inserts some lines in a
text file (such as, but not limited to, CRT.ASM), and it verifies by
linecounts and checksums or otherwise that the portion of the file being
altered is what it should have been. IIRC, this sort of thing was a
traditional patching tool for distributing upgrades.
Any details of the old code (though there need be none) revealed in the
script would be lawful under "fair comment extracts" provisions.
Alternatively, it might be practical to work with the assembled code.
BTW, unless one is forced by references to Crt in existing libraries,
ISTM better in general to give the new unit a distinct name for
unambiguity. Crt_Osmo.* would fit nicely.
--
© John Stockton, Surrey, UK. j...@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL: http://www.merlyn.demon.co.uk/> - TP/BP/&c. FAQqish topics & links.
Timo's TurboPascal <A HREF="ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip">FAQ</A>.
<A HREF="http://www.merlyn.demon.co.uk/clpb-faq.txt">Mini-FAQ</A> of c.l.p.b.
Mike Dickson
> What is needed is a public-domain script-driven file-copying program
> with public source code (which could even be put in a FAQ) that, in one
> pass, does two things; it deletes, replaces, and inserts some lines in a
> text file (such as, but not limited to, CRT.ASM), and it verifies by
> linecounts and checksums or otherwise that the portion of the file being
> altered is what it should have been.
There have been public domain 'patch' programs - together with TP source
code - of exactly this nature for years and years - I'm just damned if I
can remember what they were called!
Why not use one of them instead? In fact (under the circumstances) since
almost everyone here is ipso facto a Borland Pascal user, would a
UUencoded post of the patch software and the patch to be applied be
inappropriate?
Mike Dickson, Black Cat Software Factory, Edinburgh, Scotland
fax 0131-271-1551 - Columnated Ruins Domino - Mellotron M400 #996
Pedt Scragg
us with
> In fact (under the circumstances) since
>almost everyone here is ipso facto a Borland Pascal user, would a
>UUencoded post of the patch software and the patch to be applied be
>inappropriate?
>
binaries dumped on them but also most/alot of us have to pay for
telephone charges and downloads of binaries. Binaries should be made
available via a web site - the way I have done when a specific question
needed something too big to post onto the ng.
--
Pedt
If smoking is so bad for you, how come it cures kippers?!
Dr John Stockton
08:31:28 in news:comp.lang.pascal.borland, Pedt Scragg
<newsm...@pedt.demon.co.uk> wrote:
>Mike Dickson [mailto:mike@blackcat.?.demon.?.co.?.uk] decided to regale
>us with
>> In fact (under the circumstances) since
>>almost everyone here is ipso facto a Borland Pascal user, would a
>>UUencoded post of the patch software and the patch to be applied be
>>inappropriate?
>>
>Yes it would be Mike. Text only disucssion groups should not get
>binaries dumped on them but also most/alot of us have to pay for
>telephone charges and downloads of binaries. Binaries should be made
>available via a web site - the way I have done when a specific question
>needed something too big to post onto the ng.
I half mildly disagree. In such cases, the patching program should be a
standard - Edlin (<g>) or a binary from Garbo or suchlike; but it is
quite nice to have the changes given in an ASCII script. ISTR that it
was done in this way for RT-11, with the patch scripts distributed in
... writing. With a script patch, made available over the Net, one can
see what it will do, but need not worry about one's own typos.
--
© John Stockton, Surrey, UK. j...@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL: http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.
PAS, EXE in <URL: http://www.merlyn.demon.co.uk/programs/> - see 00index.txt.
Do not Mail News to me. Before a reply, quote with ">" or "> " (SoRFC1036)
Alexander Stohr
Jochen Heyland wrote:
> Neither Tp7 not BP7 specifies initialization of global or local
> variables. In BP7, they actually get filled with #0 but since it's not
> documented I would recommend no counting on it either way.
But function local variables will be created on the stack.
On locations where lots of garbage is around ant they
are not initialized for sure.