flat assembler
Message board for the users of flat assembler.

Index > Windows > VirtualAlloc trouble

Goto page Previous  1, 2, 3  Next
Author
Thread Post new topic Reply to topic
Teehee



Joined: 05 Aug 2009
Posts: 568
Location: Brazil
Teehee
so LocalAlloc you can to realloc?
Post 20 Dec 2009, 12:19
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
Yes you can realloc with the Local* functions. The OS takes care all the allocations and copying for you.
Post 20 Dec 2009, 12:23
View user's profile Send private message Visit poster's website Reply with quote
Teehee



Joined: 05 Aug 2009
Posts: 568
Location: Brazil
Teehee
but internally it does automatically what I should to do manually using VirtualAlloc?
I mean, alloc a bigest space, copy the last data, release last buffer...
Post 20 Dec 2009, 12:26
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
The Local* functions are quite smart. They have strategies to minimise memory copying in many common circumstances. For small memory requirements the Local* functions are very good.
Post 20 Dec 2009, 12:29
View user's profile Send private message Visit poster's website Reply with quote
Teehee



Joined: 05 Aug 2009
Posts: 568
Location: Brazil
Teehee
What do you call 'small memory requeriments'? untill 1Mb? untill 5mb? ...
Post 20 Dec 2009, 12:31
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
I usually use the Local* functions for memory allocations I expect to be less than 1MB. After that I would switch to Virtual* functions with reserve and commit as separate operations.

But it depends upon what you are doing. If you allocate a 16KB block at startup and never need to resize it then the Virtual* functions will be just fine (and probably more efficient).
Post 20 Dec 2009, 12:35
View user's profile Send private message Visit poster's website Reply with quote
Teehee



Joined: 05 Aug 2009
Posts: 568
Location: Brazil
Teehee
What's the best one to an Asm code editor? I think it's hard someone code more than 1mb of ASM-code in a same file...
Post 20 Dec 2009, 12:43
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
Teehee wrote:
What's the best one to an Asm code editor? I think it's hard someone code more than 1mb of ASM-code in a same file...
It depends upon how you handle memory. What are your replacement strategies? What are your delete strategies? Insert? Cut & paste? Undo? Vertical operations? Will you use linked lists or a plain linear buffer?

And a 1MB text file is easy to have, especially if you have predefined data tables.
Post 20 Dec 2009, 13:08
View user's profile Send private message Visit poster's website Reply with quote
Teehee



Joined: 05 Aug 2009
Posts: 568
Location: Brazil
Teehee
well, in my C# prototype, i used a dynamic string array, because this way its easier to control the lines (at least, its how i see), especially at render time.

The plain method, i think i'll need to count the lines sometimes (looking for '\n'). So it's seems slower.

In my prototyp case, i just got a char index and a line index so i move these indexes to insert/remove chars/lines. But all operations like delete/copy selection need more code, bc it's not plain, it need to jump lines.

However, i don't know to do dynamic arrays in Asm.

But i don't have a strategy yet. We need to think which is the best method (if there is a 'best') Smile.
Post 20 Dec 2009, 13:56
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
Well without any defined strategy then I would suggest that attempting to guess the "best" memory functions is premature.

Perhaps I can suggest that you spend some time to layout the basic plan of how you will do things. Once you have the layout only then should you embark upon the finer details of what memory allocation functions to use.
Post 20 Dec 2009, 14:06
View user's profile Send private message Visit poster's website Reply with quote
Teehee



Joined: 05 Aug 2009
Posts: 568
Location: Brazil
Teehee
hmm.. i'm still testing plain/array methods. When I decide which to use, i back. Smile
Post 20 Dec 2009, 14:12
View user's profile Send private message Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
Shouldn't you rather use Heap functions instead of Local?
Post 20 Dec 2009, 17:12
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
Borsuc: What is the advantage of Heap* functions?

This quote is something that always bothers me about using the heap:
Win32 manual wrote:
Memory allocated by HeapAlloc is not movable. Because the system cannot compact a private heap, the heap can become fragmented.
That is why prefer Local* functions.
Post 20 Dec 2009, 17:21
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
Well the Heap functions are high-level functions for a large virtual reserved block. It uses probably a linked list inside that block for its memory operations (offset & length for an allocation probably). So of course it can become fragmented, like files can be stored inside a "block" (harddrive) but then if you delete files and add others it will get fragmented in the process.

I don't know much about the Local and Global functions but I remember them being 'deprecated' so I thought they had less functionality and were not advised to be used. (but kept for backward compatibility only)

PE has a initial heap of a given commit & reserve size, so now you know what it does. You can also create new heaps (blocks) with HeapCreate etc... I think Local and Global use pre-defined heaps anyway.
Post 20 Dec 2009, 17:32
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
Compared to Heap* I know the Local* functions are not constrained by any initial Create function.

The Local* functions are pretty smart, I have used them to allocate blocks of memory 1GB+ with no problems. Although the alignment is not guaranteed in the same way the Virtual* does things. I have also read elsewhere that if you keep some Local memory regions unlocked that the Local(Re)Alloc can shuffle the unlocked regions around (i.e. defragment) to make space for new requests.
Post 20 Dec 2009, 17:44
View user's profile Send private message Visit poster's website Reply with quote
bitshifter



Joined: 04 Dec 2007
Posts: 764
Location: Massachusetts, USA
bitshifter
Alternatively you can use HeapAlloc to get a huge chunk and manage it yourself.
Post 20 Dec 2009, 18:09
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
bitshifter wrote:
Alternatively you can use HeapAlloc to get a huge chunk and manage it yourself.
Only if you have already used HeapCreate to make a huge heap. And this method has no advantage over VirtualAlloc anyway,
Post 20 Dec 2009, 18:18
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
Quote:
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.
http://msdn.microsoft.com/en-us/library/aa366596%28VS.85%29.aspx

How did you manage to allocate 1GB with the default heap? What PE header did you use, that's a lot of heap pages to reserve. Shocked

_________________
Previously known as The_Grey_Beast
Post 20 Dec 2009, 20:21
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
Try it for yourself. Just keep asking for more memory until you get an error.
Post 21 Dec 2009, 00:53
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
Something for you to play with:
Code:
ALLOC_SIZE = 100 shl 20

include 'win32ax.inc'

.code

begin:
 mov     ebx,0
    .again:
    invoke  LocalAlloc,LMEM_FIXED,ALLOC_SIZE
    cmp     eax,0
       jz      .error
      add     ebx,ALLOC_SIZE
      jmp     .again
    .error:
   sub     esp,1 shl 10
        mov     esi,esp
     cinvoke wsprintf,esi,'Allocated %u bytes',ebx
     invoke  MessageBox,0,esi,'LocalAlloc testing',0
   invoke  ExitProcess,0

.end begin    
Post 21 Dec 2009, 01:09
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.