Member Avatar for normanallen

For many years I have been using Borland Turbo C++ (version 3) to run a vital (to me) application. It has worked quite happily on 98SE and all my variants of XP Home (SP1, SP2 and SP3). The last time it worked was 18 September, and now I find that neither the application nor the compiler will run.
The file ntvdm.exe is the 16-bit Virtual Machine, and I can see this starting, using Process Explorer, and then stopping almost immediately.
I can only assume that a "fix" installed since then has caused it to stop working. Can anyone shed some light on what M$ have been up to, and why?
I am in the process of converting the program to use Visual C++, but I would like to keep the old version running for as long as possible.
(There is no conversion utility between version 3 and any of the higher versions of Turbo C++ so it is just as easy(!) to convert to VC++ as it would be to use the latest Turbo C++ product)

  • 1 Contributor
  • 1 Reply
  • 316 Views
  • 3 Days Discussion Span
  • Latest Post Latest Post by normanallen

Dani AI

Generated

This thread documents a transient NTVDM/16‑bit failure while running legacy Turbo C++ code. ’s follow‑up suggests the problem cleared without a clear root cause; the guidance below focuses on reproducible diagnostics and low‑risk ways to keep a 16‑bit work environment usable if the failure recurs.

Start by capturing facts that survive a reboot: note any Application/System events in Event Viewer (faulting module name, exception code such as 0xC0000005), and collect a crash dump for ntvdm if possible (DrWatson or a small sysinternals/procdump capture). A clean‑boot isolation (msconfig) or Safe Mode test will show whether a third‑party driver/service or shell extension is colliding with the VDM subsystem. Run a system file check and disk check to rule out corruption:

sfc /scannow
chkdsk /f
eventvwr.msc   (inspect Application and System logs)

If a third‑party hook is implicated, Autoruns can reveal non‑Microsoft shell extensions and startup items that load into many processes. Uninstalling very recent Windows updates (use Restore Point first) or rolling back a suspect driver is the correct way to test whether an update caused the regression — but avoid blind uninstalling without a backup.

For practical continuity, keep a preserved legacy environment: a VM snapshot (VirtualBox/VMware/Virtual PC) running the same XP/98 image or DOSBox for pure DOS programs will isolate the 16‑bit app from host changes. Embedding a tiny 32‑bit “shim” (a resident helper process) to anchor the environment is a lightweight workaround if the VDM behaves differently when no parent process is present. Long term, porting to a modern toolchain (Visual C++) or packaging the app inside a dedicated VM gives the most predictable future compatibility, since modern 64‑bit Windows do not include NTVDM.

Member Avatar for normanallen

I received a reply from a private list that said that running notepad.exe from a cmd prompt opened a window for notepad. I tried this and it did, and when I tried my applications they worked both from the cmd line and from windows. So the problem has gone away, but I don't know why it happened in the first place.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.