This paper combines a number of previous articles about porting Delphi 1.x code to 32-bits. When I write about Delphi-32, I mean any 32-bits version of Delphi: Delphi-2.x or higher!

Delphi-32 defines several new data types that exploit the features available by Windows 95. Delphi-32 has also changed a few data types to take advantage of the 32-bit environment. New Data Types include character type, character pointer types, string type, variant type and the currency type.

Character Type
Delphi-32 introduces new wide character types to support Unicode. Delphi 1.x treated characters as 8-bit values of type Char.
These are the standard types that represent characters in Delphi-32.

• ANSIChar
  A standard 8-bit ANSI character, equivalent to the Char type in previous versions of Delphi.
• WideChar
  A 16-bit character, representing a Unicode character. If the high-order byte is zero, the low-order byte contains an ANSI character.
• Char
  By default, Char is equivalent to ANSIChar. Char works in the same way as the implementation-dependent Integer type, which is equivalent to SmallInt in 16-bit versions of Delphi and to LongInt in 32-bit versions of Delphi. In Delphi-32, Char defaults to an 8-bit value.

The semantics of all the character-pointer types are identical. The only thing that varies is the size of the character pointed to.

String Type
Delphi-32 supports strings of nearly unlimited length in addition to the 255-character counted strings previously supported. A new compiler directive, $H, controls whether the reserved word "string" represents a short string or the new, long string. The default state of $H, is $H+, using long strings by default. All Delphi-32 components use the new long string type.
These are the new string types.

• ShortString
  A counted string with a maximum length of 255 characters. Equivalent to String in Delphi 1.x. Each element is of type ANSIChar.
• AnsiString
  A new-style string of variable length, also called a "long string." Each element is of type ANSIChar.
• string
  Either a short string or an ANSI string, depending on the value of the $H compiler directive.
• WideString
  A long string, with each element being of type WideChar.

Short String operation	Long string equivalent	Explanation
PString type	string	All long strings are dynamically allocated, so PString is redundant and requires more bookkeeping.
S[0] := L	SetLength(S,L) SetString(S,P,L)	Because long strings are dynamically allocated, you must call the SetLength procedure to allocate the appropriate amount of memory.
StrPCopy(Buffer, S)	StrPCopy(Buffer, PChar(S))	You can typecast long strings into null-terminated strings. The address of the long string is the address of its first character, and the long string is followed by a null.
S := StrPas(P)	S := P	Long strings can automatically copy from null-terminated strings.

Long strings cannot be passed to OpenString-type parameters or var short-string parameters.

Variant Type
Delphi-32 introduces variant types to give you the flexibility to dynamically change the type of a variable. This is useful when implementing OLE automation or certain kinds of database operations where the parameter types on the server are unknown to your Delphi-built client application.
A variant type is a 16-byte structure that has type information embedded in it along with its value, which can represent a string, integer, or floating-point value. The compiler recognizes the standard type identifier Variant as the declaration of a variant.
In cases where the type of a variant is incompatible with the type needed to complete an operation, the variant will automatically promote its value to a compatible value, if possible. For instance, if a variant contains an integer and you assign it to a string, the variant converts its value into the string representing the integer number, which is then assigned to the string.
You can also assign a variant expression to a variable of a standard type or pass the variant as a parameter to a routine that expects a standard type as a parameter. Delphi coerces the variant value into a compatible type if necessary, and raises an exception if it cannot create a compatible value.

Currency Type
Delphi-32 defines a new type called Currency, which is a floating-point type specifically designed to handle large values with great precision. Currency is assignment-compatible with all other floating-point types (and variant types), but is actually stored in a 64-bit integer value much like the Comp type.
Currency-type values have a four-decimal-place precision. That is, the floating-point value is stored in the integer format with the four least significant digits implicitly representing four decimal places.

Changed Data Types
The implementation-dependent types Integer and Cardinal are 32-bit values in Delphi-32, where they were 16-bit values in Delphi 1.x. To explicitly declare 16-bit integer data types, use the SmallInt and Word types.

Additional Syntax
You can include an optional finalization section in a unit. Finalization is the counterpart of initialization, and takes place when the application shuts down. You can think of the finalization section as "exit code" for a unit. The finalization section corresponds to calls to ExitProc and AddExitProc in Delphi 1.x.
The finalization begins with the reserved word finalization. The finalization section must appear after the initialization section, but before the final end. statement.
Once execution enters an initialization section of a unit, the corresponding finalization section is guaranteed to execute when the application shuts down. Finalization sections must handle partially-initialized data properly, just as class destructors must.
Finalization sections execute in the opposite order that units were initialized. For example, if your application initializes units A, B, and C, in that order, it will finalize them in the order C, B, and A.
The outline for a unit therefore looks like this:

  unit UnitName;
  interface
  { uses clause; optional }
  ...
  implementation
  { uses clause; optional }
  ...
  initialization { optional }
  ...
  finalization { optional }
  ...
  end.

Porting (1) - Integer Types
This article will be the first of a regular series of tips, tricks and hints to help ease the pain of moving, porting and upgrading Delphi 1.x applications to Win32-land. First published in the UK-BUG Delphi NewsLetter.

First of all, Borland claims that a normal 16-bit project will port to 32-bits with but a single recompile. Well, let's see if we can define normal here...

Normal means we can't use 16-bit VBX controls. For every 16-bit VBX control, we have to find a 32-bit OCX counterpart (or just replace it with native VCL code from somewhere else). Now you know why I prefer to use the LightLib VCL over the ChartFX VBX controls. The same holds for general DLLs, of course: for any 'foreign' DLL that you rapplication is using, you now need to obtain the 32-bit version of this DLL. And you can expect that in the first few weeks after the next version of Delphi ships, only the standard Delphi add-on DLLs that are supplied by Borland (such as the 32-bit BDE) will be available.

Ok, so we must be careful for external files. That's not so bad, is it? but even for a fully native Delphi program, there are things to watch out for when porting to 32-bit. Like 16- or 32-bit data types, for example. The 16-bit Borland Pascal had the following fundamental integer types: byte, word, shortint, integer and longint. Delphi 1.x also introduced the smallint, which is in 16-bit world the same as integer, and cardinal, which is in 16-bit world the same as word. In the next release of Delphi (the 32-bit version 2.0), both integer and cardinal will be 'upgraded' to 32-bits. We could state that integer and cardinal are the 'native' machine words (resp. signed and unsigned).
In a table, the complete overview is as follows:

Borland Pascal		Delphi 1.x		Delphi-32
ShortInt	-128..127	ShortInt	-128..127	ShortInt	-128..127
		SmallInt	-32768..32767	SmallInt	-32768..32767
LongInt	-2G..2G-1	LongInt	-2G..2G-1	LongInt	-2G..2G-1
Byte	0..255	Byte	0..255	Byte	0..255
Word	0..65535	Word	0..65535	Word	0..65535
Integer	-32768..32767	Integer	-32768..32767	Integer	-2G..2G-1
		Cardinal	0..65535	Cardinal	0..2G-1

So, if we want to write portable code between Borland Pascal and the 16- and 32-bit versions of Delphi, we are to be careful with the native integer and cardinal types (especially when these are read from files).

Note that the 32-bit cardinal type is in fact 31-bits, since it would take a 33-bit type to be able to parse both 32-bit integer and 32-bit cardinal values. If you wonder about that, consider this: in the 16-bit world, we had 16-bit unsigned words, ranging from 0 to 65535, and 16-bit signed integers, ranging from -32768 to 32767. In order for the compiler to be able to parse values from the combined range of -32768 to 65535, it actually needed at least 17-bit integer type (17-bit or more, that is). That's why even the old Turbo Pascal already had the LongInt type; a 32-bit signed long integer type, capable of parsing values from the 16-bit Word and Integer ranges (and the LongInt range itself of course). The availability of the LongInt type to the end-users of Turbo Pascal was just an added bonus; Borland could have kept it to itself, but they obviously decided to let us share this first 32-bit type! Now, back in the 32-bit world, the 32-bit version of Delphi still only has a 32-bit signed long integer as 'biggest' integer type; there is no such thing as a 64-bit integer (or at least a 33-bit integer). So, there is no way the compiler can parse a value from a combined -2G..4G-1 range (the combined range from a 32-bit signed integer and 32-bit unsigned word). The only solution was to drop the 32-bit unsigned word range to 31-bits, or create a 33-bit type integer of their own. Since the last solution would cost too much (also in performance!) it was obviously decided to just drop the range of the 32-bit Cardinal to 31-bit, and hence the range of 0..2G-1 for the Cardinal type.

Porting (2) - Long Strings
As a long-term Turbo Pascal user, I've known Strings to be limited to 255 characters only, with the 0th 'character' being the actual length-Byte (range 0..255). This lead to dirty-but-fast code such as the following to trim the spaces on the right side of the String:

  procedure RightTrim16(var Str: String);
  var Len: Byte absolute Str; { Len is overlaid with the 0th length byte of Str }
  begin
    while Str[Len] = ' ' do Dec(Len)
  end {RightTrim16};

A Long String is just what is says: a long String, of up to 2Gb characters in size (in practice a long String is limited by the amount of available memory on your machine). Since we now need a LongInt to store the size of the long String, the 0th character (or byte) is no longer sufficient to indicate the Length of the string. And hence, all legacy code that reads, writes and uses this 0th byte has become a severe cause for Access Violations. Using the old memory layout, we could state that the Length LongInt (4 bytes) now starts at offset -3. But that's not all. A long String also has a Reference Count LongInt at position -7, and a Allocation Size LongInt at position -11. Long String constants do not have the allocation size LongInt, but only the first two.

Length
Now that we know we cannot use the 0th Byte of a string as length indicator, how can we remove the trailing spaces from a long String? Well, we can still use the Length function to get the length of a String. We only need to realise that it's a 32-bit integer now. To remove trailing spaces from a (long) String, we now need to walk back from the end of the long String and count the number of spaces that are at the end. After having counted them, we can just Delete them from the String (you don't want to Delete the spaces one at a time, since this could involve copying the long String for every Delete operation, something you'd like to avoid as much as possible for performance's sake).

  procedure RightTrim32(var Str: String);
  var SPos,SLen: Integer;
  begin
    Spos := Length(Str);
    if Str[SPos] = ' ' then { are there trailing spaces to begin with? }
    begin
      SLen := 0;
      while (SPos > 0) and (Str[SPos] = ' ') do
      begin
        Inc(SLen);
        Dec(SPos)
      end;
      Delete(Str,SPos+1,SLen);
    { SetLength(Str,SPos); }
    end
  end {RightTrim32};

  {$IFNDEF WIN32} { to make sure it doesn't get added into Delphi-32 code }
  procedure SetLength(var Str: String; Len: Integer);
  begin
    Str[0] := Chr(Len);
  end {SetLength};
  {$ENDIF}

  procedure RightTrim16and32(var Str: String);
  var SPos: Integer;
  begin
    Spos := Length(Str);
    if Str[SPos] = ' ' then { are there trailing spaces to begin with? }
    begin
      while (SPos > 0) and (Str[SPos] = ' ') do Dec(SPos);
      SetLength(Str,SPos);
    end
  end {RightTrim16and32};

  function TrimRight(const S: string): string;
  { TrimRight trims trailing spaces and control characters from the given
    string. }
  var I: Integer;
  begin
    I := Length(S);
    while (I > 0) and (S[I] <= ' ') do Dec(I);
    Result := Copy(S, 1, I);
  end;

Reference Count
When a long String is copied, the reference count of the original is incremented and only a pointer is copied. This takes very little time, which explains why even copying long Strings of several megabytes long takes no time at all. Of course, once you change the copy (assign something new to the 12,345,678th element of a 20Mb long String) then the actual memory for a new long String must be allocated to hold the 20Mb long sting copy with the new 12,345,678th element. This is referred to as 'copy-on-write', but I would rather call it a 'delayed-performance-hit', since that's what your users will be experiencing. There are ways around it, such as using the UniqueString function, but that is not really a portability issue anymore...

To make a Long story Short...
Finally something to take care of when writing or calling procedures that have var parameters of type string, and local variables. I sometimes get reports of people having Access Violations after using the copy procedure to assign data to one of the var parameters. It seems that Delphi thinks these parameters are huge strings even if you set this option to off ($H- or the Compiler | Options box).
This leads to my final recommendation for this month: except when you're writing general string routines, always explicitly state whether you're using a long or a short string. Don't depend on the {$H} compiler directive (which works on a unit basis), but use the ShortString and AnsiString predefined types instead. The compiler may use a String as a Long String while you think it's a Short String or vice versa, but when you use ShortString or AnsiString types this will never happen.

Porting (3) - Components
Components come in many shapes and sizes. In source or .DCU form, with or without supporting DLLs. Not every one of them will port to Delphi-32 easily. For example, if we only have the 16-bit compiled .DCU file for a Delphi 1.x component, we'll get the following fatal error when we try to add it to the 32-bit component palette of Delphi-32:

Now, why would Delphi-32 need the source file when the compiled version is already available? Well, first of all, the .DCU file format is subject to change with every release of Delphi. For previous Borland Pascal programmers this may not come as a surprise, since the .TPU file format changed also with every major release of Turbo/Borland Pascal. But the major reason is of course that Delphi-32 needs 32-bit code to be generated, and this includes the .DCU file. Which leads to our first observation: without source code, you cannot add your Delphi 1.x components to Delphi-32's Component Palette.
Now, suppose we have the source code, and install the component. We also need to check if it isn't needing a VBX or DLL. VBXs won't be supported at all by Delphi-32 (and are replaced by OCXs), and for DLLs we can basically use the same rule as above: an existing 16-bits DLL cannot be used by Delphi-32 (unless we go through a complex and painful process of thunking down to the 16-bit DLL, a topic we won't discuss here).
For component users, it all boils down to one thing: the component builder must have made special precautions to make the component work in Delphi-32. For component builders; read the remainder of this column for an insight in problems we can expect...

Component Builders
First of all, Component Builders need to ask themselves a good question: are we willing to answer support calls by users trying to install the wrong version of our .DCU files, or do we just distribute the source code so Delphi (1 and 2) can re-compile this source while installing the components. The later solution might decrease the support our component users need. Besides, the changing .DCU file format may be a major reason NOT to use any component that doesn't come in source form (note that the source doesn't have to be part of the demo, just make it available if/when people buy or register the package).
Distributing the source code of a component leads to another recommendation: always (try to) make your source code compile with both Delphi 1.x and Delphi-32. This will enable our component users to just install the same source file with either or both Delphi 1.x and 2. Without problems of using the wrong version in the wrong place. It will also ensure to our component users that the same set of features will be available for the 16-bit and the 32-bit version. Orpheus version 2 (by TurboPower) is a good example of this; the new version can be used with both Delphi 1.x and 2, and yet uses a single source code set.
Of course, it is highly unlikely that a single set of source code can compile in Delphi 1.x and 2 as-is. At some places we may need to distinguish between the compiler versions, and to do that we can use the predefined compiler directive WIN32.
A first place where we can use this is the place where we include the .RES file that contains the component bitmap for the component palette. This file is normally distributed as the .DCR file, but since the 16-bit file format changed when moving to 32-bit, we can no longer distribute a single .DCR file. And since we want to use a single source code set for both versions of Delphi, we have to think of another way. A solution is to rename the .DCR file (so the compiler won't find it automatically) and include the 16-bit or 32-bit version of the renamed .DCR file depending of the compiler version. A good way of dealing with all these problems is the following: we should rename the 16-bit version to .R16 and the 32-bit version to .R32, and use the following code to include either resource file:

{$IFDEF WIN32}
  {$R COMPONENT.R32}
{$ELSE}
  {$R COMPONENT.R16}
{$ENDIF}

{$IFDEF WIN32}
  ListBox1.Items.Text := 'Bob'#13+
                         'Yvonne'#13+
                         'Erik'#13+
                         'Tasha';
{$ELSE}
  ListBox1.Items.SetText('Bob'#13+
                         'Yvonne'#13+
                         'Erik'#13+
                         'Tasha');
{$ENDIF}

{$IFDEF WIN32}
  {$IFDEF VER9}
    // this only works in Delphi 2.0
  {$ELSE}
    // but here's a new feature for Delphi 3.0 and up...
  {$ENDIF}
{$ELSE}
  { and here is Delphi 1.x code using the old comment style }
{$ENDIF}

DLLs
For DLLs basically the same is true. We should (try to) use a single source set to compile to a 16-bit and/or 32-bit DLL. An additional problem is the fact that the sharing of the DLLs data segment (by multiple instances of the same 16-bit program) doesn't work anymore with a 32-bit DLL, since each instantion of the DLL runs in its own memory space. We need to use a WIN32 feature called memory mapped files to actually be able to share information in the same DLL (again a topic we won't discuss at this time).
Components that need support DLLs should unfortunately, be accompanied by two versions of the DLL, one 16-bit and one 32-bit version. Fortunately, both need to be installed in different directories, so the component builder "only" needs to ensure his installation program is working correctly (what installation program?).

Porting (4) - 32-bits DLLs
This time, we'll focus on Dynamic Link Libraries (DLLs) and how they differ in 32-bit Win95/NT World from the plain old 16-bit Windows World we've been used to the past few years.

The DLL
A dynamic link library can be used to share code (and/or resources) between different applications. It is a library of code, that can be loaded dynamically on demand (if needed, or preloaded).
When porting a DLL to Win32, we need to change only a few things: the calling convention and the exporting of the functions.

stdcall
With 16-bits Delphi 1.x DLLs we needed to export the functions to the outside world using the export keyword. In Win32, this keyword is replaced by the stdcall (actually a new Win32 calling-convention), and export is now meaningless. This means we need to use our first {$IFDEF} here to make sure our functions are defined correctly regardless of the version of Delphi:

  function MyFunction(Param1: Integer; Param2: PChar): Word; export;
          {$IFDEF WIN32} stdcall; {$ENDIF}

no index
Delphi 1.x can export functions by name and index number. In Win32, functions are no longer exported by index, but only by name. The index number is only used as a hint to indicate to the loader where to start looking for the specified function name. While this doesn't lead to much different code, it's good to realise what goes on behind the scenes!
We can still return index (hint) numbers as well as names as follows:

  exports
    MyFunction index 1 name 'MYFUNCTIONNAME';

The Import Unit
When porting an import unit to Win32, we need to adjust a few things: the stdcall calling convention, of course, but also the library extension and the resulting handle type when using LoadLibrary.

importing
Unlike 16-bit DLLs, we now need to specify the DLL extension with the library name. Note that Win95 works in both cases (i.e. either the DLL extension or no extension), while WinNT only works with extension. To avoid problems, we should use an extension always when importing a 32-bit DLL. This leads again to a simple use of {$IFDEF} in our import unit:

  Const
    LibName = 'MYLIB' {$IFDEF WIN32} + '.DLL' {$ENDIF} ;

handle
We can use the resulting LibName in two ways: either by specifying it with an implicit import function definition, as follows:

  function MyFunction(Param1: Integer; Param2: PChar): Word; stdcall;
           external LibName index 1; { index is only a hint here }

  begin
    LoadLibrary(LibName);
    @MyFunction := GetProcAddress(DLLHandle, 'MYFUNCTIONNAME');
    { now you can just call MyFunction() }
    FreeLibrary(DLLHandle);
  end

  MyFunction: function(Param1: Integer; Param2: PChar): Word
              {$IFDEF WIN32} stdcall {$ENDIF};

The DLLHandle is a bit more tricky, as it's a Word in 16-bit import units, but a DWORD in 32-bit import units. I changed it into a Cardinal, to be usable in both environments without having to use an {$IFDEF}. If you forget to change it from a Word, you won't get any compiler errors, but the DLL will seem to have not loaded at all (I got an error message 0, telling me the DLL itself might be corrupted in some way - a real time-consuming problem if you're looking in the wrong way ;-)

Note that a general THandle might even a better solution, which would have been portable in the first place...

1. OLE
2. BDE
3. QReports
4. DCU Formats
5. Packages
6. TTreeView
7. TDataSet
8. TypeLibraries
9. Internet and Web Features
10. Decision Cube
11. TeeChart
12. ReportSmith

  IFoo = interface(IUnknown);
  Tfoo = Class(TObject, Ifoo);

  if IsEqualCLSID(iid, IMalloc) then

2. Borland Database Engine
Migrating applications that use the BDE from Delphi 2 to Delphi 3 is not very involved. The main concern is how you will use the new features. Check out the Delphi 3 help file topic Compatability with Delphi 2. This covers a number of issues that are likely to be of interest to BDE users migrating. The following are the highlights of the new features:

• The BDE Administrator is the new tool for configuration and administration of the BDE. It has all the capabilities of the old BDE Configuration tool that deployed with Delphi 2 but shares the look and feel of the Database Explorer.
• There are 2 new drivers allowing Delphi applications to use data from MS Access tables and FoxPro without using ODBC. This includes support for CDX indices in FoxPro.
• Two new BDE API functions, DbiAddDriver and DbiDeleteDriver, allow adding and deleting of drivers from the current BDE configuration or session.
• The BDE now automatically adds ODBC drivers and data sources as BDE aliases to the active session when they are not currently stored in the configuration file.
• Binding Blobs as parameters in Queries and Stored Procs.
• ODBC 3.0 support.
• SQL Monitor can now display the value of bound parameters.

4. .DCU Formats
When a project is compiled or run, Delphi's compiler produces an intermediate output file on disk from a unit's source code. This compiled version of a unit is stored in a binary-format file with the same name as the unit file, but with the extension .DCU (Delphi Compiled Unit). A .DCU file should not be edited or opened under any circumstance and is not necessary for deployment. Since this is a proprietary format it is liable to change from version to version of the product. If a project is created in Delphi 1 or Delphi 2 the only files necessary to recompile it under Delphi 3 are the .DFM, .PAS, and .DPR file.
If a project contains resource files (.RES) consisting of custom cursors, icons, etc. they will also need to be included. It is critical to NOT relocate the .DCU files along with the other files as that it may lead to strange and unexplainable behaviors with an application.

5. Packages
Packages (.DPL) are special dynamic-link libray used by Delphi 3 applications, the IDE or both (see DELPHI3.HLP). Packages come in two flavors, runtime and design-time. Runtime packages providefunctionality when running an application while design-time packages provide development phasefunctionality. One notable change in Delphi 3 concerning packages is of using ExitProc() (seeDELPHI3.HLP, 'Changes introduced by packages'). For more information on the new file types introduced by packages see TI3213 - Delphi 3 File Types with Descriptions.

Migration Issues
A. 3rd Party Components: (see DELPHI3.HLP, 'using older third party components').
When migrating applications that utilize 3rd party components from Delphi 2 to Delphi 3 it is essential to keep in mind these 3 items:

1. .DCU files are not cross version compatible. The source code is necessary for recompiling 3rd party components under Delphi 3.
2. Changes in the VCL source or version specific syntax may have occured between versions. While the external interface for the VCL will remain the same, the internal workings of the VCL may have changed.
3. Always make sure that the 3rd party vendor provides a Delphi 3 compatible version of their component.

6. TTreeView
If a custom component descending from TTreeView has been created in Delphi 2 the event handlers have been reworked. For example: The OnExpanded, OnExpanding, OnCollapsed, and OnCollapsing events now occur in all parent nodes no matter how the nodes are expanded or collapsed.

7. TDataSet - Database Object Differences
The primary differences in the database component hierarchy between Delphi 2 and Delphi 3 involve the introduction of the TBDEDataSet. In Delphi 2, is was not practical to make data-aware controls that did not use the BDE. TBDEDataSet was designed to implement BDE-specific code and TDataSet was generalized sothat it knew nothing about the BDE and merely knew how to do general things like dealing with records. It is now possible to make objects that descend from TDataSet and implement database functionality without involving the BDE at all. These TDataSet descendent components will then also work with all of the standard Delphi data-aware controls.
Chapter 5 of the Delphi 3 "Developer's Guide" gives details and examples for the TDataSet and Chapter 6 discusses the TBDEDataSet.

Remote Data Sets
Unlike Delphi 2, Delphi 3 gives the developer the ability to make a very light-weight database client where the BDE is actually running on a different machine than the client program. This remote, multi-tier capability is implemented by the new Data Access controls: Provider, ClientDataSet, and RemoteServer. Chapter 18 of the Delphi 3 "Developer's Guide" gives details and examples for using remote data sets.

New Data-Aware Controls
Delphi 3 also implements several nice new database controls: DBRichEdit for storing memo-type data in "Rich Text Format", and the DBChart which uses the Tee-Chart charting engine to quickly make graphs directly for the data in database tables without requiring any code. Chapter 14 of the Delphi 3 "Developer's Guide" discusses the TDBRichEdit control, the TDBChart component as well as all the other Tee-Chart related controls are documented in the "TCHARV3.DOC" file in the ..\Borland\Delphi 3\TeeChart directory after Delphi 3 is installed.

New decision support capabilities were added with the Decision Cube set of components which allow a user to drill-down into their data and do multi-dimensional analysis without any additional programming. Chapter 16 of the Delphi 3 "Developer's Guide" gives details and examples relating to the new Decision Support components.
After many requests, the DBGrid now has the ability to show the contents of database memo fields due to the BDE's new memo caching capability.

8. TypeLibrary Editor
The Type Library Editor is the new feature that allows users to easily open type libraries from .tlb, .ocx, or .exe files that contain them. It also allows the user to generate a type library for deployment or use with other development tools. For more information on the Type Library Editor you can refer to the Delphi 3 Help and search under Type Library Editor, or for more information on type libraries in general search the Help for type libraries. Additional information can be found in the MSDN.

9. Internet and Web Features
Delphi 2 allowed users to create CGI application, ISAPI DLLs, NSAPI DLLs, and WinCGI applications but Delphi 3 now provides a Wizard which greatly simplifies the process and eliminates a great deal of the work involved. Delphi 3 also provides the user with the isapter.dll that eliminates creation of separate ISAPI and NSAPI version of the web application. Finally, with WebBroker, Delphi 3 provides a series of new web enabled components on the internet tab of the component palette. These include components like the PageProducer that simplify web application development and the new socket components that wrap the winsock functionality.

10. Decision Cube - Decision Support Components
In Delphi Client/Server, a new group of components facilitates data analysis for decision support. These components include TDecisionCube, a multidimensional array that caches cross-tabulated data from a dataset; TDecisionQuery, a special dataset object that simplifies use of Decision Cubes; TDecisionSource, which represents a pivot state on data from a Decision Cube; TDecisionGrid, which displays cross-tabulated data from a Decision Source; and TDecisionGraph, which displays Decision-Source data in dynamic graphs.
For further information on these components see the Delphi Help files and from the contents select What's New. Under this heading the Decision Support Components are listed. To create a simple example using the Decision Support Components do File|New..., then select the business tab from the object repository. Now select the Decision Cube object and hit return.

11. TeeChart - TeeChart Graphing Components
100% Native Data-Aware Charting Component Library for Borland Delphi, TeeChart 3 runtime version is packaged with Delphi version 3. It is a fully functional charting library packed with many powerful charting capabilities.
For further information on TeeChart refer to the online documentation including the teechart.hlp file in the default Delphi 3 help subdirectory and the tchartv3.doc file in the teechart directory under the Delphi 3 directory. This component suite also has an exhaustive example program in the demos subdirectory under the Delphi 3 subdirectory. Finally, selecting File|New..., selecting the Business tab, then selecting the TeeChart Wizard allows for rapid use of this component suite.

12. ReportSmith
Delphi 3 no longer deploys with ReportSmith and although the TReport component is not on the Delphi 3 palette it can be added. Simply select Component|Configure Palette, selecting all, and then select the TReport component from the very bottom of the list and then click the Show button. This allows your ReportSmith applications to be migrated to Delphi 3. Keep in mind that Strategic Reporting System is now supporting the ReportSmith tool.

For information on what has changed with respect to deployment of applications be sure to read deploy.txt. This documents the details of supported deployment methods for your application.