DOS program has 8 second delay on startup under Win 7

Question

My legacy DOS program (instant-Office) endures an 8 second delay when starting under Windows 7 - every time.

Having run the identical program thousands of times under DOS and Win-XP it starts up instantly; literally sub-second.

The drives are nearly empty, CPU load is under 5 percent, tons of memory available. Standalone air-gapped computer; there is no network. No viruses.

CMD.exe starts up instantly.

I timed the delay after the window opens with the PIF showing at the top.

The problem is not the PIF, as I can go to the directory (running under CMD) and the raw .exe has the same 8 sec. delay.

I realize it is running under an emulator (virtual machine) but 8 seconds ?!?

This seems like a gratuitously enforced delay (to get us off DOS programs?).

Any ideas what is causing this ?

Any ideas on how to diagnose this ?

Any ideas on how to jump around this artificial delay ?

Thank you.

PS This question box here won't let me Tag this question with "DOS." But that's a different silly problem.

Answer 1

I had the same issue and found recently the solution on this site (intelvidfix.zip‎). It works perfectly for me.

---

Short version:

A patch that fixes a glitch in the BIOS of some Intel VGA onboard graphics adapters (i.e. 4010U, 4340 i3 and 4200U i5, 4600...) that cause NTVDM startup to be delayed for 5-10 seconds and also causes slow text output and other INT10h operations (1char / second) in fullscreen mode.

Long version:

Whom to blame for this mess. Intel or Microsoft?

Interestingly, they are both to blame in a certain way, but a problem with NTVDM suprisingly is even benifical for solving the Intel video BIOS bug. Sounds a bit confusing? You can read more in the technical details below. Microsoft's fault is to not implement IN/OUT on 32bit Ports in NTVDM. But even if that had been implemented, Intel's BIOS wouldn't work properly, it would even cause more problems. Intel on the other hand expects MMIO ports to be accessinble which isn't the cause in a V86 environment like the NTVDM. Therefore it runs in a 1 second timeout on every operation, even though it seems to work fine without using these MMIO-Ports. So their fault is to try MMIO access for 1 second each time instead of just skipping over it if it fails for unknown reasons. The problem in fact can be solved by jumping over the check routine, which is just 1 byte to patch in the Video BIOS. Fortunately the NTVDM mapping of the BIOS address space can be patched in memory via a NTVDM extension DLL, so that you don't need to reflash your VGA BIOS.

Answer 2

Robert, where you suggestion actually does make some sense is the problem started to appear with the LGA 1155 chipsets. It was quite obvious.

So yes, maybe it has something to do with the Intel GPU that's now embedded in the new generation processors. Why not...

However, we're not talking at all about full screen apps here, for the simple reason full screen mode has been purely and simply removed from Windows 7 !!!

So all DOS programs now have to run in windowed mode, period.

This means the slight (not even one second long, actually) lag that could occur when changing screen resolutions just doesn't exist anymore, because it's just impossible to occur.

Nope, we're talking about pure Windows display here.

Please give it a simple try. You'll find lots of DOS apps in your \Windows\System32 folder : just click on edit.com (for instance) and see by yourself. :)

Edit : I'm actually using expensive video cards, at least on my home PC.

It doesn't change anything to the phenomenon, and the lag has a fixed and perfectly predictive duration.

Now you're making me thinking about it, the processor speed does change something there : it's shorter on an i5 than on an old Pentium 4...

So there's probably some data treatment involved somewhere, most probably when running NTVDM.

Another feature you can easily check by yourself is the lag happens only once.

I'm explaining :

• Launch the shell : no lag at all
• Run any DOS program : lag
• Exit the program and run it again (or any other) : no lag at all.

This means it's absolutely not related to the display, but to invoking NTVDM for the first time (and probably setting up a work environment).

The only difference with the new chipsets is where it was instant before, it suddenly took several seconds.

I'm actually rather wondering if it's not a deliberate attempt to push people out of using 16 bits apps, but it's quite complicated here, because it only happens with Windows 7 or later, and not with Vista, XP (if you can find the drivers, which can usually be done to the only exception of graphics and sometimes network drivers if they're Intel and not Realtek or other makes), and of course not with linux...

... So we can't really accuse Intel there, but rather the way Microsoft is using the hardware with NTVDM on mor recent versions of Windows (including 32 bits Windows 10, that features the same lag).

Answer 3

You're assuming wrong things. I'm surprised nobody just gave it a try to see by themselves.

Here is how it works, so maybe thing would be stated more precisely :

• It's obviously on a 32 bits Version. A 64 bits version just can't launch any 16 bits program anyway as NTVDM has been removed from all 64 bits Windows versions.

• There's absolutely no lag at all when using an emulator. It has nothing to do with the program itself, it's only an arbitrary and quite incomprehensible delay when launching it from Windows, or from the shell, or whatever.

• You can very easily check by yourslef, launching any Microsoft app provided with Windows itself, such as edit !

By the way, as soon as you launch any DOS program, you also lose your keyboard localization !

Just do this simple test :

• Launch the command prompt

• type edit -> damn 5 seconds (or so) lag, then the classical DOS text editor opens

• type anything -> your keyboard is now in US layout.

About that, adding lh kb16 in autoexec.nt solves the problem, except the AltGr key is disabled so you can't type any "\", "@", etc. You have to se ALT + ASCII code... Note that it worked correctly in Windows Vista (and wasn't needed in XP). From Windows 7, MS provided a faulty keyboard table and never fixed it.

Back to our concern :

• It has nothing to do with screen resolution, frequency or whatever, for a very simple reason : full screen mode doesn't exist anymore. You can definitely not launch any DOS program in full screen, period. They always have to be windowed. So obviously, nothing at all changes in the windows desktop display (this too is easy to check before writing !)

• However, the idea about Intel based graphics may be a serious hint.

As a matter of fact, it worked a breeze up to LGA 775 motherboards, and the lag first appeared with LGA 1055 chipsets. I could clearly see it (yes, my customers are using programs written in Clipper. Then what ? They do the job perfectly).

So is it connected to integrated video processing in the latest motherboards chipsets and intel processors ?

I can confirm it behaves exactly the same with any processor (from the weakest Celeron to the fastest i7), and that the lag is absent on any motherboard using an LGA 775 chipset or older, whatever the processor and with or without an add-on video card.

At least, these are the facts.

Now about the cure... I'm still investigating. :p

For now, the most satisfying solution I could find is the vDos emulator. Unlike DosBox, it correctly manages file sharing for multi-user applications (though in this case, it's not free). WMWare also works a breeze, though heavier to install (vDos needs almost no installation. It's actually much faster and easier to use than DosBox).

As I said above, launching a DOS program through vDos is immediate : no lag at all. Of course, it's mostly aimed at 64 bits Windows, but it does make using DOS program under 32 bits Windows more convenient, because it removes the damn lag to start with.

On the practical side, our multi users customers actually work through PuTTY connected in ssh to Linux servers running Dosemu. At least, we don't have any keyboard nor display issues in this setup (about display issues, Microsoft has been adding CHCP in Windows, while it made no sense at all, since all DOS progams have always been using the standard 437 code page. As a result, some semi-graphic characters display fancy exotic accented characters instead).

Of course, being able to launch DOS programs under native Windows without the weird lag would be more satisfying. This and the damn keyboard translation bug... It worked allright in Vista, so I'm wondering if the Vista files could be inserted in the latest Windows versions... I still have to identify them.

Answer 4

In general, dos support were gradually cut since XP (it does not run a small number of programs which worked in 98). That you were able to start them on Windows 7 is already a small miracle. With that in mind, it would not be a total surprise if even DOSBox could run those programs faster than the Windows native "emulation".

Answer 5

Actually Prusswan, DosBox runs these programs VERY slower.

When my customers are asking for a PC to run these programs as standalone, I install a 32 bits OS on them, that's all.

The only drawback is the localized keyboard driver (you have to add kb16 in autoexec.ini) that's messed up, as it disables the Alt Gr key, so the extended characters become unavailable (meaning no access to "@", "\", "#", etc. in French, for instance, so users have to hold the Alt key and type in their ASCII codes !)

Other than that, you get the fastest experience when running these programs under native Windows (you have to re-enable NTVDM in Windows 10, there's a setting for this).

vDos is a very good alternative, though.

I agree using XPMode was slowing down things a bit, but it was very gratifying too, and I sadly regret they removed it from Windows 10.

It was not only about DOS apps there, but also about 16 bits Windows apps in general. I've been using Graphic Works 4 for decades (I've bought the license, in case you're wondering) and I can't use it anymore at home because I stupidly installed Windows 7 in 64 bits to get the i7 + 16 GB RAM + 10 Gbps SSD full power, and I even more stupidly updated it to Windows 10... So no more simple technical sketching at home now. :(

Anyway, the best solution right now for DOS apps under 64 bits Windows (and 32 bits Windows if the lag really upsets you) is probably vDos.

However, the question remains open about the reason, and hopefully the cure, about this strange lag...

Answer 6

It is related to your video card. I'm betting you are using a Intel core processor with the integrated Intel HD Graphics 4400 processor.

The delay is not 8 seconds on every system. On some systems it is longer. I have a system that always has a 5 second delay.

Not every video card supports every video mode. For instance, some video cards do not support full screen DOS mode. That is, text 80 columns wide and 25 rows tall. Some video cards only support DOS programs in a windows.

From my experience, the Intel HD Graphics 4400 integrated processor always causes a multiple second delay launching 16 bit programs.

Maybe you can buy an inexpensive video card and put it in your computer and stop using the integrated VGA or DVI on the motherboard.

Maybe Intel can fix this in the driver for the integrated 4400 chip video.

Until then, you will experience the delay EVERY TIME you launch your 16 bit program. Even if you are in a "black" command prompt window already. You would think the driver has already entered the support mode for the DOS program. But you will experience the delay when you enter the name of the 16 bit program and hit enter.