You might be able to port a lot of your legacy code to
FreePascal,  their compiler is compatible with a very
wide variety of systems ( and the price is right, too )

http://www.freepascal.org/

I've encountered something similar when drawing fractals and other math-intensive graphics on my 1.8G laptop: the first few seconds everything is ok, and then suddenly the whole thing slows down. I discovered this to be the fault of Intel and their mobile/speedstep technologies: after a short while of user inactivity, the processor's speed is reduced so that less power is consumed.

It might also just be the inability of new Windows versions to provide decent DOS compatibility.

Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com
http://student.vub.ac.be/~bvingerh/
Don't worry what people think about you. They're too busy wondering what you think about them.

Hm, this reminds me a tiny bit of the old Turbo pascal problem with fast processors with the crt unit. (overcome by using a replacement crt unit, no further modification needed).
Depending on what key information you are collecting, I'd be inclined just quickly to try replacing the procedures/functions you're using with your own, which should use standard DOS and BIOS routines in a totally standard way, just to check it's not something weird about interactions of mouse and keyboard interrupts when they're being handled so fast.
Weird one. Good luck!

    This looks like the old bugaboo of Windows deciding the program isn't doing anything and taking away CPU power.  It sounds like now it isn't recognizing keyboard activity.

    1)  Turn the idle sensitivity as low as possible.

    2)  If that's not enough, make your program do something periodically.  For example, read the same small bit of a file every 5 seconds.

    I haven't hit this particular problem as showstopper (but my code does follow suggestion #2 due to prior encounters with it) but I utterly can not get file locking to work under Windows XP.  A Micro$oft guy at Comdex thought about it for a bit and agreed that it wasn't going to fly--he was one of the ones who broke it.

Thank you for all your replies.  The super-short term resolution for this is that it DOES work in fullscreen mode (you can use alt+enter within a dos window to do this).

Idle Sensitivity didn't seem to make a difference and i'm going to try to force a screen refresh or something a few times a second in the code next.

I have also tried quite a few other ideas.  The patching the NTVDM.exe idea at: http://clio.rice.edu/djgpp/W2K_workaround.htm
and installing the Long Filename TSR.  Tried them as they were some of the few "patches" to Dos on current machines, you never know what they can fix.

Does anyone have any information pointing towards the differences between fullscreen DOS and windowed DOS?  The fact that it does work in fullcreen is promising because it shows it can still work fine....under the right circumstances.  It's looking to be something to do with CPU speed and allocating resources for a windowed version of dos that causes the input buffer not to be read until you move the mouse.  Hopefully it is something small that can be tweaked to get this working.

The idea of running dos fullcreen didn't go over well with the users.  The characters are about a half inch high on their  monitors.

Thanks in advance.

When DOS programs run under Windoze, the processor is switched to virtual 8086 mode. If the mode is windowed, there are still lots of other things that need to be done (rendering graphics, polling input devices, ...) and the time slice the DOS program receives is rather small. In fullscreen mode, the time slices may be larger (no graphics rendering, polling mouse is done by DOS driver, ...) and I/O operations can be performed more directly (e.g. writing to screen doesn't have to be interpreted by anymore).

As for the character size: if you know your application will be run mostly with recent graphics' cards, you should consider to support VBE text modes (modes like 80x60, 132x43, 132x60 are some examples). There is also a VGA mode with 80x43 screen size. Specs for VBE modes can be found here: www.vesa.org.

Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com
http://student.vub.ac.be/~bvingerh/
Don't worry what people think about you. They're too busy wondering what you think about them.

     Since it works full-screen it certainly sounds like the falling-asleep problem.  Screen refreshes don't count against  this, it won't help.  Periodic disk accesses do seem to work for me, though.

Here is what I have found out.

After more tinkering we decided to install Borland Pascal 7.0 on that 2.4Ghz computer with NT4.0 SP6.

We couldn't even get past the first install window!  It wanted you to "push enter to continue" and we couldn't do that, even with mouse movement (I assume since it wasn't looking for mouse movement and didn't have a cursor).

That was using the Command.com dos window.  Using cmd.exe we got better results but that showed that it affects other programs as well, not just ours.

Further testing showed that using command.com in a window was extremely flakey with cmd.exe only "sort of" buggy.

So, we formatted that computer, Installed Windows XP, and everything works exacly how it always has!  Who would ever have thought that a newer version of Windows would actually have BETTER ms-dos support than an older one!

We are happy with this solution, as well as the customers as they have copies of Windows XP as well lying around.  

We haven't tested with win 95/98/ME/2000 but this problem could show up there as well, who knows.

Thanks for all your time, and I hope this helps others.

     Better?!  I can't get file locks to work in the dos box of XP, period.  A Micro$oft guy even admits he (he was part of the team that did it) broke them.


     The problem is that while the lock is set properly the program isn't considered the owner of the lock.  Thus you can't read what you just locked.