Hello Keith!

Saturday April 27 1996, Keith Thomson writes to Allan Mertner:

 KT> SP's debugger is almost identical to TP7.0's, That's quite enough to find
 KT> the bugs you encounter in SP.

 KT>  VP need a larger debugger because of it's overzealous attempt to be
 KT> BP compatable.. IE using heaps of 16 bit stuff..

I do not write 16 bit stuff with VP, so what is the problem ?

 KT>>> Virtual pascal is a very good compiler.. But the authors were
 KT>>> being Over-zealos with their compatability with Turbo/borland
 KT>>> pascal.

I can understand that, keeps it easy to have a common code base with some
{$IFDEF}{$ELSE}{$ENDIF} without having to think about what the OS/2 or the
dos version makes of the written code.

 KT>>>  Such as the 16 bit ASM.. the MEM variable..  Absolute..
 KT>>> etc. These make it easier to port over, But also FAR less stable.

Who says those have to stay within the program ?

 KT> In OS/2, They are simply unstable, Or at least, VP's implenetation of them
 KT> is. I do not use the Inline,

??? I thought they ( Fprint) removed the Inline statements. I have tried to
get it to work, but Vpascal does not support inline ( inline($66 etc ))

 KT>  or Mem variable..

But I think mem is mostly used for referencing keyboard or video functions
( or for the biosdata area ) There are examples for finding out those
things with native os/2 calls.

So basicly your complaint boils down to dos specific routines. I.e. they
should be rewritten. ( heck, who is going to use old code in an os/2
program ? )

 KT>  And you really should use 32 bit if you are going to do ASM in os/2,

 KT> 16 bit ASM in a 32 bit memory model is, as i said earlier, Unstable.

Depends, you should be really carefull about the stack and referencing memory.

 AM>> I really do not see how it can be a disadvantage to
 AM>> supply more features, faster compilation, good debugging and high
 AM>> compatibility! :)

 KT> Too bad that isn't quite what VP offers.

???? I do not get it, while learning pascal for school, I wrote my
assignments with VP, and ported them to dos by removing the uses use32.
That is what I call compatibility. ( and some other programs I wrote with a
shared code base, with some help of {$IFDEF OS2}... )

 KT> Compile speed is about the same,

Have not ftp'ed the 1.5 release of SP.

 KT>  VP's debugger had to be upped to get rid of the bugs..

Could you clarify this please ? It helped me to kill a big bug, it turned
out I was looking at the wrong part ) With standard methods that would not
have worked. ( simply because I was looking at the wrong part )

 KT>   the compatability causes it to be unstable. and VP Actually
 KT> offers less features,

Well, can SP procedure code optimized specificily for the pentium, 486 or 386 ?
Can you use classes ? ( you know delphi... )

 KT>  All VP offers in the way of features over SP is the heaps and heaps
 KT> of useless DOS libraries ported to it.

That is more because of its compatibility with the Borland pascal language
definition. But SP is not that compatible, I do not know if I would like to
learn yet another different pascal slang to get SP to work.

==> Gerard/2   - member of team os/2 -  1000521{at}ibk.fnt.hvu.nl

--- Fmail/2 1.02 Registered