All windows applications enter WinMain() when they start, and the last code to run is on the way out of WinMain(), right?

If that is so, how can a VB6 programmer put must-run-before-exit code into WinMain()?

I have an app that does not put up a form, but uses Sub Main() as the entry point. I am creating a timer using User32’s SetTimer() (with hWnd = 0, since there is no form to associate the timer with).

If the app crashes, I want to be sure to use KillTimer(). But I am not sure that I can always count on Sub Main() running error handling I build into it.

I cannot find what will happen if a timer is left running when an app dies, but I suspect it is not good...

Well Brian, thinking out loud, if the timer is still running but the app crash, it will crash the timer too, since they are in the same thread... Also how do you expect to execute something inside the app if it crash? another case would be if you can control the error, then you are sure that you would execute everything you need...

HTH

Gonzalo

================================================== =========
Read this if you want to know how to get a correct reply for your question:
http://www.catb.org/~esr/faqs/smart-questions.html
^^Took that from dparsons signature and he Took that from planoie's profile
================================================== =========
My programs achieved a new certification (can you say the same?):
WORKS ON MY MACHINE
http://www.codinghorror.com/blog/archives/000818.html
================================================== =========
I know that CVS was evil, and now i got the proof:
http://worsethanfailure.com/Articles...-Hate-You.aspx
================================================== =========

as soon as the Sub Main ends, so does your application (unless you have loaded forms), therefore you can put KillTimer before the End Sub of the Main method.

"There are two ways to write error-free programs. Only the third one works."
Unknown

  My thinking was that, though the app is crashing, and the appearance to the user is an immeditate end to any planned action, that still behind the scenes, WinMain() is used for the exit—that that was what Windows compelled to happen. (This ignores crashes like the processor's program pointer being arbitrarily changed, inadvertently overwriting the memory where WinMain() has been loaded, deleting the stack entries, or corrupting them, and catastrophes like that.)

So is it the case that every running EXE has its own thread, no exceptions? If one application starts another app, do they share a thread?

Nop, they don't share a thread, everyone has it own thread. But if the parent dies, the child will be left alone.. In that case, your time will live forever until someone kill it..

HTH

Gonzalo

================================================== =========
Read this if you want to know how to get a correct reply for your question:
http://www.catb.org/~esr/faqs/smart-questions.html
^^Took that from dparsons signature and he Took that from planoie's profile
================================================== =========
My programs achieved a new certification (can you say the same?):
WORKS ON MY MACHINE
http://www.codinghorror.com/blog/archives/000818.html
================================================== =========
I know that CVS was evil, and now i got the proof:
http://worsethanfailure.com/Articles...-Hate-You.aspx
================================================== =========

Just to clarify: It seems you were addressing the question of whether an app spawning another app would-or-could have them sharing a thread when you said, “If the parent dies, the child will be left alone.”

But calling an API that starts something like a timer seems to be a horse of a different stripe. Is it an absolute that any asynchronus “thing” (I’m deliberately casting a wide net here) that is initiated by an app fits this paradigm? Is that “thing” (irrespective of whatever it is) functioning like an app on another thread?

That seems to not be the case (just in guessing here), because something like SetTimer() has access to the running app (can call one of the launching app’s functions as a callback, for instance), and can be killed without much ado using KillTimer() from within the launching app.

And if the timer continues to run, how is its attempt to call the callback function handled by the OS?

In that case, if you call an API, you are in the same thread, since API are declared like "include" functions (like in C).. but I think we are far away of your original question now..

HTH

Gonzalo

================================================== =========
Read this if you want to know how to get a correct reply for your question:
http://www.catb.org/~esr/faqs/smart-questions.html
^^Took that from dparsons signature and he Took that from planoie's profile
================================================== =========
My programs achieved a new certification (can you say the same?):
WORKS ON MY MACHINE
http://www.codinghorror.com/blog/archives/000818.html
================================================== =========
I know that CVS was evil, and now i got the proof:
http://worsethanfailure.com/Articles...-Hate-You.aspx
================================================== =========

Well, maybe not.

If apps all have their own threads, and that thread is destroyed / dropped / assassinated / terminated / killed / slain / snuffed out / extinguished when the app crashes (should that happen to happen), then the API "object" will not be sitting there in perpetuity emitting messages, and attempting calls to non-existent routines. Is that right?

(The thing that makes me need to ask rather than already knowing is the issue of asynchronicity. An out of process server—VB6 terminology—would seem to be separate running app. Whether it shares the thread with the app that uses it is unclear to me. What happens to an OoPS when the calling app fails is also unclear to me. And how this all relates to an asynchronous API call is not clear to me either. And these are the sorts of issues that books and "Help" generally ignore...)

I remember that Dll that holds APIs are unloaded after a certain amount of time that are not being used. So they will die by itself. But the call is not async. unless it has something to proccess and then you call another function to see if it ends...

HTH

Gonzalo

================================================== =========
Read this if you want to know how to get a correct reply for your question:
http://www.catb.org/~esr/faqs/smart-questions.html
^^Took that from dparsons signature and he Took that from planoie's profile
================================================== =========
My programs achieved a new certification (can you say the same?):
WORKS ON MY MACHINE
http://www.codinghorror.com/blog/archives/000818.html
================================================== =========
I know that CVS was evil, and now i got the proof:
http://worsethanfailure.com/Articles...-Hate-You.aspx
================================================== =========

Well, you're right. Calling it asynch is not actually accurate. But you create a timer, which (apparently) causes a section of code to be installed in memory, and run on service interrupts. When on being serviced that isolated code reaches a certain status—in this case the countdown equaling zero—that isolated code triggers a callback function in the program you have used it in.

It has behavior like an asynch call in that setting it up does not cause the program using it to come to a halt, and wait...

So the question is how Windows views the nature of this section of API code that has been loaded. It [u]is</u> being used (sort of), in that it gets regularly serviced to see if the countdown has zeroed out. But if the app that installed it is gone, yet the API code is still in memory being serviced, what happens when it counts down to zero?

I suspect it doesn’t matter—that the mechanism it uses for the callback is the Windows Messaging system, and that it is posting messages into the cue that merely get ignored. If the API code [u]is</u> still running after the installing app is gone (gone for whatever reason), then a little bit of memory is used for no good reason, but not very much. I am still curious what goes on in the case of a catastrophic failure of the app that installed the API code, though. One thing that encourages me to believe it might matter, is that Microsoft included the KillTimer Sub in the library.