Case study: the 1997 insurance system that stopped printing on Windows 11

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.