Yes, exactly, one will have to use WaitForMultipleObjects in order to be able to wait on both the timer and a quit/exitthread event (and possibly other objects as well, depending on design). If the update processing is a lengthy operation, it might be a good thing to check if the quit event has been set at a few checkpoints. This can be done using WaitForSingleObject with a zero timeout value: WaitForSingleObject(hQuitEvent, 0). If the event is set, the return value will be WAIT_OBJECT_0 (cancel update and exit thread), else it will be WAIT_TIMEOUT (continue the update process).

For really tiny wait intervals such as a few ms, there are no obvious advantages, and Sleep might in fact be a better solution than creating a kernel object. However, for longer intervals the thread would remain locked until the timeout value expires, which would cause the application to look as if it was hung (and you don't want to use the dangerous TerminateThread API, since it doesn't allow for object cleanup among other unwanted side effects). In this case, it's always better to implement a solution such as the one I suggested.

First, a service is a normal Windows 32 program, and as such it has at least a system message queue (even if it doesn't use it). Each thread may also have a thread specific message queue, but the creation is deferred until it's really needed (e.g., a User or GDI function is called). The old SetTimer function makes use of window messages (it was normally used for background processing purposes back in the 16-bit days), even if you specify a callback. Because of this reason, one must get and dispatch messages when it's used. Basically, all you need to do is to implement a Get-or-Peek/DispatchMessage-loop somewhere in your ServiceMain (or a function called from it). This is what makes the wheel go round. MFC and other framework libraries have a message loop buried way down in their private code, so you don't see it often these days, but it's still integral to Windows. However, if the only WM-based function you're going to be using is SetTimer, there is a better solution: Waitable Timers. A waitable timer is a kernel object that can be waited on using the WaitForXObject(s) set of functions (cf. CreateWaitableTimer API), and it can be set to an absolute or relative due time. This way you can combine it with waiting on other events such as a Quit event, which is a good service design.

You can remove WM_TIMER messages like this at the end of your data polling function: // Look for WM_TIMER messages MSG msg; while ( ::PeekMessage(&msg, NULL, WM_TIMER, WM_TIMER, PM_NOREMOVE) ) {    // m_nTimerID contains holds the ID of your timer... if you're using    // more than one timer, this removal procedure won't be fool proof.    if ( msg.wParam == (UINT)m_nTimerID )    {       // Remove the message       ::PeekMessage(&msg, NULL, WM_TIMER, WM_TIMER, PM_REMOVE);    }    else break; }; However, I wouldn't implement it like this, but instead create a worker thread that uses a Waitable Timer object (cf. CreateWaitableTimer in the Platform SDK). This way you needn't worry about removing messages from the queue, and you can change the worker thread's priority if you like. You will need to synchronize access to the variables you will be updating, but it isn't that hard. HANDLE hWait = ::CreateWaitableTimer(...); for ( ;; ) {    ::SetWaitableTimer(...);    // You might want to use a "Quit" event object as well, created and signaled from the main thread, so you know when to exit the thread. If that's the case, use WaitForMultipleObjects instead.    DWORD dwWaitRet = ::WaitForSingleObject(hWait,...);    switch (dwWaitRet)    {       // cases...    } } CloseHandle(hWait);

1. Nothing could happen, besides that the update would occur less frequently. However, I believe 10 ms is too frequent if the update is made only for updating a GUI. It could probably be 250 ms (a quarter of a second), or even higher. 2/3/4) Using a WM_TIMER message to pull information is an old fashion, "16-bit" type solution, which, as you've noticed, usually affects performance. While it is possible to discard intermediate messages that have arrived during processing of another (by using the message filtering parameters of PeekMessage to remove such messages), it would be better to implement a push design in the DLL. If you have the DLL's source code, you could change it to signal a kernel object (such as an event) as soon as new information is available. The event would typically be created by the consumer application, and be supplied to the DLL through some initialization function. The application would then wait on this object to become signaled, either in a separate worker thread (the better choice since it wouldn't lock up the GUI during update processing), or in its main thread by using MsgWaitForMultipleObjects (in order to allow for window message processing). When signaled, the application should do whatever needs to be done for retrieving data from the DLL and updating the user interface, then return and wait for another update to occur. This way, the update thread will only be active when new data is available (which could be after 5 ms or 15 minutes). If you need to limit the update interval (i.e., data is sometimes available more often than you'd like to update the GUI), you could create a WaitableTimer object with say a 50 ms interval, and let the thread wait for both the update event and the timer object to become signaled (WaitForMultipleObjects with bWaitAll = TRUE). This way the update cannot begin until the wait interval has expired even if data is available. Good luck!

Yes, you can. Internet Explorer has a rich set of COM-interfaces, so you can do almost anything you want. You can get the documentation (samples included) by downloading the Internet Development SDK from Microsoft, or by browing it online using the MSDN Library (URL for both the SDK and the Library: http://msdn.microsoft.com).

When creating an active document container application, is it possible to display an active document server's menu icons? The default MFC implementation does not do this, so I'm wondering if it would be possible to (re)implement some OLE interface to achieve this. Any hints would be greatly appreciated!