Does anyone know if code in Turbo Pascal for WIndows 1.5 can be
compilied on Delphi?  I have a large application in TPW that I would
like to move into Delphi so I can take advantages of Win32.  Thanks
Nick Widboom
widb...@ssu.southwest.msus.edu

Moving your engine/kernal to Delphi (32 bit) can result in a substantial
performance boost (in my case it was 300%).  Additionally, the de{*word*81}
is infinitely better.

As I understand it version 3 of Delphi doesn't even mention the old
"object" keyword.  Consequently, you may want to either start with D2 or
at least take a peek at the relevant help files for D2.

Bob Lee

I ported about 80,000 lines of Pascal 6 (DOS) code to delphi 1
successfully.  I know its not 1.5,
but the experience should prove similar.  This code was originally not
written in an "object" style, but conversion proved "relatively"
straight forward.  And you will
just have to do the interfaces pretty much from scratch, but then that's
what's supposed to
be easy about delphi, right?

There are a few issues:

1.  Pointer arithmetic... the segment-offset format for DOS and D1 are
different.
(That difference may have already been there between DOS and P1.5 for
windows.

2. Time stamps... If you saved time stamps in the old Borland format,
they are now
obsolete and the time functions return a different format. ( I am
assuming P1.5 still
used the P6 style stamps)  However, disk-file timestamps
are STILL in the old format, and Delphi provides conversion routines.
Just be careful that
routines with the same names as your P1.5 routines are now returning the
different format.

3. Stuff like color constants, the way pens and fonts were defined etc..

 ( I had some graph stuff to convert, too) but I dont know how much an
issue
 that will be for 1.5.

4. Inlines.  No more inline functions.  Most of the inline I had was
convertable either to straight
  Pascal or embedded ASM

============================================================

I evtually got it to D2, but If you GO to delphi 2 or 3,
 you will have the following additional issues:

1.  Record alignment... if you are saving record structures in files,
you may have to test
whether you will need the compiler option for "record alignment" on or
off, and it will depend
also on whether you used alignment before.  The 32-bit alignment MAY end
up different than
the original 16-bit alignment, so you may end up having the same
structure become a
different size when compiled in D2; and would have to "convert" your
data files with
a utility before you can use the old ones.

2. Strings.  D2 default for type "String",  is the new pascal "huge"
strings.
Unless you have used strings
somewhat generically, you will probably need to turn off that compiler
option and
stick to the original "pascal" style string for
it to compile immediately.  Also D2 wants to stop your acess to byte [0]
to set a
string length and you have to use their "SetLength" function.

However, certain functions that used to take "string" as a parameter,
will insist on
the new HUGE strings and you will have to transfer the data from your
short string to
a huge string appropriately.  (Fortunately, If you choose the "no huge
strings" compiler option,
you can still compile "huge" strings with the  "AnsiString" type
declaration.

3. Overflow.   I had a 3rd-party sort routine that depended on
decrementing a word past
0 and used the information that it had now gone to 64k.  In D1 this will
not generate an
exception; in D2, you have to turn off the compiler option for checking.

4. Pointer Arithmetic again... flat 32 bit address now makes it easy.

5. Memavail, maxavail no longer there.

6. If you used "word"-typed arguments to Pascal functions, where
Integers were called
   for, those will not compile.

So-- there ARE issues, but it should be do-able.