Delphi Environment 
 

Program EXE depends on Delphi design-time and compile-time environment
(see below for some run-time issues)

Being a source control fanatic from way back (I used to fix and compile PDP-11 assembler language programs that I could not even run - see source code control techniques if you want the gory details) I like having a good "handle" on the programs I compile. Delphi and Windows make this difficult in several ways. I've read a few articles over the years in "The Delphi Magazine" that address this issue (details below).

I've always made heavy use of Beyond Compare to verify my changes (including binary DFM changes) between versions of programs I ship. I also use VmWare to test programs on older versions of Windows.

How many ways does the developer's computer affect the compiled EXE?

Design-time

When you load images into TImageList the Delphi compiler uses the Microsoft ComCtl32 dll to stream in the images. If you run your compiled program on a PC with an older version of ComCtl32.dll then your images may not appear correctly. There are several ways to get around this problem. The first solution is to distribute the comctl update with your application. Or, if your program's GUI needs are simple and you'd rather not ship anything other than your application EXE then you can put your images into TImage components and load them dynamically into the TImageList at run-time. Another similar method is to put the images into a resource that is added to your project and then load that resource into the TImageList at run-time.

When you save a form with a TImageList the Delphi compiler saves the image in the DFM with the color depth of the developer's computer. If you want to reduce the size of the DFM file (and reduce the resource requirements of your program) you can use TImage components or a resource as mentioned in the previous paragraph, or you can reduce the color depth on the developer's computer, save all DFMs that have TImageList components, and recompile the program.

If you use XP for your development environment, you should heed the warnings at this Borland page: http://community.borland.com/article/0,1410,28423,00.html (Microsoft ComCtrls and Delphi/C++Builder version 6 - by Eddie Churchill) from which we quote: "We are planning to support the new ComCtrls in the next major release. Until then please don't add a manifest to Delphi or C++Builder itself or it will start using the new ComCtrls and in turn start writing out Image List streams that are wholly incompatible with anything except Windows XP's ComCtrls v6. You will regret it, trust me."

Compile-time

If you use ResourceString to define your string constants the compiler uses the Windows API to load the strings when creating the resources (which uses the default codepage to do the conversion). I had to change "ResourceString" to "Const" to compile the multi-byte Chinese language program I wanted (I plan to go back to ResourceString and internationalize the program with separate resources later).

I hope there are not very many issues like the above that we need to be aware of to get reproducible results from our compiles. If the compiled binaries are compared to verify reproducible results, there are several other issues:
1) There are timestamp differences and also unused memory (for data alignment) that may not initialized to a consistent value.
2) The DVCLAL resource is compiled into the executable and identifies the compiler version and edition (Std, Pro, Enterprise). Search SysUtils for DVCLAL and GDAL for details.


Run-time requirements

Many times I want to create simple Delphi programs that will run on original Win95 systems with the least amount of problems. I do not want to have to update DLLs on the user's system (or ask them to do that).

I'd like to find an accurate summary of common components and properties that require later DLL versions. One example is the ToolBar.Flat property. How many other similar items lurk within the common VCL controls?

The Delphi-3 Readme.txt file had the information below but I haven't found a similar summary for Delphi-5. If you know of such a summary please let me know. Other components and properties to be careful with are: TImageList, TCoolBar, TListView.FlatScrollBars.

New! - An article on the new docwiki looks useful: Components Available Only on Specific OS

COMCTL32
--------
Several of the components on the Win32 palette page function best with the latest version (4.70) of COMCTL32.DLL. TCoolBar and TDateTimePicker will not work at all unless version 4.70 or later is installed. In addition, the following properties require version 4.70:

TToolBar.DisabledImages
TToolBar.Flat
TToolBar.HotImages
TToolBar.Images

TTabControl.HotTrack
TTabControl.ScrollOpposite
TTabControl.TabPosition

TPageControl.HotTrack
TPageControl.ScrollOpposite
TPageControl.TabPosition

TListView.Checkboxes
TListView.HotTrack
TListView.GridLines
TListView.RowSelect
TListItem.Checked

The Min, Max, and Position properties of TProgressBar must fall within the range of 0 - 65535 if the installed version of COMCTL32.DLL is less than 4.70.

Delphi-2005 issues

It has been reported that if you use THandleEvent, TEvent, or TMutex from the SyncObjs unit your program may not run on Win95.

Delphi-2006 issues

Missing msimg32.dll - This dll is not present on 95/NT4 and is needed for the toolbar gradient. Don't use the toolbar, or use an earlier version of Delphi to compile. This QC Report also presents a solution. This problem may be fixed in Delphi 2007.

Missing oleacc.dll - This dll is not present on Win95 or Win98 (first edition). Here are some possible ways to deal with the problem:
1) Install Microsoft Active Accessibility (MSAA) on the machine (this is available for download on Microsoft's web site).
2) Put some conditional code into oleacc.pas that allows you to build an application that is Win95
compatible inside Delphi 2006. Recompile oleacc.pas and place the oleacc.dcu file in the <BDS>\Lib\ directory.
3) Find out what is pulling the oleacc unit into your application and try to eliminate that. Maybe it is the use of actions?

Missing Gdiplus.dll - This dll is included only on XP and Server 2003 and is required by some newer Delphi third-party components. You can get this redistributable from the Microsoft website and install it into your application folder.

Delphi-2009 issues

TLinkLabel component requires user to have theme support enabled. Windows 2000 doesn't support themes. Theme support can be disabled on XP.

TButton->Style properties require Vista to add a drop-down menu to the button.

New! - Delphi-2010 issues

If your program uses ADO and when you run it (on Windows 2000?) it starts up briefly but then goes away without any dialog you might need to install a newer version of the Microsoft Data Access Components (MDAC).

Would be nice to have? - A tool that uses Dependency Walker to look at the program EXE and then uses DLL Help to list what required dlls are not included on the different versions of Windows. Please let me know if you are aware of such a tool. Thanks!


Other strange run-time issues

Do you have a Delphi program that works good except that it causes Win98 to crash on some machines (with VIA hardware drivers)? Search http://www.fulltextsearch.com or google groups for "ezerodivide Win98" and you'll turn up some interesting threads.

The "Invalid floating point operation" exception can be caused by using a DLL for which FPU exceptions are disabled. That search mentioned above (for "ezerodivide Win98") will also turn up an interesting message from Danny Thorpe (on 4 Sept. 2003) about Delphi-5 Trunc() problems (per Danny this was resolved in Delphi-6).

Here are two interesting QC entries about the FPU Control Word:
http://qc.codegear.com/wc/qcmain.aspx?d=5928
http://qc.codegear.com/wc/qcmain.aspx?d=8399

If you use OpenGL then search http://msdn.microsoft.com for "Borland DirectX" and you'll read that "Compilers from Borland report floating-point exceptions in a manner that is incompatible with Microsoft® Direct3D®." and you'll find a work-around.

When using Windows 2000 SP1 on some motherboards (VIA again?), QueryPerformanceCounter can return incorrect results if it isn't called frequently enough (4.5 seconds), or if it is called continuously. See these pages for more information:
http://blogs.teamb.com/CraigStuntz/archive/2005/04/19/QueryPerformanceCounterHardwareBug.aspx
http://www.etestinglabs.com/bi/cont2000/200012/perfcnt.asp

Craig Stuntz has an informative blog article: Why an App Might Disappear Without Notice


Controlled compile environment

Some folks have found it beneficial to set up a separate computer or environment so release versions of programs can be compiled in a controlled manner. Using the Delphi DCC32 command-line compiler in such an environment is simplified because custom components do not need to be installed on the Delphi component palette.

Here are some magazine articles that cover this in detail:

"Refactoring In The Real World" by Brandon Smith in The Delphi Magazine issue 66 (February 2001)

"A Better Build Process" by Primoz Gabrijelcic in The Delphi Magazine issue 49 (September 1999)

"Creating A Delphi Build Process" by Dave Collie in The Delphi Magazine issue 38 (October 1998)

A build automation tool that has good reviews: FinalBuilder


Other Delphi resource pages on this web site

Cleaning up the Delphi uses statements
Detecting an Internet Connection


Engineering and Communication Systems Programming

Available at reasonable rates for contract or part-time employment via telecommute with occasional on-site. Small projects and maintenance projects are welcomed.

Return to recent projects and experience

Return to home page for Breneman Labs
Show this image for email address

BRENEMAN LABS
Customer support is our top priority!
Contact information on home page
email: see the image to the left