X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
NNTP-Posting-Date:	Tue, 12 Dec 2006 21:50:59 -0600
From:	"Alexei A. Frounze" <alexfru AT chat DOT ru>
Newsgroups:	comp.os.msdos.djgpp
References:	<1165931131 DOT 768505 DOT 13330 AT 73g2000cwn DOT googlegroups DOT com> <t5udnW6gE8jud-PYnZ2dnUVZ_ujinZ2d AT comcast DOT com> <1165953093 DOT 635481 DOT 221520 AT 16g2000cwy DOT googlegroups DOT com>
Subject:	Re: delay() different bahavior under Win98 window/fullscreen in DJGPP 2.04
Date:	Tue, 12 Dec 2006 19:46:45 -0800
MIME-Version:	1.0
X-Priority:	3
X-MSMail-Priority:	Normal
X-Newsreader:	Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE:	Produced By Microsoft MimeOLE V6.00.2900.2962
Message-ID:	<AKydnWmn0cs-5eLYnZ2dnUVZ_obinZ2d@comcast.com>
Lines:	48
NNTP-Posting-Host:	24.18.54.185
X-Trace:	sv3-wqSwFNz6Wcs5Q/SOHg/m44a8QhtZu2d2CrwKNvRI3iHmXEItJlLrxrrIYzUgY3F/FkMhxbRRdR4QaaI!PjgQCT+PZcxJCMpJ0NCIu/9MxyKTkBS9cIf4RRnXQiGG7LBL9AF1ZnKkzTmwk0njxjAgVlpIqgui!SumRUtjQcq4=
X-Complaints-To:	abuse AT comcast DOT net
X-DMCA-Complaints-To:	dmca AT comcast DOT net
X-Abuse-and-DMCA-Info:	Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info:	Otherwise we will be unable to process your complaint properly
X-Postfilter:	1.3.32
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

Glaux wrote:
>> What if you press and hold, say, Ctrl during delay()? Will tha make
>> delay() finish up faster?
>
> Yes, what this means?
>
> I tried:
>
>  for(i=0;i<100;i++) // it's OK, exec time 5 seconds
>    delay(50);
>
>  for(i=0;i<1000;i++) // this takes about 50 seconds, when holding CTRL
> it drops to ~30s
>    delay(5);
>
> It seems like delay timer uses 55ms granularity instead 1ms like
> before...

The thing is that if your DOS application does things like:
- polling keyboard
- yielding time slice (yes, there's a function for that too)
- polling time
- and probably doing lots of disk I/O (I'm not sure if this is the real 
cause or there's something else happening along disk I/O)
then the NT-based Windows will decide that your DOS application isn't doing 
anything useful, just waiting for something to happen (e.g. keyboard input, 
certain time, etc) and gives very small share of the available CPU time to 
it. There may be other conditions when this happens.

I had to fix a couple of "induced" bugs in my DOS applications because of 
this. One app was an i8051 emulator which was checking if a key is pressed 
after execution of every instruction. The idea was to stop execution if a 
key was pressed. What happened is that Windows decided that the app is doing 
too much of keyboard checks doing nothing good inbetween and slowed it down 
below any reasonable level. Since this happens not immediately, on short 
8051 pieces of code you'd never see this problem because there would be not 
enough keyboard checks. But on larger 8051 pieces of code, there would be 
too many checks before the code finishes. My fix was to remove the old 
checks (calls to BIOS/DOS to see if a key is pressed) and hook up to the 
keyboard IRQ and get this info the other way.

The moral is simple -- DOS apps and Windows don't trust each other and can't 
rely on each other for different reasons but with the same outcome -- the 
DOS apps may and will fail to work under Windows. And this more so, since 
DOS support is being quickly removed from Windows...

Alex

- Raw text -