MasmBasic

[dedndave]

75 Kb is nothing - lol
you can do a lot of recursions with that much stack space
and....
i think windows will cache out some memory to disk to make space available for more stack, if needed

now, i understand that it may be limited for a driver - but we aren't talking about drivers   :P

[jj2007]

75 Kb is nothing - lol
you can do a lot of recursions with that much stack space

I agree. In the extreme case of 48 levels, GetFiles uses 28K. At the theoretical maximum of 256 levels, you need about 140,000 bytes, but a little test shows that you have 1,036,228 bytes of stack available:

Code Select Expand

include \masm32\include\masm32rt.inc
.code
start:
xor ecx, ecx
.Repeat
push eax
add ecx, 4
.Until 0
exit
end start


You need Olly to test it, as it will crash silently.

[dedndave]

still - i liked Alex's statement the best - lol

Dave, this discussion is not interesting.

:P

[Antariy]

75 Kb is nothing - lol
you can do a lot of recursions with that much stack space
and....
i think windows will cache out some memory to disk to make space available for more stack, if needed

now, i understand that it may be limited for a driver - but we aren't talking about drivers   :P

Still, Dave... You are not under DOS, and should not decide that you can do almost anything with 512 bytes of stack.

Your program runs under system, and you never can know in which level your code would be called.
So, you should always (always!) decide that your resources are limited.

If some of yours procs was called in some deep code (for example some callback), then you can reach the end even with small local data :P

Decide that your resources as limited as maximally possible :P

[Antariy]

I agree. In the extreme case of 48 levels, GetFiles uses 28K. At the theoretical maximum of 256 levels, you need about 140,000 bytes, but a little test shows that you have 1,036,228 bytes of stack available:

Jochen, this is just one case. I make "speech" in general, I'm not R.E. your latest library yet.

You need Olly to test it, as it will crash silently.

Yes:

In some relatively deep call you will get a stack overflow, and exit without any "error message", since SEH cannot work in this case.

"Bye-Bye" Windows message is default SEH for the thread.

[jj2007]

So I hope we can agree that MasmBasic GetFiles cannot cause a stack overflow unless a mentally sick person uses up 94% of the stack space with some odd recursion algo and then, from that low stack level, calls GetFiles on a folder that has the theoretical maximum of 125 levels of subfolders (yes it is 125, not 256, because 125*x\=250, and more Windows won't tolerate).

[Antariy]

So I hope we can agree that MasmBasic GetFiles cannot cause a stack overflow unless a mentally sick person uses up 94% of the stack space with some odd recursion algo and then, from that low stack level, calls GetFiles on a folder that has the theoretical maximum of 125 levels of subfolders (yes it is 125, not 256, because 125*x\=250, and

Yes, with MB it is almost OK. But you should not search for "mentally sick person". Again, *how you can decide, which is stack "loading" when your code was called in Window/DialogProc, for example?*. Maybe, it is already 94% "full" - you cannot prove inverse... and straight, too :green2

[jj2007]

Hi Alex,
If you can show me at least one real (i.e. not purely hypothetical) application that uses >900k of stack, we should continue the discussion. For info: RichMasm, source code 13,000 lines, uses at most 696 bytes (yes, bytes, not kBytes) of stack.
If that real application then sees an urgent need to search, from that dangerously low stack level, all available files, using in the worst possible scenario another 70k, then I will declare you a guru. Otherwise I might add you to a long list of persons who look desperately for problems where problems do not exist.
Take care,
Jochen

[jj2007]

I have give you one "real application" - TotalCommander as example.

You are confusing things. Yes TC has had stack overflow problems, but it's a bug, not behaviour "by design". Give me an app that is designed to use up its stack to the last drop...

[dedndave]

You can put me in any list you want

careful, Alex - that could bite ya   :bdg

i would say any program that met those conditions was poorly designed, to begin with
i would say MasmBasic is pretty safe, in this regard

as for the topic - you may want to split it to another thread
we are making a mess out of Jochen's MasmBasic stuff

[Antariy]

I have give you one "real application" - TotalCommander as example.

You are confusing things. Yes TC has had stack overflow problems, but it's a bug, not behaviour "by design". Give me an app that is designed to use up its stack to the last drop...

P.S. One application more.

In XP (and almost in 2000) has existing ShimEngine, or Application Compatibility mode, as you know.
And one from switches on the compatibility layers is "StackSwap". Its description:

Many APIs use much more stack space on NT than Win9x. This compatibility fix is command line driven and takes a list of APIs that will be hooked, making them use no stack. The format the command line is "MODULENAME!APINAME[:X]; MODULENAME!APINAME[:X] ..." where X is 0 : fill old stack with zeroes 1 : fill old stack with pointers 2 : fill old stack with pointers to pointers by default, no stack filling occurs.

And it's by default is applied to, for example MSVC 6.0 IDE - very real application... or not?
By the way, when you run many applications, they can already beed covered by ShimEngine. You should find Application Compatibility Toolkit to see which applications was covered by it.


P.P.S. TotalCommander have *design* problem. It was not limit the deep of the recursion, for example, in search and in regular expressions. Now it doing limitation, and because this it works.

[jj2007]

In XP (and almost in 2000) has existing ShimEngine, or Application Compatibility mode

Try this Google search for ShimEngine "stack overflow". An impressing 4 hits, none of them related to the problem.

P.P.S. TotalCommander have *design* problem. It was not limit the deep of the recursion, for example, in search and in regular expressions. Now it doing limitation, and because this it works.

Apps that perform a recursion that can end up using 1,000,000 bytes of stack are indeed poorly designed, and may be a security risk. GetFiles uses at most 7% of that.

But if it makes you happy, I will add to the GetFiles guide the remark "Do not use if you are currently using more than 90% of your stack". By the way, when you arrive at that low level, you should also refrain from using any Windows API, as you have demonstrated yourself above.

@Dave: Thanks, good idea to split the thread. This debate is extremely hypothetical...

[Antariy]

Try this Google search for ShimEngine "stack overflow". An impressing 4 hits, none of them related to the problem.

Because the authors of the programs is not brave enough to confirm such design overlook (since it is one from the baddest).
To confirm that something is design overlook, but not bug, needed brave. For example, yesterday I've sented one bloated fast code to you for looking and testing. And it is contain one design overlook - it is not check the tail of string. I've fixed it already.
But, to be honest, two other's algos is overlooked, too. Just replace nulls before gltestA to crlfs, like this:  :wink

Code Select Expand


align 16
db crlf, crlf, crlf, crlf, crlf
gltestA db "A test", 10, "string", 10, crlf, 10, 10


[Antariy]

By the way, when you arrive at that low level, you should also refrain from using any Windows API, as you have demonstrated yourself above.

No, at the last page of the stack you can still do almost anything (except GUI stuff) what you want - just use NativeAPI. NativeAPI in general do only fast checking for parameters, and calls to the kernel. Kernel's stack is different from user-mode stack. So, you can do anything heavy data processing at last page of the stack with NativeAPI, to say that.

But if it makes you happy, I will add to the GetFiles guide the remark "Do not use if you are currently using more than 90% of your stack".

Again, read some my previous post carefully. With MB recursive search almost all is OK. You only use ~620 bytes, in maximal 128 levels.

Just:
1.) I speak in general.

2.) Reread line 1.) :P

[MusicalMike]

I have to say, putting a BASIC syntax layer ontop of Assembly language is a really cool idea. I don't do much windows assembly language programming these days as I use Macs and linux boxes now days. It would be really cool if this macro system could be ported to nasm, or fasm. (gas is probably a lost cause for this)