Once more I need your help. It seems that wine is not correct with the way it sets guard pages for stack. Here is an example that works fine on windows, and fails on wine. And yes, I do have a program that does something like this:
PDWORD p = TEB.Tib.StackLimit; *p = 0;
I'm not sure what to do here. It looks like there are several places that we allocate stack, and both of them set first page (last for stack) as a PAGE_GUARD. Could that be that this wasn't what we wanted? Since both places using size of 1. But this looks like sets whole page to be guard page.
Vitaliy Margolen wrote:
Once more I need your help. It seems that wine is not correct with the way it sets guard pages for stack. Here is an example that works fine on windows, and fails on wine. And yes, I do have a program that does something like this:
PDWORD p = TEB.Tib.StackLimit; *p = 0;
I'm not sure what to do here. It looks like there are several places that we allocate stack, and both of them set first page (last for stack) as a PAGE_GUARD. Could that be that this wasn't what we wanted? Since both places using size of 1. But this looks like sets whole page to be guard page.
Looks like you're investigating a software crippling scheme :)
Wine handles the StackLimit in the wrong way. On Windows, the ntteb->StackLimit is set to a low value when the program starts, and as more stack is committed, the kernel increase StackLimit.
On Wine, we never change StackLimit, and it is fixed at the larger of 2Mb or the size the application requests.
The above code results in StackLimit changing. It's possible your crippling software is checking that it changes in a "windows like" way.
Mike
-
Mike McCormack -
Vitaliy Margolen