Hello,
I have been trying to recode the Bounce1 program written in C to masm assembler from the Petzold book Programming Windows, chapter 14. I have ran into a few problems and am asking for help. The video explains more Thanks.
Chad Botting
coffeeprog
https://youtu.be/H6QoM--RD7s
https://forums.grc.com/threads/c-and-assembly-symbols-and-debugging-question-and-a-discussion.760/
Hello,
Welcome on the forum.With source code all is possible.
Sub Eax, Ebx ;
mov edx,eax ;<<<<<<<<<<<<<<<<<<<<< don't use eax in a call
Invoke BitBlt, hdc, Ecx, Edx, cxTotal, cyTotal, hdcMem,0, 0, SRCCOPY
The compiler need a very number of registers to solve the call,eax is the one you coulndn't use without random problems.That is perhaps it work,perhaps not.
Ok, thanks, that did not solve the problem, but I did not know not to use eax in a call
Hi Chad Botting,
you cannot do this (actually and technically you can but then you must know what you're doing):
Mov DWord Ptr [cyClient], Ecx
Mov Eax, DWord Ptr [cyClient]
By doing Mov DWord Ptr [cyClient], Ecx you will overwrite the variable xCenter with the high word of ecx.
And with Mov Eax, DWord Ptr [cyClient] you will load cyClient into ax and xCenter into the high word of eax.
In the Petzold source the size of the static variables are int = DWORD and not WORD.
Download and read the MASM Programmer's Guide and you'll understand what's wrong with your code.
http://masm32.com/board/index.php?topic=3445.0 (http://masm32.com/board/index.php?topic=3445.0)
Kind Regards
Greenhorn
Here is what you can do with a c source code using option /FAs,you get an asm file who can help you.
There is errors of size using the register dword ptr [XXX] .. who must be corrected.
Ok, good information, the link the Programmer's Guide is dead, but you can just search for the filename of the pdf. I actually bought a copy on ebay, so I have a physical copy too.
Attached your code but it is not testet !
Try this link https://idoc.pub/download/masm-611-programmers-guide-5143gd0jejnj (https://idoc.pub/download/masm-611-programmers-guide-5143gd0jejnj)
OK, had a closer look at it ...
Attached code should work fine, but it's not tested ...
You have to complete your WM_DESTROY. At the moment there is a GDI leak if do not free allocated resources.
.ElseIf uMsg == WM_DESTROY
; Clean up
.If (hBitmap)
Invoke DeleteObject, hBitmap
.EndIf
invoke KillTimer, hWnd, ID_TIMER
Invoke PostQuitMessage, 0
Xor Eax, Eax
Sorry, forgot to adjust the protos ...
MinNum PROTO :DWord, :DWord
MaxNum PROTO :DWord, :DWord
Thank for your help, I think I am done for today. I am including the newest code in a zip file and another video for additional help. Super thanks.
Chad
https://www.youtube.com/watch?v=8Q9Cl3Eq2SU
This one work exactly as the original except he is green to be original.
I made a quick video for the sake of completion. This is the fully working Bounce1 in masm, little messy still, but works.
https://www.youtube.com/watch?v=RYZL7te3sdM
Quote from: Greenhorn on July 29, 2021, 05:28:14 AM
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 (http://masm32.com/board/index.php?topic=6053.0). 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.
deleted
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...
Quote from: jj2007 on August 04, 2021, 08:20:46 PM
Quote from: Greenhorn on July 29, 2021, 05:28:14 AM
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 (http://masm32.com/board/index.php?topic=6053.0). 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
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. :tongue:
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". :biggrin:
Quote from: Greenhorn on August 05, 2021, 07:08:37 AMGDI objects are systemwide resources and they are limited.
Any evidence for that? A link to MSDN or Microsoft docs maybe?
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. :tongue:
Quote from: jj2007 on August 07, 2021, 05:57:18 AM
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.
Quote from: hutch-- on August 07, 2021, 08:00:39 AM
I have moved this thread to the Workshop
To the lab, but anyway: wise decision :thumbsup:
This is
not a trivial issue. For example, Chen writes explicitly (http://bytepointer.com/resources/old_new_thing/20120105_006_when_dll_process_detach_tells_you_that_the_process_is_exiting_your_best_bet_is_j.htm)
QuoteDon'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
Quote"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!
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?
Quote from: jj2007 on August 07, 2021, 05:57:18 AM
Quote from: Greenhorn on August 05, 2021, 07:08:37 AMGDI 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 (https://docs.microsoft.com/en-us/windows/win32/sysinfo/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
Quote from: Greenhorn on August 08, 2021, 05:31:09 AMGDI Objects (https://docs.microsoft.com/en-us/windows/win32/sysinfo/gdi-objects)
QuoteThe 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
Quote from: Greenhorn on August 08, 2021, 05:31:09 AMin 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.
Quote
All this anal-rententive memory management is pointless.
translate in french give
Quote
Toute cette gestion de la mémoire annale-rententive est inutile.
?! :mrgreen:
:biggrin:
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.
deleted
Quote from: nidud on August 09, 2021, 01:45:00 AMAs 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.
QuoteLocal 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.
Hi
https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-globalalloc (https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-globalalloc)
QuoteRemarks
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 (https://docs.microsoft.com/en-us/windows/win32/memory/global-and-local-functions)
QuoteThe 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
Quote from: Biterider on August 09, 2021, 07:56:47 PMthe GlobalAlloc and LocalAlloc functions are essentially the same.
Thanks, Biterider. In the meantime, I made an interesting discovery: Nidud was partially right.
Two posts above I attached two proggies: The first one GlobalAlloc's 200MB and exits without freeing them. The second one WinExec's the first 10,000 times. No problem, tested fine on Windows 7-64.
However, if you replace
GlobalAlloc with
SysAllocString as shown below, the behaviour changes dramatically. Test it only with maximum caution - I had to press the power button for five seconds to get out of the mess (and I had to do that three times...).
After only 20 iterations in the loop of the launcher posted above, the system
may freeze completely. I've put "may" in bold, because, ehm, it depends :cool:
include \masm32\include\masm32rt.inc
.code
start:
mov ecx, 200000000
push ecx
invoke GlobalAlloc, GMEM_FIXED, ecx
pop ecx
.While 1
dec ecx
.Break .if Sign?
mov byte ptr [eax+ecx], "x"
.Endw
push eax
invoke SysAllocString, eax
.if !eax
print str$(rv(GetTickCount)), "..."
print LastError$()
print chr$(13)
.endif
call GlobalFree
exit
end start
deleted