The Holmes Page: CA-Clipper Tips & Tricks

Home

Web Design

Programming

Fairlight CMI

Soap Box

Downloads

Links

Biography

About...

Site Map

Running on Windows NT

CA-Clipper

Opportunities

Tips and Tricks

Networking

Internal Errors

Source Code

CA-VO

BACK TO
CA-CLIPPER
TIPS & TRICKS

I have received quite a few questions about running CA-Clipper applications on Windows NT. This page collects some of the answers in one place. If you have anything to add, send it in.

If your application fails and displays an internal error number, you can look for it on my Internal Errors page.

Most of the problems are not immediately obvious. For example, NT is generally quite picky about direct hardware access. This may cause problems for some CA-Clipper programs, although there is usually a VXD installed that "virtualizes" the hardware to allow programs to access it.

Use The Latest Drivers

So the first thing to check is that you are using the latest drivers, both VXDs and DLLs. Because CA-Clipper apps often access data files on remote servers, make sure that the network drivers are up-to-date.

Update The Compiler and Linker

Make sure that you have all of the patches for CA-Clipper. I use version 5.2e, which is stable although no longer sold by Computer Associates. Version 5.3 is still being maintained and patched by CA, but some popular third-party libraries were not modified to work with that version. CA-Clipper patches are available from CA's CA-Clipper patch directory or at The Oasis CA-Clipper Mirror.

Also upgrade to the latest version of your linker. I use Blinker, because it is the best!

Upgrade Third-party Libraries

It is increasingly hard to find third-party libraries for CA-Clipper. Those products which managed to expand beyond CA-Clipper are still around, like the Blinker linker which works with practically every language in use today.

I try to minimize the use of third-party libraries in my applications. One reason is that my clients often require all the source code for the systems, but source is usually not available for libraries. Some libraries went "public domain" as their developers moved on to other things (Class(y) is a good example), while others are hard to find (like the SIx RDD) but at least are still available.

I'd like to add some links and contacts here for third-party products, so if you know any, please send them to me.

Fix The "Divide By 0" Error

One less obvious problem with Windows NT is that most machines capable of running it are "faster" processors, which in turn may cause the "6003 Integer divide by 0" error in CA-Clipper programs. This is not caused directly by NT, but by the hardware required to run it. When a CA-Clipper application starts, it runs through a test loop to determine the speed of the processor. On faster machines the loop runs so fast that the time taken is "0", which later causes the error. See my Internal Errors page.

Enable Background Execution

Make sure that CA-Clipper apps are given some "background processing" cycles. In Win95, this is handled by the "Always suspend" option on the "Misc" tab of the "Properties" dialog. Of course it should NOT be checked. If the app is not given background processing, it is possible that file locks will be needlessly extended causing other users to have trouble accessing records if one user switches away from the app (or a screen saver kicks in).

Release Processor Cycles

Since CA-Clipper apps were not intended to run on multi-tasking operating systems, they tend to "hog" the CPU cycles. This makes running them under Citrix WinFrame or NT Terminal Server edition unworkable. The solution is to include code to release the CPU during "idle" times, such as while waiting for keyboard input from the user. You can do this with the NanForum library or with OSLIB, both available on The Oasis. Presumably, both libraries use the "Release CPU" call (INT 2F Function 1680).

Here's what I do: I use a couple of simple pre-processor statements to give me the option of using either of the two libraries.

// The following lines use NANFOR.LIB.

	//   #xtranslate OS_Yield()     => FT_IAmIdle()

	//   #xtranslate OS_AutoYield() => FT_OnIdle( {|| FT_IAmIdle()} )

	

	// The following lines use OSLIB.LIB.

	#xtranslate OS_Yield()     => OL_Yield()

	#xtranslate OS_AutoYield() => OL_AutoYield( .T. )

At the beginning of the program (or in an init procedure), I call the OS_AutoYield() pseudo-function. Then in my "event loop" (while waiting for a key) I call OS_Yield(). The CPU utilization typically drops from 96% to 2% or so. No kidding!

The call to OS_AutoYield() provides a general release of CPU cycles whenever the app is in an "idle" state, such as when performing memory management. By itself, it will reduce the CPU utilization to around 30%. However, to get a real improvement you also need to call OS_Yield() as often as possible, which is why it should be included in your keyboard handling loop.

More...

If you have any tips on making CA-Clipper applications work (better) under Windows NT or Win9x, send them in.