Runtime 200 (don't skip) 
Author Message
 Runtime 200 (don't skip)

Is it true that when you have a patched version of TP7 (for the RT200) you can't
use units compiled with an unpatched version, or the other way round? That is,
if you don't have the source to the unit. Someone suggested that to me when he
had some problems with a unit I made. The compiler gave a unit version mismatch.

Regards,

Remco de Korte
http://www.*-*-*.com/ ~remcodek/



Wed, 18 Jun 1902 08:00:00 GMT  
 Runtime 200 (don't skip)

Quote:

>Is it true that when you have a patched version of TP7 (for the
RT200) you can't
>use units compiled with an unpatched version, or the other way round?
That is,
>if you don't have the source to the unit. Someone suggested that to
me when he
>had some problems with a unit I made. The compiler gave a unit

version mismatch.

Unit version mismatch should only occur if the _interface_ of a unit
has changed. There should not be any problem from patching the
implementation section of a unit. That is not the same thing as saying
there _is_ no problem, however, and I don't have unpatched units handy
to try it out. What unit is the error reported for? CRT? System? Your
unit? Which patch did you use?

FP



Wed, 18 Jun 1902 08:00:00 GMT  
 Runtime 200 (don't skip)

Quote:

> Is it true that when you have a patched version of TP7 (for the RT200) you can't
> use units compiled with an unpatched version, or the other way round? That is,
> if you don't have the source to the unit. Someone suggested that to me when he
> had some problems with a unit I made. The compiler gave a unit version mismatch.

This isn't so much an RTE200 issue as it is general compilation behavior.  A
unit mismatch error should ONLY occur if the interface portion of the unit has
changed.  A change in implementation won't change the internal version code of
a unit.  If you're getting version mismatch errors, make sure the interface is
100% compatible.

Quote:
> Regards,

> Remco de Korte
> http://www.xs4all.nl/~remcodek/

--
Scott Earnest            | SPAM protection in effect. Remove  |





Wed, 18 Jun 1902 08:00:00 GMT  
 Runtime 200 (don't skip)

Quote:


> > Is it true that when you have a patched version of TP7 (for the RT200) you can't
> > use units compiled with an unpatched version, or the other way round? That is,
> > if you don't have the source to the unit. Someone suggested that to me when he
> > had some problems with a unit I made. The compiler gave a unit version mismatch.

> This isn't so much an RTE200 issue as it is general compilation behavior.  A
> unit mismatch error should ONLY occur if the interface portion of the unit has
> changed.  A change in implementation won't change the internal version code of
> a unit.  If you're getting version mismatch errors, make sure the interface is
> 100% compatible.

> > Regards,

> > Remco de Korte
> > http://www.xs4all.nl/~remcodek/

This is a reply to both Frank and Scott's messages:

The unit itself isn't changed.

To make a short story long:
I have made some font-units which I have made available for other users on my
webpage. Everybody is free to use them, but I didn't want to distribute the
source. You may find this stupid, but I had put a lot of time in making them, a
few years back, and at time they were the only thing of their kind. I had
compiled them using TP7 for BGI-graphics but soon found that lots of people
absolutely refused to use BGI so I made a mode13h-version, then VESA, even a
Delphi version of some. Meanwhile people kept on asking for the source because
they wanted to use them with TP6. So, I made a TP6-version. At that point I
thought I had it nearly all covered.
Some time ago I had a message from someone who still couldn't get the units to
work even though he was using TP7, as he said. He got a version
mismatch-message. I tried helping him a few times. At one point he suggested it
might have something to do with a patched RTL for the RTE200-bug. To be honest,
I don't know if I have patched my TP7, I hardly ever use it, but I haven't had
any problems yet. I haven't heard from that person since, but last week there
was someone else with the same complaint. I tried to help him, suggesting it
might have something to do with the RTE200-stuff, but I'm not sure whether that
makes any sense, so I thought I'll ask the real experts :-)
I don't mind distributing the units and answering questions, but I still refuse
to give away the source, more so because several people have paid the
registration-fee to get them. But if I have to keep on making new versions for
every bug, patch or update in an otherwise obsolete (pardon: unsupported by the
maufacturer) compiler, I think I'll take the whole stuff off line.
I just want to make sure.
(I hope this doesn't seem too childish)

So: the units haven't changed, but has the compiler?
Or: am I making any sense?
;-)

Regards,

Remco de Korte
http://www.xs4all.nl/~remcodek/



Wed, 18 Jun 1902 08:00:00 GMT  
 Runtime 200 (don't skip)

Quote:

>...
>Some time ago I had a message from someone who still couldn't get the
units to
>work even though he was using TP7, as he said. He got a version
>mismatch-message. I tried helping him a few times. At one point he
suggested it
>might have something to do with a patched RTL for the RTE200-bug. To
be honest,
>I don't know if I have patched my TP7, I hardly ever use it, but I
haven't had
>any problems yet. I haven't heard from that person since, but last
week there
>was someone else with the same complaint. I tried to help him,
suggesting it
>might have something to do with the RTE200-stuff, but I'm not sure
whether that
>makes any sense, so I thought I'll ask the real experts :-)
>...

A patch for the RTE200 bug should not cause this behaviour, since it
should only affect the implementation of the CRT unit, whereas unit
versions depend only on the interface.

Each TPU contains a unit version number for each unit that it depends
on as well as for itself. If the compiler finds a TPU file X that
depends on a unit Y for which a TPU exists, it checks the unit version
numbers and recompiles Y if the version numbers differ. I wonder if
anyone has a utility for printing out the unit version numbers for TPU
files? That might pinpoint exactly which unit is causing the problem.

If you modified the interface of the CRT unit before compiling up your
run-time library, and then compiled up units that used your modified
CRT unit, you would have a problem. Same for other standard units -
the worst one to change would be SYSTEM.PAS, of course, since _every_
unit depends on it.

Similarly, if your users changed the interface section of a unit when
modifying their RTL, they would be unable to use your units. In other
words, it could possibly be a problem with the user's RTL, and not
yours.

However, fixes for that bug require modification to CRT.ASM, the
CRT.PAS file containing the interface should not be touched.

FP



Wed, 18 Jun 1902 08:00:00 GMT  
 Runtime 200 (don't skip)
In comp.lang.Pascal.borland, Remco de Korte uttered:

Quote:

>So: the units haven't changed, but has the compiler?
>Or: am I making any sense?
>;-)

The user has changed the interface section of one of the units that your
unit uses and recompiled it. The only change to the header part of a
unit on recompilation will be in the date stamp if the interface section
has not changed.

<ponders>
I wonder if changing any of the compiler directives without changing the
interface also makes a difference ?

Not able to test at the mo - my notebook has no BP yet
</ponders>

--
Pedt Scragg

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



Wed, 18 Jun 1902 08:00:00 GMT  
 Runtime 200 (don't skip)

Quote:
> A patch for the RTE200 bug should not cause this behaviour, since it
> should only affect the implementation of the CRT unit, whereas unit
> versions depend only on the interface.

> Each TPU contains a unit version number for each unit that it depends
> on as well as for itself. If the compiler finds a TPU file X that
> depends on a unit Y for which a TPU exists, it checks the unit version
> numbers and recompiles Y if the version numbers differ. I wonder if
> anyone has a utility for printing out the unit version numbers for TPU
> files? That might pinpoint exactly which unit is causing the problem.

> If you modified the interface of the CRT unit before compiling up your
> run-time library, and then compiled up units that used your modified
> CRT unit, you would have a problem. Same for other standard units -
> the worst one to change would be SYSTEM.PAS, of course, since _every_
> unit depends on it.

> Similarly, if your users changed the interface section of a unit when
> modifying their RTL, they would be unable to use your units. In other
> words, it could possibly be a problem with the user's RTL, and not
> yours.

> However, fixes for that bug require modification to CRT.ASM, the
> CRT.PAS file containing the interface should not be touched.

> FP

Thanks for the information. I'm sure I never touched my CRT-unit, so, as I
understand there's little I can do.
Again, thank you.

Regards,

Remco de Korte



Wed, 18 Jun 1902 08:00:00 GMT  
 Runtime 200 (don't skip)

Quote:

> <ponders>
> I wonder if changing any of the compiler directives without changing the
> interface also makes a difference ?

> Not able to test at the mo - my notebook has no BP yet
> </ponders>

Which brings me to the question: is BP7 fully compatible with TP7?
I never had BP7, so I only know it doesn't work the other way round.

Remco de Korte



Wed, 18 Jun 1902 08:00:00 GMT  
 Runtime 200 (don't skip)

Quote:

> Which brings me to the question: is BP7 fully compatible with TP7?
> I never had BP7, so I only know it doesn't work the other way round.

To the extent that you're asking, yes.  BP7 with real mode target selected
produces results identical results as TP7.

Quote:
> Remco de Korte

--
Scott Earnest            | SPAM protection in effect. Remove  |





Wed, 18 Jun 1902 08:00:00 GMT  
 Runtime 200 (don't skip)

Quote:

> Thanks for the information. I'm sure I never touched my CRT-unit, so, as I
> understand there's little I can do.
> Again, thank you.

Well, you could check your units against fresh copies.  Use TPUMOVER.EXE to
extract all the units from your TURBO.TPL into one subdirectory, then go
through the install disks and get a clean TURBO.TPL and extract all the units
from that file into a second directory.  Then, with a little bit of batch
work, do a comparison.  For example, suppose you extracted your working TPL
into C:\TURBO\BIN\WORKING and the one from your install disk into
C:\TURBO\BIN\ORIGINAL.  cd to C:\TURBO\BIN\WORKING then do this:

for %%a in (*.tpu) do fc %%a ..\original\%%a >> ..\compare.txt

This will show you if there are any discrepancies in your core units.

Another potential problem.  Does your code use a unit that you haven't
distributed, but may also have a common name?  If someone has a different unit
of the same name, it can trigger just this sort of error message as well.  If
you can give me a precise pointer, I could go take a look at it and see if
there's anything else that could be problematic.

Quote:
> Regards,

> Remco de Korte

--
Scott Earnest            | SPAM protection in effect. Remove  |





Wed, 18 Jun 1902 08:00:00 GMT  
 Runtime 200 (don't skip)

Quote:


> > Thanks for the information. I'm sure I never touched my CRT-unit, so, as I
> > understand there's little I can do.
> > Again, thank you.

> Well, you could check your units against fresh copies.  Use TPUMOVER.EXE to
> extract all the units from your TURBO.TPL into one subdirectory, then go
> through the install disks and get a clean TURBO.TPL and extract all the units
> from that file into a second directory.  Then, with a little bit of batch
> work, do a comparison.  For example, suppose you extracted your working TPL
> into C:\TURBO\BIN\WORKING and the one from your install disk into
> C:\TURBO\BIN\ORIGINAL.  cd to C:\TURBO\BIN\WORKING then do this:

> for %%a in (*.tpu) do fc %%a ..\original\%%a >> ..\compare.txt

> This will show you if there are any discrepancies in your core units.

> Another potential problem.  Does your code use a unit that you haven't
> distributed, but may also have a common name?  If someone has a different unit
> of the same name, it can trigger just this sort of error message as well.  If
> you can give me a precise pointer, I could go take a look at it and see if
> there's anything else that could be problematic.

> > Regards,

> > Remco de Korte

> --
> Scott Earnest            | SPAM protection in effect. Remove  |




Thanks for all your efforts. Really, I didn't want you to do all my work. On the
other hand, I have little time to start fooling around with my TPL because one
or two (of many) users of a unit I made have problems. I was just trying to make
sure. (As I said, if it would be necessary for me to invest a lot of time and
trouble again I'd rather take the stuff offline. Okay, I'm lazy, let's keep it
at that ;-))
If you really want to go and check here's the URL:
http://www.xs4all.nl/~remcodek/fontpage.html

Regards,

Remco de Korte



Wed, 18 Jun 1902 08:00:00 GMT  
 Runtime 200 (don't skip)

Quote:


>> Which brings me to the question: is BP7 fully compatible with TP7?
>> I never had BP7, so I only know it doesn't work the other way round.

>To the extent that you're asking, yes.  BP7 with real mode target selected
>produces results identical results as TP7.

Is the pentium/CPU over 200Mhz runtime error 200 common to both
compiles?  IF not, that explains why I never have problems, as I only
compile protected mode applications.

--
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  
 Runtime 200 (don't skip)

Quote:

>Is the pentium/CPU over 200Mhz runtime error 200 common to both
>compiles?  IF not, that explains why I never have problems, as I only
>compile protected mode applications.

It is same on both.

Osmo



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

 Relevant Pages 

1. Pent2.exe (runtime error 200 fixer) well it don't fix on 500mhz+

2. Object Pro Opcrt unit runtime error 200

3. runtime error 200

4. Runtime Error 200 with new computer

5. Runtime Error 200 auf PC mit 800 MHz

6. Win98 & Runtime-Error 200

7. Runtime Error 200

8. RUNTIME 200 on P200

9. NEW Runtime error 200

10. FAQ for Runtime error 200 at 0164:0091

11. Problem mit Pascal Programm (RunTime error 200 at 4AC2:0091)

12. Runtime error 200

 

 
Powered by phpBB® Forum Software