Memory-mangement dilemma

[NoCforMe]

I've come up against a gnarly problem in developing my (yet another) ASM editor (in other thread here). It has to do with memory management.

Specifically, how to handle getting selected text. I wanted to try out copying a selection the user had made in the edit window into one of my "cubbyholes". Seems simple enough, right? Well, not so much.

Since there's no such edit control message as EM_GET_SELECTED_TEXT, what a guy would have to do is this:

• First see if there's any selection at all using EM_GETSEL
• If there's a selection, get the entire edit control's text into a buffer, say with GetWindowText()
• Use the selection positions to extract the selected text

So what if we have tens of K of text? or hundreds of K? This means we have to have a buffer allocated that's big enough for that text. (Windows is helpful here by giving us the WM_GETTEXTLENGTH message and the GetWindowTextLength() function to tell us how much text (in characters) is in the control.)

Here's where we have to make some design decisions. The easy way to do this would be to allocate a buffer (I'd use HeapAlloc(), as that's what I'm familiar with) every time we want to do this operation, then de-allocate it. Easy, but wouldn't this be expensive? as well as potentially causing memory problems with all that allocating and deallocating?

Or we could initially allocate a buffer that we think might be big enough for most cases, then compare its size to the amount of text in the control. If it's not big enough, then enlarge it using HeapReAlloc(). My bet would be on this method, which forces us to do some bookkeeping, i.e. memory management. (Ugh.)

Of course this problem isn't limited to us assembly-language programmers: even in a very high-level language like C++, the programmer's going to be faced with some tough decisions in the memory department.

So what would y'all do here? The same problem applies to any operations on the edit control, like searching for text or loading and saving files, where we have to deal with the entire mass of text.

[zedd151]

I think you need code something like this (excerpt from other code)

Code Select Expand


           invoke SendMessage, hRich, EM_EXGETSEL, 0, ADDR Cr   ; <---- to get selection size
            mov eax, Cr.cpMin                                                         ;  Cr is CHARRANGE structure
            mov edx, Cr.cpMax
            sub edx, eax
            jz done                           ; if zero no text selected
           
            mov selsize, edx                                                            ; <---- selection size
           
            mov tmpsize, edx
            invoke GlobalAlloc, GPTR, selsize                                      ; allocate memory AL LEAST THAT SIZE
            mov tmpbuf, eax
            invoke GlobalAlloc, GPTR, tmpsize
            mov tmpbuf2, eax
            invoke SendMessage, hRich, EM_GETSELTEXT, 0, tmpbuf   ; <------- get selected text into memory buffer




Oh, this code is for richedit controls. Not sure if it works with plain Edit controls but you CAN try. They are Edit Messages after all. (EM_??????). but I've only ever used with Richedit controls.

[jj2007]

EM_GETSELTEXT doesn't work with edit controls, but this works:

Code Select Expand

push esi
  mov esi, rv(SendMessage, hMyEdit, EM_GETHANDLE, 0, 0)
  push rv(LocalLock, esi)
  ... extract the selected text here ...
invoke MessageBox, 0, eax, chr$("The full text:"), MB_OK
  call LocalUnlock
  pop esi

[zedd151]

Ok cool. I wasn't so sure about using for edit controls.

[NoCforMe]

Ah, EM_GETHANDLE. Never knew. Kewl! (Misleading name; when I saw it I assumed it returned a handle to the control itself.)

[jj2007]

Test case attached (pure Masm32 SDK code).

[zedd151]

EM_GETHANDLE:

The return value is a memory handle identifying the buffer that holds the content of the edit control. If an error occurs, such as sending the message to a single-line edit control, the return value is zero

Ah, who knew? I did'nt.   I thought it returned the control handle too.

[NoCforMe]

JJ: I just want to thank you again for giving me the perfect solution to the problem at hand. EM_GETHANDLE and LocalLock() did the trick. No need for any memory management on my part!

Moral of the story: it pays to ask. (At least if you're in the right place.)

[NoCforMe]

The saga continues.

I ran across another gotcha that I haven't seen documented anywhere, but figured out all by myself. My little editor can now load (and save) files. So I loaded a file, which happened to be the editor's source file. Fine and dandy. Looked great. Until I tried to edit it: I could move around in it, select text, but I couldn't type any text into it. WTF???

OK, to make a long story short, there's this thing called a "text limit", an upper limit to the amount of text an edit control can hold. The default seems to be 30,000; at least that's what I'm getting here on Win 7-64. But wait a minute: the file I loaded was even bigger than that, 53 Kb or so. So I was able to load a file over the limit, but unable to type any additional text into it. Weird.

The solution is to increase the text limit with EM_SETLIMITTEXT. Now I'm wondering what the convention is here: do you set the text limit to some extremely high number, like a bajillion characters? Or set it to the size of the file you're loading plus X for additional text? Is there a penalty for making the limit huge? (After all, the control has to allocate memory to store all that text.) What do people do here?

I've never seen Notepad not be able to load a huge file, so it must have some feedback going on as it works; maybe it can detect that it's hit the end of its buffer and just silently reallocates it. I don't see how to do this with a regular edit control; I guess you could look for EN_CHANGE notifications, which happen whenever the user types a character, and constantly check the amount of text in the control against the text limit and adjust it as needed ahead of time.

I just went ahead and set the limit to 100,000 for the meantime.

[jj2007]

JJ: I just want to thank you again for giving me the perfect solution to the problem at hand. EM_GETHANDLE and LocalLock() did the trick. No need for any memory management on my part!

Moral of the story: it pays to ask. (At least if you're in the right place.)

You are definitely in the right place

I wonder if there is still a difference between LocalLock/Unlock and GlobalLock/Unlock. This is old stuff.

[daydreamer]

Api Get file size + extra buffer= max typed chars in a day by fast secretary before load file choose by user?
Biggest file size change copy/paste big source file, api get clipboard size and reallocate + clip size?

[jj2007]

Api Get file size + extra buffer= max typed chars in a day by fast secretary before load file choose by user?
Biggest file size change copy/paste big source file, api get clipboard size and reallocate + clip size?

Please translate to English

[hutch--]

David,

You can play with the old format of GlobalAlloc() - GlobalLock() if you need the practice with old Win 3.0 junk but if you use GlobalAlloc() with the GMEM_FIXED flag, its return value casts directly to a pointer and you free it after use with GlobalFree(). You only use the old system with the clipboard.

[jj2007]

Hutch,

The point here is that EM_GETHANDLE does the alloc for you, so no setting of GMEM_FIXED allowed.

Re GlobalLock==LocalLock: The EM_GETHANDLE example works fine with both GlobalLock and LocalLock  (M$ docs is unclear as usual, but they recommend LocalLock). Under the hood:

Code Select Expand

CPU Disasm GlobalLock
Address   Hex dump          Command                                  Comments
75B5D0C7   $ /6A 10         push 10                                  ; VOIDPTR kernel32.GlobalLock(hMem)
75B5D0C9   . |68 50D1B575   push 75B5D150
75B5D0CE   . |E8 ED44FEFF   call 75B415C0--->
75B5D0D3   . |8B5D 08       mov ebx, [ebp+8]
75B5D0D6   . |F6C3 04       test bl, 04
75B5D0D9   . |0F84 7DEA0000 jz 75B6BB5C
75B5D0DF   . |FF35 6000C175 push dword ptr [75C10060]                ; /Arg1 = 260000
75B5D0E5   . |FF15 8003B475 call near [<&ntdll.RtlLockHeap>]         ; \ntdll.RtlLockHeap
75B5D0EB   . |8365 FC 00    and dword ptr [ebp-4], 00000000
75B5D0EF   . |C745 FC 01000 mov dword ptr [ebp-4], 1
75B5D0F6   . |8D73 FC       lea esi, [ebx-4]
75B5D0F9   . |56            push esi                                 ; /Arg2
75B5D0FA   . |FF35 5C00C175 push dword ptr [75C1005C]                ; |Arg1 = KERNELBASE.76A416C0
75B5D100   . |FF15 8403B475 call near [<&ntdll.RtlIsValidHandle>]    ; \ntdll.RtlIsValidHandle
--->
75B415C0   $  68 CB49BE75   push 75BE49CB
75B415C5   .  64:FF35 00000 push dword ptr fs:[0]
75B415CC   .  8B4424 10     mov eax, [esp+10]
75B415D0   .  896C24 10     mov [esp+10], ebp
75B415D4   .  8D6C24 10     lea ebp, [esp+10]
75B415D8   .  2BE0          sub esp, eax
75B415DA   .  53            push ebx
75B415DB   .  56            push esi
75B415DC   .  57            push edi
75B415DD   .  A1 AC03C175   mov eax, [75C103AC]
75B415E2   .  3145 FC       xor [ebp-4], eax
75B415E5   .  33C5          xor eax, ebp
75B415E7   .  50            push eax
75B415E8   .  8965 E8       mov [ebp-18], esp
75B415EB   .  FF75 F8       push dword ptr [ebp-8]
75B415EE   .  8B45 FC       mov eax, [ebp-4]
75B415F1   .  C745 FC FEFFF mov dword ptr [ebp-4], -2
75B415F8   .  8945 F8       mov [ebp-8], eax
75B415FB   .  8D45 F0       lea eax, [ebp-10]
75B415FE   .  64:A3 0000000 mov fs:[0], eax
75B41604   .  C3            retn

CPU Disasm LocalLock
Address   Hex dump          Command                                  Comments
76A15493   .  6A 10         push 10                                  ; KERNELBASE.LocalLock(guessed Arg1)
76A15495   .  68 488FA376   push 76A38F48
76A1549A   .  E8 491F0200   call 76A373E8  --->
76A1549F   .  33FF          xor edi, edi
76A154A1   .  897D E4       mov [ebp-1C], edi
76A154A4   .  8B5D 08       mov ebx, [ebp+8]
76A154A7   .  F6C3 04       test bl, 04
76A154AA   .  0F84 AC000000 jz 76A1555C
76A154B0   .  FF35 E016A476 push dword ptr [76A416E0]                ; /Arg1 = 5C0000
76A154B6   .  FF15 9013A076 call near [<&ntdll.RtlLockHeap>]         ; \ntdll.RtlLockHeap
76A154BC   .  897D FC       mov [ebp-4], edi
76A154BF   .  C745 FC 01000 mov dword ptr [ebp-4], 1
76A154C6   .  8D73 FC       lea esi, [ebx-4]
76A154C9   .  56            push esi                                 ; /Arg2
76A154CA   .  68 C016A476   push offset 76A416C0                     ; |Arg1 = KERNELBASE.76A416C0
76A154CF   .  FF15 8C13A076 call near [<&ntdll.RtlIsValidHandle>]    ; \ntdll.RtlIsValidHandle
--->
76A373E8   $  68 5074A376   push 76A37450
76A373ED   .  64:FF35 00000 push dword ptr fs:[0]
76A373F4   .  8B4424 10     mov eax, [esp+10]
76A373F8   .  896C24 10     mov [esp+10], ebp
76A373FC   .  8D6C24 10     lea ebp, [esp+10]
76A37400   .  2BE0          sub esp, eax
76A37402   .  53            push ebx
76A37403   .  56            push esi
76A37404   .  57            push edi
76A37405   .  A1 4012A476   mov eax, [76A41240]
76A3740A   .  3145 FC       xor [ebp-4], eax
76A3740D   .  33C5          xor eax, ebp
76A3740F   .  50            push eax
76A37410   .  8965 E8       mov [ebp-18], esp
76A37413   .  FF75 F8       push dword ptr [ebp-8]
76A37416   .  8B45 FC       mov eax, [ebp-4]
76A37419   .  C745 FC FEFFF mov dword ptr [ebp-4], -2
76A37420   .  8945 F8       mov [ebp-8], eax
76A37423   .  8D45 F0       lea eax, [ebp-10]
76A37426   .  64:A3 0000000 mov fs:[0], eax
76A3742C   .  C3            retn

Note this brilliant example of compiler creativity:

Code Select Expand

75B5D0E5   . |FF15 8003B475 call near [<&ntdll.RtlLockHeap>]         ; \ntdll.RtlLockHeap
75B5D0EB   . |8365 FC 00    and dword ptr [ebp-4], 00000000
75B5D0EF   . |C745 FC 01000 mov dword ptr [ebp-4], 1

[hutch--]

I addressed memory allocation, not an edit control and the comment about using GMEM_FIXED is correct, return value casts directly to a pointer.