It is commonly considered "good practice" to deallocate acquired resources (memory, file handles, GDI objects, ...) before exiting a program. On the other hand, much of this housekeeping is not really necessary because Windows will do it automatically when the application calls ExitProcess.

One of my programs creates various resources on startup (fonts and brushes, a context-menu, a backbuffer DC plus bitmap, etc.). At the moment, the program destroys them one by one before calling ExitProcess. I'd like to delete the whole block of housekeeping routines and simply call ExitProcess instead. Is that safe (theoretically, it should be), or are there "known issues" (for instance with GDI on Win9x)?

Thank you

Frank
Posted on 2004-11-15 10:38:29 by Frank
It is a bad ideaTM to do that.
Although windows is clever enough to clean up 99% of the time, there is still that 1%. To be honest you should know what you are using, and be able to clean it up better and faster than windows can.

One day MS may release a Windows version that doesn't do clean up (some embedded thing maybe), and then your code will break. It really is your job to clean up.

Mirno
Posted on 2004-11-15 11:12:58 by Mirno
Although windows is clever enough to clean up 99% of the time, there is still that 1%.


Can you give a specific example for the 1% that are not cleaned up automatically?
Posted on 2004-11-15 11:20:09 by Frank
No :lol:

But the time you discover a case, it'll take you days of real gritty debug to find.

Mirno
Posted on 2004-11-15 11:38:50 by Mirno
No :lol:


That's why I ask. If nobody points out a specific example, then I will consider Windows a "decent OS" and trust it with the cleanup.
Posted on 2004-11-15 12:01:31 by Frank
As I understood it, this ExitProcess garbage collecting is made solely for prophylactic reasons and it's not a routine that should be fully responsible for such task.
Posted on 2004-11-15 13:08:44 by arafel
Just thought of something. Try creating two threads one calling EndProcess and other making some sequential memory allocation and freeing. It will fail sometimes!
But if you were manually de-allocating memory, you can be pretty sure that there wont be any leakage.
Posted on 2004-11-15 13:18:59 by arafel
IMHO the real problem is not in memory allocs (they will always be cleaned when the process, and it's memory space, are freed). But kernel or GDI objects may not be. So may happen with other resources allocated by third party libraries of which you know nothing about.

Besides, if you're using some software like MemProof, you'll get rid of a lot of false alarms and focus on the really important leaks. :)
Posted on 2004-11-15 14:23:56 by QvasiModo
GDI objects must be cleared, and menus that aren't assigned to a window, too (at least on Windows 9x). Kernel objects don't need to be closed.
Posted on 2004-11-15 14:57:43 by Sephiroth3
Menus ... yes. That's a specific example as I had hoped not to find. From WIN32.hlp:
An application must destroy the unassigned menu by calling the DestroyMenu function. Otherwise, the menu continues to exist in memory even after the application closes.

Okay, I'll go with the conventional wisdom and keep releasing my resources manually.

Thank you

Frank
Posted on 2004-11-15 15:38:35 by Frank