Need help with my first masm program

[jj2007]

Nidud,

If you have some wisdom to add, don't hesitate - seriously.

The one bit that I miss in the picture is which objects are so global that ExitProcess can not free them. Global atoms, for example. But all the rest? Address space gone, object gone...

[Greenhorn]

You have to complete your WM_DESTROY. At the moment there is a GDI leak if do not free allocated resources.

Raymond Chen doesn't agree with you. To test it, write a little proggie that spawns another little proggie 10,000 times. If your system crashes, you are right. If not, Chen is right.

Sorry, but I don't get the point here.

The Bounce application is not a DLL. Raymond Chen is talking about what may to do or not to do if your DLL gets detached when the process exits. He is not talking about the WM_DESTROY! And it applies to calling procedures in other (private) DLLs, not system DLLs.

GDI objects are systemwide resources and they are limited.
However, always free your allocated resources if you don't need them anymore unless the documentation states something else!

Kind regards
Greenhorn

[hutch--]

I confess to being "Olde Schoole" when it comes to allocating and freeing memory. Its the law of gravity, what goes up must come down. It used to make me laugh when people went looking for memory leak detectors when what they needed was to keep track of what they allocated. In whatever scope, allocate memory and set where it is freed.

In Win3.0/1? you forgot at your peril, when you botched memory, the OS would KRASCHE. If you were truly "lucky" it would wreck something in the OS and it would not boot again so you learnt the other aspect of Windows, re-install Windows. 

Now something that is still with us is the "Black screen of death", means you have made an even bigger PHUKUP that a "Blue Screen of Death". 

[jj2007]

GDI objects are systemwide resources and they are limited.

Any evidence for that? A link to MSDN or Microsoft docs maybe?

[hutch--]

I have moved this thread to the *Laboratory as the Campus is for new members to ask questions without being hassled, used as recruiting fodder or their topics being taken over for technical arguments. This topic was moved instead of being locked or deleted but to protect new members, I am bound to delete any unwanted content.

*correction : lousy aim when moving the thread. 

[HSE]

Any evidence for that? A link to MSDN or Microsoft docs maybe?

I think you will see the problem when Windows don't have enough disk free room to simulate memory. Anyway, I presume programs become slow when disk is used for memory, then I destroy not used things.

[jj2007]

I have moved this thread to the Workshop

To the lab, but anyway: wise decision

This is not a trivial issue. For example, Chen writes explicitly

Don't worry about freeing memory; it will all go away when the process address space is destroyed. Don't worry about closing handles; handles are closed automatically when the process handle table is destroyed.

Further down, 50. jas71@hotmail.com says on January 7, 2012 at 4:42 pm

"Freeing memory and closing file handles isn't going to peg your cpu so long you notice or care. Something else is probablt going on with your favorite prgram"

It will if it's a long-running app with either a memory leak or a long history implemented by something like a linked list. If it's, say, Raymond's web browser/music player/text editor, keeping a 4 kb block of current state with a pointer to the previous state etc back to the start, you could easily end up with lots and lots of disk thrashing. Each of those blocks will have been paged out – potentially at different times, hence to different bits of the pagefile – at which point every single block will involve a disk seek. That 1 Gb undo/history buffer which seemed so reasonable at the time just became the cause of a quarter-million disk seeks, tying up a typical drive for 20 minutes in the worst case!

[daydreamer]

I am interested in the scenario of multiple threads use
Getdc
...gdi drawing code here
Release dc
Has bigger chance of memory leaks?
Needs invoke waitformultiplethreads in Wm_destroy before delete all gdi resources maybe?otherwise some thread still running can create gdi things and mess up delete all inside Wm_destroy?
Or suspendthread?

[Greenhorn]

GDI objects are systemwide resources and they are limited.

Any evidence for that? A link to MSDN or Microsoft docs maybe?

You're right, they are private - but limited.
GDI Objects

However, I personally would not rely on the OS to do all the cleanup for me and in my opinion it is bad programming style not to implement such a simple task like a proper cleanup on exit.

Kind regards
Greenhorn

[jj2007]

GDI Objects

The destroyer functions remove the object from memory

Raymond Chen: All this anal-rententive memory management is pointless. The process is exiting. All that memory will be freed when the address space is destroyed. Stop wasting time and just exit already

in my opinion it is bad programming style not to implement such a simple task like a proper cleanup on exit.

Read the last sentence of my post above. Even better, the whole article by Raymond Chen.

[TouEnMasm]

All this anal-rententive memory management is pointless.

translate in french give

Toute cette gestion de la mémoire annale-rententive est inutile.

?! 

[hutch--]

 

Learn bad habits, end up with bad results. Yes you can exit an app and the OS will clean up the mess for you but apply bad habits to long running dynamic code and you can lock it up. Sloppy programming ends up with people who have botched it and retire, never to be heard from again.

The law of gravity is eternal, what goes up, must come down, what you allocate you should free. Do it everywhere and it works for you.

[nidud]

deleted

[jj2007]

As pointed out your quote(s) from Raymond Chen is taken completely out of context and only refer to a specific condition in DllMain.

What Chen writes applies obviously also to executables.

Local memory (the heap) is created by extending the size of the application image (the process) in memory, so when the application exits all locally allocated memory (LocalAlloc/HeapAlloc) to the process is gone. System-wide allocations however is not (Sys/GlobalAlloc).

Oh well... I had hoped that Chen's All that memory will be freed when the address space is destroyed was clear enough. Fortunately, that is easy to test, see attachment - pure Masm32 SDK. It launches 10,000 times an executable that forgets to free 200,000,000 GlobalAlloc'ed bytes. You can stop the process by pressing the Shift key; if it takes too long for your taste, use Sleep, 1 and rebuild it.

The usual disclaimers apply - close all open docs and use at your own risk.

[Biterider]

Hi

https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-globalalloc

Remarks
Windows memory management does not provide a separate local heap and global heap. Therefore, the GlobalAlloc and LocalAlloc functions are essentially the same.

https://docs.microsoft.com/en-us/windows/win32/memory/global-and-local-functions

The global and local functions are supported for porting from 16-bit code, or for maintaining source code compatibility with 16-bit Windows. Starting with 32-bit Windows, the global and local functions are implemented as wrapper functions that call the corresponding heap functions using a handle to the process's default heap. Therefore, the global and local functions have greater overhead than other memory management functions.

Biterider