alarm() on PC/MSoft (long)

[John D. Gwinner]

Michael:

Note: there's a solution here, but first some background:

.... 
> > Is there a message pump in the app?  SetTimer, even
> with a processor
> > callback, won't work without a message loop, I
> believe.
> 
> I'll verify it at the moment I finish this reply but
> I clearly read from MS Developers Network CDs that it
> is one of the two. Either a message loop in which the 
> application gets WM_TIMER message OR a function call
> back. If this does not work I don't know what to do.
> Some people claim that kaffe works fine under cygnus
> build. I hope they tried more then HelloWorldApp. This
> does not need any threads.

As I mentioned, it was an MSJ article: check out Volume 12, number 3,
"Under the Hood" by Matt Pietrek.  It's on the October MSDN, if you've got
that handy.

QUOTE:

With this quick review out of the way, consider a question I’ve heard
several times recently: "I’ve called SetTimer in a program that doesn’t
have any windows. Therefore, I set the timer to call a function, rather
than post a message to a window. However, my timer callback (see Figure 1)
is never called."

.... Fig 1 snipped

My immediate response is to ask if their program has a DispatchMessage
loop. They’ll reply that they shouldn’t need one. After all, they told
SetTimer to call their TIMERPROC rather than post a message. The problem
is that calling DispatchMessage isn’t optional if you’re using timers. As
you’ll see later, DispatchMessage is needed for both varieties of timer
notifications (that is, window messages and callback functions).

.....

In reading the Remarks section of the 32-bit SetTimer documentation,
you’ll come across this: "When you specify a TimerProc callback function,
the DispatchMessage function simply calls the callback function instead of
the window procedure. Therefore, you need to dispatch messages in the
calling thread, even when you use TimerProc instead of processing
WM_TIMER."

UNQUOTE.

Doing a Windows application without a message loop isn't the best way to
go -- the Win OS's pretty much live by messages, even if they aren't
posting to a Window.

However, check out the multimedia timers; such as timeSetEvent.  Even
though you aren't playing MIDI, the mm timers are good and fairly
accurate; better than SetTimer in any event.

Also, timeSetEvent doesn't require a DispatchMessage loop!  A console app
will run and link fine to winmm.dll.  It will NOT run if you 'exit to DOS'
from Win95, however.

Regarding using threads instead of a timer tick: I think it would be a
good way to go, although the winmm timer functions will probably work. 
Threads on Windows are much lighter weight than threads on Unix; they have
little overhead and live inside the address space of the owning process. 
I've been told that 'lightweight threads' on Unix are pretty much the same
thing as a Win32 thread, but I don't know.

		== John ==

P.S.  Just as a general observation, doing "a little bit" of Windows
programming and avoiding messages is like taking a shower with your
clothes on -- you're missing the full effect.  I know a lot of game
programmers that get themselves into trouble by creating loop driven code
without a message pump.  I'm not saying Kaffe or you have this problem,
it's a general observation.