The MASM Forum Archive 2004 to 2012
Welcome, Guest. Please login or register.
August 26, 2019, 01:21:54 AM

Login with username, password and session length
Search:     Advanced search
128553 Posts in 15254 Topics by 684 Members
Latest Member: mottt
* Home Help Search Login Register
+  The MASM Forum Archive 2004 to 2012
|-+  General Forums
| |-+  The Workshop
| | |-+  MasmBasic
« previous next »
Pages: 1 ... 11 12 [13] 14 15 ... 21 Print
Author Topic: MasmBasic  (Read 139641 times)
dedndave
Member
*****
Posts: 12523


Re: MasmBasic
« Reply #180 on: December 15, 2010, 04:16:02 AM »

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   Tongue
Logged
jj2007
Member
*****
Gender: Male
Posts: 6011



Re: MasmBasic
« Reply #181 on: December 15, 2010, 08:10:16 AM »

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:
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.
Logged

dedndave
Member
*****
Posts: 12523


Re: MasmBasic
« Reply #182 on: December 15, 2010, 11:21:53 AM »

still - i liked Alex's statement the best - lol
Quote
Dave, this discussion is not interesting.
Tongue
Logged
Antariy
Member
*****
Gender: Male
Posts: 1041


Re: MasmBasic
« Reply #183 on: December 15, 2010, 02:24:50 PM »

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   Tongue

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 Tongue

Decide that your resources as limited as maximally possible Tongue
Logged
Antariy
Member
*****
Gender: Male
Posts: 1041


Re: MasmBasic
« Reply #184 on: December 15, 2010, 02:27:55 PM »

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.
Logged
jj2007
Member
*****
Gender: Male
Posts: 6011



Re: MasmBasic
« Reply #185 on: December 15, 2010, 04:18:41 PM »

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).
Logged

Antariy
Member
*****
Gender: Male
Posts: 1041


Re: MasmBasic
« Reply #186 on: December 16, 2010, 01:16:33 AM »

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
Logged
jj2007
Member
*****
Gender: Male
Posts: 6011



Re: MasmBasic
« Reply #187 on: December 16, 2010, 01:30:37 AM »

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
Logged

jj2007
Member
*****
Gender: Male
Posts: 6011



Re: MasmBasic
« Reply #188 on: December 16, 2010, 01:46:31 AM »

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...
Logged

dedndave
Member
*****
Posts: 12523


Re: MasmBasic
« Reply #189 on: December 16, 2010, 01:47:51 AM »

Quote
You can put me in any list you want

careful, Alex - that could bite ya   BadGrin

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
Logged
Antariy
Member
*****
Gender: Male
Posts: 1041


Re: MasmBasic
« Reply #190 on: December 16, 2010, 01:49:21 AM »

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:

Quote
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.
Logged
jj2007
Member
*****
Gender: Male
Posts: 6011



Re: MasmBasic
« Reply #191 on: December 16, 2010, 02:00:02 AM »

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.

Quote
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...
Logged

Antariy
Member
*****
Gender: Male
Posts: 1041


Re: MasmBasic
« Reply #192 on: December 16, 2010, 02:06:30 AM »

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:
align 16
db crlf, crlf, crlf, crlf, crlf
gltestA db "A test", 10, "string", 10, crlf, 10, 10

Logged
Antariy
Member
*****
Gender: Male
Posts: 1041


Re: MasmBasic
« Reply #193 on: December 16, 2010, 02:10:42 AM »

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.) Tongue
Logged
MusicalMike
Member
*****
Posts: 147


Re: MasmBasic
« Reply #194 on: December 23, 2010, 07:54:06 PM »

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)
Logged
Pages: 1 ... 11 12 [13] 14 15 ... 21 Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP The MASM Forum Archive 2004 to 2012 | Powered by SMF 1.0.12.
© 2001-2005, Lewis Media. All Rights Reserved.
Valid XHTML 1.0! Valid CSS!