Windows CE stack size

[Enrico Trombetta]

I don't understand why in MSDN is indicated that the default stack size is
1MB:FROM MSDN:/STACK:reserve[,commit]This option sets the size of the stack
in bytes. This option is only for use when building a .exe.

This option specifies the total stack allocation in virtual memory. The
default stack size is 1 MB. The linker rounds up the specified value to the
nearest 4 bytes.

....

And if I create a new Win32 application I find: /STACK:0x10000 that is
64536.

Does anyone have an idea?

[Michael J. Salamone]

Either your reading documentation for Windows9X/NT/2K/XP or the CE
documentation is incorrect.

The default stack size for CE is 64K. And that should be plenty for most
applications. And CE virtual memory is very precious (you get 32MB for your
process). Setting it higher just eats up the address space. If you have
large items you're putting on the stack, think about dynamically allocating
those items instead.

--

Michael Salamone
Entrek Software, Inc.
www.entrek.com

"Enrico Trombetta" <winceit_...@yahoo.it> wrote in message
news:#DHiSyLN...@TK2MSFTNGP11.phx.gbl...

[Enrico Trombetta]

Ok, but my problem is that I'm trying to link a library that use 1MB of
stack.
Unfortunately I haven't got source files.
I have to create a device driver.
Do you have an idea if it's possible to increment Device Manager
(device.exe) stack size?
How can I do that?

"Michael J. Salamone" <mik...@entrek.com> ha scritto nel messaggio
news:%23U4BJRW...@TK2MSFTNGP10.phx.gbl...

[Michael J. Salamone]

You cannot. The process's default stack size is set at build time by the
linker. You could, for RAM-based files, theoretically change the value
(using PEF to binary edit it). You can't do it for system
applications/modules for several reasons: 1) they are ROM-based files, 2)
they are XIP (which means that you wouldn't be able to use PEF), and 3) in
device.exe case, it's already running (it's started at system init time, so
you wouldn't be able to open for write access - even RAM-based file).

I would contact whoever provided the library and see if you can get a change
in.

If you are stuck with that library, then the only alternative would be to
build a new process with stacksize=1MB. And then do some IPC between the
device driver and the new process. That may or may not be practical for
your driver/system, but that would be it.

There are actually two "hack" approaches - that may or may not work - I
haven't tested them.

1) Allocate additional stack before you invoke anything in the library. You
could get the stack base address (just take the address of a stack variable
and call VirtualQuery to get allocation base, size). Then call VirtualAlloc
with a base address which is allocation base+64K (and size to be 1MB-64K -
that for a total 1MB stack). May not work for a couple reasons. First, the
addresses following the stack may already be allocated/reserved (in which
case VirtualAlloc would fail), and second, when handling page guard
exception, the system may not grow the stack beyond the original limits.
You'd have to test to verify - or read the shared source code.

2) Swap the stack. I.e. create an entirely new stack and set the thread to
use the new stack (using SetThreadContext). This may not work for some of
the reasons mentioned above (VirtualAlloc failure, system handling).

--

Michael Salamone
Entrek Software, Inc.
www.entrek.com

"Enrico Trombetta" <winceit_...@yahoo.it> wrote in message

news:#Ss89BXN...@TK2MSFTNGP10.phx.gbl...

[sireesht...@greymatterindia.com]

when my program was showing me stack overflow i used following steps

1) alt+f7 this brings up build option sheet
2) go to linker tab
3) select output...
4) here u can specify stack size and commit size
5) i stick to stack size of 5mb and commit size of 1mb

chk out on u r side..

eVC3.0 PPC for x86,ARM on Win2K professional...