# Correct usage of stack settings

**URL:** <https://clarionhub.com/t/correct-usage-of-stack-settings/7381>\
**Category:** questions\
**Tags:** c11\
**Created:** [August 9, 2024, 5:47am UTC](https://clarionhub.com/t/correct-usage-of-stack-settings/7381 "2024-08-09T05:47:08Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Owen](https://clarionhub.com/letter_avatar_proxy/v4/letter/o/b2d939/32.png) [@Owen](https://clarionhub.com/u/Owen)\
**Post date:** [August 9, 2024, 5:47am UTC](https://clarionhub.com/t/correct-usage-of-stack-settings/7381/1 "2024-08-09T05:47:08Z")

</div>

When looking at the project settings of a Clarion application, there is an option to set the stack size. This option is available for both executables and dlls.

Is this setting even relevant to dlls?

My understanding is that executables are allocated a stack size based on a setting in the PE header. Threads are allocated a stack size via a value passed to the START() function.

So where does stack size fit in for a dll?

There are two other linker settings available if calling the linker manually

STACK\_RESERVE  
STACK\_COMMIT

Where do these fit into the picture?

Any thoughts?

---

<div class="post-metadata">

**Author:** ![anon77170705](https://clarionhub.com/letter_avatar_proxy/v4/letter/a/ecccb3/32.png) [@anon77170705](https://clarionhub.com/u/anon77170705)\
**Post date:** [August 9, 2024, 12:16pm UTC](https://clarionhub.com/t/correct-usage-of-stack-settings/7381/2 "2024-08-09T12:16:20Z")

</div>

> [@Owen](#):
>
> This option is available for both executables and dlls.

Stack-related settings in the DLL header can be used by the system loader. At the moment they are using only for DLLs allowing to be invoked by RUNDLL32. But who can know Microsoft’s plans…

> [@Owen](#):
>
> STACK\_RESERVE

Max size of the stack.

> [@Owen](#):
>
> STACK\_COMMIT

Size of the stack’s part initially allocated in the physical memory. When the committed part exceeded, next portion is committing until all the reserved stack space is exhausted.

Physical memory is a very expensive resource. If some memory is committed but the process does not access it, the OS is backing it up to the page file. If the process is accessing backed up memory, it must be restored from the page file to the physical memory. If memory is reserved but not committed, it is just a record in the virtual memory map structure. Therefore, the recommended way to handle large blocks of memory is to reserve all its size but commit the active part only and commit next portions when this is necessary.