Bytes: 4,394 Date: 1996-12-19

(this is superseded by R6003FIX.ZIP found below)

Bytes: 43,764 Date: 1996-11-20

(this is superseded by the CA-Clipper 5.3b patch in the CA-Clipper Mirror)

Bytes: 4,264 Date: 1997-08-22

In October of `96 I (Michael Schneider) wrote a driver to fix the
R6003 error on AMD-Processors, which disables the branch prediction on
the AMD-K5 and K6 processor. The driver works fine, and AMD UK and
Germany sends my drivers to customers who have this problem. Here is
the latest version. It supports all K5-CPU's, Models 0 - 3, and now
also handles the K6.

Load this driver in CONFIG.SYS before loading EMM386!

FREEWARE

Bytes: 309,131 Date: 1994-12-07

Blinker 3.1 upgrade patch from 3.01 version only.

Please note: The 3.0 to 3.01 patch must be obtained directly from
Blink, Inc. by mail. It was never made publicly available.

Bytes: 404,573 Date: 1995-07-04

Blinker 3.2 upgrade patch from 3.1 version only.

Bytes: 325,635 Date: 1995-12-07

Blinker 3.3 upgrade patch from 3.2 version only. English version.

Bytes: 9,958 Date: 1995-08-21

Comix patch for Clipper 5.3

Bytes: 5,891 Date: 1993-04-20

This is Malc Sheddons object that fixes the insidious problems that
S87 and 5.01x were plagued by when faced with newer EMM systems.

If you are having problems running S87 or 5.0x with DOS 6, QEMM or
386MAX, get this file and link it in.

This is not needed for Clipper 5.2 or greater.

Bytes: 37,378 Date: 1996-04-14

This patch contains both a discussion on why Clipper uses all the CPU
time while it is running, and offers several suggestions on what to do
about it, including a patching program which will alter the default
INKEY() activity in an already compiled .EXE.

Bytes: 4,792 Date: 1996-05-31

A C function that provides idle stat announcement to the operating
system. This is intended to allow Clipper to not hog all of the
processor time when run in a multitasking environment.

Requires FT_ONIDLE() from NanForum library to operate.

Bytes: 3,634 Date: 1998-12-12

The enclosed object file __WAIT_B.OBJ is used to fix a problem with
Clipper applications terminating at start up with either an "R6003
divide by zero" message or no error message at all. This problem has
recently reared it's head with the advent of new advanced design
microprocessors. These new design CPUs run "software timing loops" so
rapidly that a software timing loop module which is part of Nantucket
Tools II and CA-Tools III cannot work as designed. Not all Tools
functions use the software timing loop, but it appears to be linked
into your application if you're using either the CTUS.OBJ or CTUSP.OBJ
extended drivers. A few people have reported this problem without
having CTUS.OBJ or CTUSP.OBJ linked in.

The two processors currently exhibiting this condition are the AMD K5
and Cyrix 6x86. As of this writing, AMD apparently has no "fix" of
their own, while Cyrix has a "fix" posted on their web site at
http://www.cyrix.com . Their fix consists of an executable named
PIPELOOP.EXE that is run from the AUTOEXEC.BAT file and causes timing
loops to be slowed down. Another "fix" is to turn off the internal
cache, which will significantly degrade all performance. Please note
this problem is not caused by a defect in the CPUs.

Just add it to your link script ahead of the libraries and ahead of
the extended driver file, if used. PIPELOOP.EXE from Cyrix is no
longer needed. It's been tested on Clipper 5.2 and 5.3. It should work
on 5.01a as well, but no one has reported using it on that version.
There's no need to maintain a separate program version for Intel
processors. It works fine on all brands of CPUs. So far.

The file name itself isn't significant. It's just a new name to
differentiate it from earlier versions.

Bytes: 8,218 Date: 1996-12-19

The two enclosed ZIP files were downloaded from the BlinkInc BBS and
fix a GPF problem when using Loadstone's COMIX 3 RDD. I don't know
which version the problem started with, but it's present in Comix
3.00.08.

The GPF occurs intermittently, almost always when opening the index
file or when changing the order in the index file. For me, it suddenly
appeared after making some minor code changes, and always when opening
a non-structural index file. Others have reported it has occurred when
running in a loop, although I don't know what they were doing with
their loop.

The RDDORDT.OBJ file must be added to your link script ahead of any
call to the Comix libraries. I have it before my SEARCH BLXCLP52 line
and it's very happy.

CDXFIX.ZIP has the object file for Clipper 5.2 and CDXFIX53.ZIP has
the object file for Clipper 5.3. I do not know if this was fixed in
5.3, as I'm not using 5.3 at the moment.

Bytes: 33,481 Date: 1998-11-16

There is no "SET EPOCH TO nn" implemented in Clipper Summer87, at
least none that is documented. There appears, however, to exist in
the standard CLIPPER.LIB the facilities to implement such an EPOCH
facility (perhaps the feature was never released by Nantucket). The
files here exploit this existing code, and are an attempt to thereby
avoid any Y2000 problems where only 2-digit years are used.

1. Usage
~~~~~~~~
There are two methods provided for setting the epoch:

(a) setting a DOS environment variable ('EPOCH') which will be
consulted automatically as your program loads. For example to set
the epoch to 80 (ie. 2 digit years of 79 or below will be assumed
to be 21st century dates), use:

SET EPOCH=80

This can be entered at the DOS prompt, though probably more
usefully will be included in AUTOEXEC.BAT.

(b) using the new EPOCH() function. The calling syntax is similar to
the SETCOLOR() function, eg.

nCurrent_epoch = EPOCH (nNew_epoch)

where 'nCurrent_epoch' is the existing value (normally zero at
startup unless preset by (a) above) and 'nNew_epoch' is the
desired EPOCH setting, in the range 0 to 99. This latter
parameter is optional, and if omitted or is outside the permitted
range, nothing will be changed and the current EPOCH setting is
returned.

Includes a replacement for LUPDATE() (s'87 only) which correctly
handles centuries after 1999.

Bytes: 178,399 Date: 1998-10-06

(this is a newer patch than vrdr2upd.zip)

SYMPTOMS

Database programs running in Windows 95 OEM Service Release 2 (OSR2)
or 2.1 (OSR 2.1) over a Microsoft network may damage the database.

CAUSE

When a program uses the GetFileSize() API to get the size of an
existing file on a Microsoft networking server (such as a Windows
NT-based server), the Client for Microsoft Networks may not return the
correct file size. When the program then attempts to write additional
information to the end of the file, it may overwrite existing data
instead.

This problem has been observed only with the version of the Client for
Microsoft Networks (Vredir.vxd) included with OSR2 (version 4.00.1111)
and later.

STATUS

This issue is resolved by the following updated file for Windows 95
OSR2:

vredir.vxd version 4.00.1116 (dated 9/11/97) and later

Bytes: 118,796 Date: 1997-09-05

This is a early release patch from Microsoft that fixes the broken
file shareing problem in the (OSR2) version of Windows '95.

This patch is needed if you are experiencing data corruption when
using a W'95 machine on an NT server, but can be installed on any
machine without ill effects.

If you are running FAT32, then you are running (OSR2).

Bytes: 3,739 Date: 1996-12-12

Some text explaining which file from Symantec causes the debugger to
stop working under Windows '95

Bytes: 7,594 Date: 1998-09-20

This software provides an equivalent to SET EPOCH TO for Summer '87.

These notes and the accompanying software have been placed in the
Public Domain by their author, Roderick McLeod.