Adventures in programming: Treeviews, directory scanning, recursion

[sinsi]

The default heap is the one that comes with your program, set by the linker.
A non-growable heap is one you use CreateHeap for, which isn't used much.
You get the default heap with GetProcessHeap and use the return handle for allocating and reallocating heap memory. The default heap is growable, so the only memory limit is available address space.

[NoCforMe]

Thank you, thank you. So nice to get a clear and complete answer!

[jj2007]

The default heap has no limit

So nice to get a clear and complete answer!

You are welcome

With you, I always have to balance the absolutely necessary against your willingness to read longer text like this one (let alone downloads). Besides, I was on my smartphone ;-)

@FreeSpeechBrigade: this is friendly banter. Don't call the police

[NoCforMe]

Aaaargh.

I'm already using GetProcessHeap(). I didn't realize that this gives me the "default heap" (I didn't even know what that was, which is why I found your first reply less than helpful, JJ).

Anyhow. The problem is that HeapReAlloc() gives me a different pointer to the allocated memory than the original allocation from HeapAlloc(). Is this the expected behavior? I was hoping that reallocating would simply enlarge the heap at the same location.

I tried using the HEAP_REALLOC_IN_PLACE_ONLY flag so that the re-allocation would be in the same place as the original one. But then HeapReAlloc() failed.

I really don't understand how this is supposed to work. Say I allocate space for 100K objects with HeapAlloc() and get back a pointer, let's say 23D0020h (that's the actual base address from my last run). Then I do a HeapRealloc() and get a different address back. Does that mean that the original allocation is now invalid? or can I copy my data from the original heap to the "new" heap?

This is bullshit. There's got to be an easier way.

Again, is this (heap allocation) really the way to go here? What about using virtual memory instead?

[sinsi]

Maybe you should read the documentation?

HeapReAlloc is guaranteed to preserve the content of the memory being reallocated, even if the new memory is allocated at a different location.

[NoCforMe]

Goddamnit, I fucking read that! what, you think I'm a total idiot? Don't condescend ...

OK, so it preserves the content of the memory being re-allocated. But where is that memory? At the address of the original allocation? or the address of the re-allocation?

And if the re-allocation is at a different location, wouldn't that mean that you now have two allocated chunks, one at the original location of the original size, the other at the new location at the new size?

Or does this just mean that the new allocation includes all of the old allocation, and that the original allocation is now invalid? Which gets back to the major problem of having to go through my list and rejigger it. (I guess maybe it wouldn't be that hard if I knew the offset from the original allocation to the new one, and then could just readjust all the pointers using this offset. But still a pain in the ass.)

They (Micro$oft) really do not make this clear. Unless I'm having some kind of mental block here ...

[sinsi]

You allocate some memory and save its address in MyPointer.
You later resize the block, passing it MyPointer and receiving a pointer.
If there was enough memory after your block, it just extends it and returns the MyPointer you gave it.
If there wasn't enough, it allocates a new block, copies the existing data, frees the old block and returns the new block's address, which you should store in MyPointer, because what's there now is an invalid pointer.

You are mad if you have stored pointers in every one of your objects, they should be offsets from the base address (MyPointer).

[NoCforMe]

OK, good answer.

It was easier just to store absolute pointers, because I didn't realize that they could change due to reallocation. Ackshooly, it turns out to be trivially easy to adjust the pointers, so kind of 6 of one, half a dozen of the other.

Coding it up now ...

Your way is better. This is new to me, but after thinking about it a minute or three it makes more sense to store offsets than absolute pointers. Takes a little more arithmetic (you've got to add in the base address each time you access a pointer), but requires no readjustments.

[TimoVJL]

Basic vectors are usable in many ways and perhaps in this site we have seen those in asm code too.

[NoCforMe]

Here's the latest, now going by the name of "PicView", your basic picture viewer. Heap allocation stuff all worked out.

sinsi, since you have a nice big fat drive, could you try this out to make sure it scans the whole disk? It should, but none of my drives have that many "objects". (Keep in mind that I'm only counting as objects either folders or files that match my filter: .jpg, .gif, .bmp, .png and .ico. Other files are skipped.)

[stoo23]

Just had a quick 'play', seemed to work fine as far as I can tell   

[NoCforMe]

So how many file+dirs ("objects") on your fattest drive?

[sinsi]

Windows has a stupid habit nowadays of just terminating a program so all the uer sees is the window disappear.
WinDbg will usually use a special stack, which is why it worked OK under the debugger, 255000 objects, but crashed from the desktop with STATUS_STACK_OVERFLOW.

Recursion is your enemy in this case I would imagine.

Code Select Expand

Faulting application name: PicView.exe, version: 0.0.0.0, time stamp: 0x6614a47e
Faulting module name: ntdll.dll, version: 10.0.22621.3374, time stamp: 0x3fddb55c
Exception code: 0xc00000fd
Fault offset: 0x0004b5a1
Faulting process ID: 0x0x2354
Faulting application start time: 0x0x1DA8A2842A677D1
Faulting application path: e:\Desktop\PicView.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report ID: 267ff532-a26f-4da7-9953-5b7bb825e6e5
Faulting package full name:
Faulting package-relative application ID:


[NoCforMe]

Hate to ask you, but would you mind testing again? I increased stack size to 64K DWORDs, attached to post #69 above.

I'll assume no news is good news.

[stoo23]

So how many file+dirs ("objects") on your fattest drive?

Nothing even close to what 'sinsi' had, mine was about a 3rd of that size.