Lets say i compile a window with MASM32.

Is there any way i can retrieve the size of the stack that has been allocated for the thread?

thanx in advance

:alright:
Posted on 2001-10-14 21:32:29 by titan
I don't know how to do that programatically. But you can specify
default stack size at link-time. And if you do your own thread creation,
you can specify a stack size in the CreateThread call (or leave at
0 to use default (linktime) stack size for the new thread).

I'm poking around in MSDN right now to see if I can find some more info.
Posted on 2001-10-14 23:00:27 by f0dder
It would seem that the TIB/TEB (Thead Information Block / Thread Environment Block...
9x and NT dudes have different names for it) has some stack related
information (which is quite logical, of course ;)). You find the TIB at
(fs is updated per-thread). You'll have to "assume fs:nothing"
in masm before you can mess with it.

The first two DWORD entries are widely used in SEH (structured
exception handling), and are
FS:00 -- pointer to next handler
FS:04 -- handleraddress

After that comes stackUserTop at 08h, and stackUserBase at 0Ch.
Now, these two values would give you the "remaining stack size",
but not total stack size. And offsets might be wrong, it's 6:15 (AM
for you 12h freaks), and I've been up all night.

But play around with it :).
Posted on 2001-10-14 23:17:20 by f0dder
Ok, I've messed a little with it, and it seems the info was a little wrong :).
is obviously a pointer to an exception structure, where the
first DWORD is "next handler" and the second DWORD is "this handler" -
the values aren't, as I wrote in the previous post, the first two.

This means that
stackUserBase = 04h
stackUserTop = 08h

By subtracting the one from the other, I get the "commit" stack
size I specified in the linker settings (I was confused by this at
first, until I realized the linker parms were in decimal, not hex...
DOH ;). StackUserTop matches my esp pretty well, 16 bytes off.
I guess this is because your app starts with "a few undocumented
things" on the stack, and the TIB isn't updated until the thread is
switched, which doesn't occur in a singlethreaded app (dunno about
the windows process preemptive scheduling, though...)

Ok, this can give you the amount of committed stack, it seems.
But since sackUserBase is a linear address, I dunno how to get the
stack size from that. But I think the stuff I've figured out is sorta
interesting anyway :).
Posted on 2001-10-14 23:42:52 by f0dder
Heh, I topped 500 posts... and it's my 20th birthday... *grin*.

Well, I figured out that the two stack thingamagijcs in the TIB of
course aren't related to the ESP register... they simply show the
max value esp can reach (the top... and I believe esp should always
be 4 less than this?), and the lowest committed stack page (if you
go lower than this, I believe you will have to pre-touch it in 4k increments...
ie, you can't touch 4097 bytes (or more) "further down" than the
committed stack size, because the way the stack grows (guard pages),
but I might of course be wrong... :))
Posted on 2001-10-14 23:51:46 by f0dder
f0dder,

may be using VirtualQuery() should work too. Use VirtualQuery with actual ESP and you may get stack size in MEMORY_BASIC_INFORMATION.RegionSize. But I haven't tried yet.

japheth
Posted on 2001-10-15 01:56:03 by japheth
As I read it, VirtualQuery returns information *beginning* from the
address you specify... and stack grows downwards... :/.
Posted on 2001-10-15 02:01:27 by f0dder
thats right, f0dder, but in my eyes thats a question of the memory being committed or not. I Think if you specify a stack size of 0x100000 at link time the PE loader will allocate a memory region of 0x100000, with only the last page committed. So VirtualQuery should work.

japheth
Posted on 2001-10-15 02:11:23 by japheth
Happy birthday you modest one !
Only 20 years?
grrrrrrrrrrrrrrrrrrrrr
hehe
Congrats.

Latigo
Posted on 2001-10-15 09:35:00 by latigo
Happy Birthday f0dder :alright: . By the time you're 30, we'll all be working on machines of your design. ;)
Posted on 2001-10-15 11:39:28 by lackluster