Originally published at migrationparity.com.
The inquiry came through the site's contact form on a Monday: a small insurance
firm in the American South, still running the agency management system it bought
in 1997. The software worked. The data was fine. But on the office's new
Windows 11 laptop, under the vDos DOS emulator, every report ended in the same red
box — "Couldn't access temporary file" — and nothing had printed for months. The
old Windows XP machine, where everything worked, had just refused to boot.
The owner didn't want a migration. They wanted their balance sheet.
What was actually running
It was a Clipper-built agency management package from 1997 — vendor long gone, no
source code, modules for marketing, accounting and document imaging. Reports go
through an embedded R&R Report Writer runtime from 1995. Printing was designed for
an HP LaserJet on a serial port, speaking PCL. The office's current printer is a
Wi-Fi inkjet that has never heard of PCL.
The installation media the client could share was the original distribution: nine
spanned diskette images, straight from the era when software arrived in a cardboard
box. I installed it into a clean vDos sandbox on my side and had their exact error
on the screen the same evening — without any printer attached at all. That
mattered: the printer was innocent.
The actual fault, three layers down
The report module failed before it ever reached printing. The main executable is
built with Blinker 3.30, a DOS extender; when it launches the report engine it swaps
itself out of memory and execs the child process. That swap-run mechanism needs a
DPMI host — a memory-management service that real DOS setups of the era, and the
NTVDM layer in Windows XP, quietly provided.
vDos doesn't provide one. The swap fails silently, the report engine never starts,
and the application reports the only thing it can see: the output file its child
never produced. "Couldn't access temporary file" — technically true, maximally
misleading. It took a 49-byte stub program planted in place of the report engine to
prove the engine was never being called at all.
The fix was small — finding it was the job
Once the cause was pinned down, the remedy fit in a small kit the client installed
themselves from a two-step README: a memory-management host that loads before the
application, and a rendering layer that catches the application's print jobs and
turns each one into a PDF — from there, any modern printer. The 1990s printer
profiles inside the application stayed untouched; PCL is just a language, and it
got a translator.
Two days of that week went into the diagnosis — reproducing the environment,
instrumenting a binary with no source, ruling out the printer, the config and the
emulator one by one. The installation took the client about a minute. That ratio
is normal for this kind of work; it's also why the fix survives Windows updates
instead of being a lucky tweak.
No reinstall, no data conversion, no settings changed inside the application. The
client's verdict, verbatim: "This ran perfectly… probably under DOS 6.0."
The numbers
| Time from first email to confirmed fix | 8 days |
| Remote sessions / calls needed | 0 — email and screenshots only |
| Price | a few hundred dollars, fixed — half up front, no-fix-no-fee |
| Change to the client's data or workflow | none |
| Follow-up utilities since | 2 small ones, same by-email pattern |
A week later the client was entering policies again and running the system
side-by-side with the books through year end. The agency's thirty years of customer history
stayed exactly where it has always lived — in DBF tables a
free analyzer can read in your browser.
Why this is on a migration consultancy's site
Because containment is a legitimate outcome. The decision framework in
rewrite vs convert vs wrap has a branch
most vendors skip: when the system is sound, the business is small and the pain is
environmental, the right engineering is to fix the environment — and keep the
migration conversation for the moment it earns its cost. A repair costing a few
hundred dollars that buys years is a better first step than a $50,000 rewrite that
buys the same years with
more risk. When this client is ready for more — a modern front end, a second user,
the cloud — the path is mapped, and nothing done this week blocks it.
If you have a Clipper-era system that still earns its keep but fights its
environment, that's exactly the shape of problem our
Clipper / xBase service starts with —
assessment first, and sometimes the assessment honestly says: don't migrate yet.
Top comments (0)