Timers under Win95 vs. 3.1

Timers under Win95 vs. 3.1

Post by Steve Cohe » Wed, 29 Oct 1997 04:00:00



Sorry to broadcast this so widely, but there is a problem I cannot solve
and I need all the help I can, wherever I find it.

Our company has produced a 16-bit Windows application for a client.
This program communicates using 16-bit OLE and callback functions with
another 16-bit application running out-of-proc.  The second program is
responsible for communications with an external device via the serial
port as well as other forms of connection, but for the purposes of this
question, let us assume the comms are serial.

As the user scrolls in our program, different data must be exchanged
with the external device so that what is showing on screen can be
monitored.  It developed that the processing done by the second
application was intensive enough that overloads would occur that crashed
the program while scrolling so we reprogrammed it so that no
communication with the second application and the external device takes
place until the user has stopped scrolling (determined by trapping
WM_KEYUP and WM_VSCROLL).  This worked well, until we noticed that users
could cause the same problem by rapid-fire pressing of the navigation
keys (as opposed to leaning on them).  So we introduced another wrinkle
- a one second wait after scrolling stopped (using WM_TIMER).  Only
after this one-second delay would communications with the other program
and external device be reinitiated.

This ugly kludge solved our problems, or so it seemed.  Then we got
reports of occasional crashes when the program was run under Win95 and
less frequently, NT 4.0.  Under Windows 3.1, everything continued to
work.  Without a reasonable means of debugging this application under
Win95 (neither Codeview, the VC 1.5 IDE debuggeer could handle it and
our program was too big to have its symobl table loaded under Softice
for Win95) we are left to try solutions on whims.  Eventually, it
developed that a bug fix in the second program had made our kludge with
WM_TIMER unnecessary and it was removed, solving the immediate problem.

But our client and our client's client want to understand what happened
and I don't know enough about Windows internals to tell them anything
useful.  So I am asking the resources on UseNet.
The basic scenario, I believe, is this:
Our program handles a WM_TIMER message (through the message loop, not a
TIMERPROC)
and within that handler launches a call to the second process that will
result in callbacks.
This works under Windows 3.1 but not under Windows95.  So the question
is, is there a basic difference in the handling of WM_TIMER messages by
the kernels of these two operating systems that would cause this
difference in behavior.

Thanks in advance for any light you can shed.

--
Steve Cohen
RDI Software Technologies

remove the ** spam remover from in front of my email address to reply.

 
 
 

Timers under Win95 vs. 3.1

Post by Stan Feath » Wed, 29 Oct 1997 04:00:00



Quote:

>...
>... program handles ... WM_TIMER message ...
>... <which> launches a call to ...second process that will
>result in callbacks....

>...works under Windows 3.1 but not under Windows95.
> ... is there a ...difference in the handling
> of WM_TIMER messages by... these ...operating systems...

One possibility is due to the fact that win32 (9x/nt) is preemptive and win16
is not.  

If your wm_timer handler takes too long in win32 it's could get interrupted,
restarted, and even be subject to recursion.    

In win31 everything will wait for it to finish unless the handler had special
code to yield.

sf

----------------------------------------------------------------------------
This response does not represent the official position of, or
statement by, the Hewlett-Packard Company.  The above data is
provided for informational purposes only. It is supplied
without warranty of any kind.

 
 
 

1. Timers under Win95 vs Win 3.1

Sorry to broadcast this so widely, but there is a problem I cannot solve
and I need all the help I can, wherever I find it.

Our company has produced a 16-bit Windows application for a client.
This program communicates using 16-bit OLE and callback functions with
another 16-bit application running out-of-proc.  The second program is
responsible for communications with an external device via the serial
port as well as other forms of connection, but for the purposes of this
question, let us assume the comms are serial.

As the user scrolls in our program, different data must be exchanged
with the external device so that what is showing on screen can be
monitored.  It developed that the processing done by the second
application was intensive enough that overloads would occur that crashed
the program while scrolling so we reprogrammed it so that no
communication with the second application and the external device takes
place until the user has stopped scrolling (determined by trapping
WM_KEYUP and WM_VSCROLL).  This worked well, until we noticed that users
could cause the same problem by rapid-fire pressing of the navigation
keys (as opposed to leaning on them).  So we introduced another wrinkle
- a one second wait after scrolling stopped (using WM_TIMER).  Only
after this one-second delay would communications with the other program
and external device be reinitiated.

This ugly kludge solved our problems, or so it seemed.  Then we got
reports of occasional crashes when the program was run under Win95 and
less frequently, NT 4.0.  Under Windows 3.1, everything continued to
work.  Without a reasonable means of debugging this application under
Win95 (neither Codeview, the VC 1.5 IDE debuggeer could handle it and
our program was too big to have its symobl table loaded under Softice
for Win95) we are left to try solutions on whims.  Eventually, it
developed that a bug fix in the second program had made our kludge with
WM_TIMER unnecessary and it was removed, solving the immediate problem.

But our client and our client's client want to understand what happened
and I don't know enough about Windows internals to tell them anything
useful.  So I am asking the resources on UseNet.
The basic scenario, I believe, is this:
Our program handles a WM_TIMER message (through the message loop, not a
TIMERPROC)
and within that handler launches a call to the second process that will
result in callbacks.
This works under Windows 3.1 but not under Windows95.  So the question
is, is there a basic difference in the handling of WM_TIMER messages by
the kernels of these two operating systems that would cause this
difference in behavior.

Thanks in advance for any light you can shed.
--
Steve Cohen
RDI Software Technologies

remove the ** spam remover from in front of my email address to reply.

2. Ohh My God Wheres my kit

3. WM_NCHITTEST 16bit app in Win95 vs 3.1

4. PIE / internet explorer lookalike

5. GetFocus() in Win95 vs. 3.1

6. IEnumeratable

7. S.O.S. - Windows 3.1 MultiMedia Timer

8. ??Monitor or HD????

9. Timers and Win 3.1 ... !

10. Q: Better Timer Resolution Under Windows 3.1 ????

11. Using the Windows 3.1 Timer

12. Win 3.1 look under Win95

13. Win95,NT,3.1 Search(grep) & Replace utility