[answer to m.mclean..i post it separately as for me that low level
things are specially interesting and worth separate message imo..though
i kno sadly there are not much low lewel winapi likers people here, like
me who likes low lewel and uses winapi]

this is not strictly true

well important knowledge which not mantyy programers know i think is
that how the layout of program im memory of you system is exactly

and i think this knowledge should be learn "by heart" just to increase understanding

i know somewhat how it looks like in win32 :

generally the addres space aplication have os from 0x0000 0000 to 0x7fff
ffff - which is only 2 gigabytes

(hovever i like it and still prefer writing my windows programs on win32
than win 64, 2 gigabytes of ram is enough for me)

your program is by default placed at 0x0040 0000 (which is 4MB from
start of adres space)..there is smal pe header loaded to ram then your
assembly binary code (typical entry point it is first assemby
instruction to run is at 0x00401000 ) then you got loaded const data
(.data and .rdata)
after the machine code then you got, static empty arrays (.bss) (which are usually big like 100 MB or more depending how many static arrays you
got) (allso smaller sections also could be placed there .rsrc for
example, .tls, .idata (imports), .CRT, .tls)

the dlls your program links to are placed from the top it is from 0x7fff
ffff down below, both system ones, part side ones or yours own

system ones are optimised to not have .bss which consumes most of the
memory so system dlls do not occupy lot of ram (hovevevr system dlls
loads and i for example write pure winapi programs and still that system
dlls loaded in my program space are nearly 20 od system dlls)

heap you got BETWEEN end of your code and begin of dlls, so if your
program uses 300 MB od static tables (my fault as i used tod eclate a
lot of static tables in various files) and your dlls in sum use 500 MB
(of their .bss mostly) then your heap is limited to 1.3 GB on win32

at least this is what i know


the stack in turn is betwwwen your app start that +4MB and the starting
point, im not exactly syre but its probably something about +3M down do
+1M approximatelly

stack could be set to bigger in your exe heder your exe has 9may be
modified by -something switch in gcc comandline) and i not tested it
afair (or rather tested but forgot the strict conclusions) but i dont
se nthing specially wrong even in setting this stack to 100 MB

2 MB by default is silly and if you have 10 GB of ram putting 100 MB for
stack is not even a waste becouse if it is not used it only consumes
"logical" ram pages afair but reall ram is not even attached
(downside is it will not run on pc that have less that 100 MB ram as it
couldnt alloocate stac i guess but some must assume some numbers today probably, and sadly i would assume at least 2-4 GB and assuming less is optimisation)

(I also dont checked if there are some hardcoded limits for stack size
like it cant be bigger than 1 Gb or so, could be checked)

some vaules some can obtain just by printfing pointers in c application, pointers to stack objectm, pointer to aray begoning pointer to some
function, maybe pointer to dlls attached (its function or datya) and
pointers to heap storage

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

fir wrote:

[answer to m.mclean..i post it separately as for me that low level
things are specially interesting and worth separate message imo..though
i kno sadly there are not much low lewel winapi likers people here, like
me who likes low lewel and uses winapi]

this is not strictly true

well important knowledge which not mantyy programers know i think is
that how the layout of program im memory of you system is exactly

and i think this knowledge should be learn "by heart" just to increase understanding

i know somewhat how it looks like in win32 :

generally the addres space aplication have os from 0x0000 0000 to 0x7fff
ffff - which is only 2 gigabytes

(hovever i like it and still prefer writing my windows programs on win32
than win 64, 2 gigabytes of ram is enough for me)

your program is by default placed at 0x0040 0000 (which is 4MB from
start of adres space)..there is smal pe header loaded to ram then your assembly binary code (typical entry point it is first assemby
instruction to run is at 0x00401000 ) then you got loaded const data
(.data and .rdata)
after the machine code then you got, static empty arrays (.bss) (which are usually big like 100 MB or more depending how many static arrays you
got) (allso smaller sections also could be placed there .rsrc for
example, .tls, .idata (imports), .CRT, .tls)

the dlls your program links to are placed from the top it is from 0x7fff
ffff down below, both system ones, part side ones or yours own

system ones are optimised to not have .bss which consumes most of the
memory so system dlls do not occupy lot of ram (hovevevr system dlls
loads and i for example write pure winapi programs and still that system
dlls loaded in my program space are nearly 20 od system dlls)

heap you got BETWEEN end of your code and begin of dlls, so if your
program uses 300 MB od static tables (my fault as i used tod eclate a
lot of static tables in various files) and your dlls in sum use 500 MB
(of their .bss mostly) then your heap is limited to 1.3 GB on win32

at least this is what i know

the stack in turn is betwwwen your app start that +4MB and the starting point, im not exactly syre but its probably something about +3M down do
+1M approximatelly

stack could be set to bigger in your exe heder your exe has 9may be
modified by -something switch in gcc comandline) and i not tested it
afair (or rather tested but forgot the strict conclusions) but i dont
se nthing specially wrong even in setting this stack to 100 MB

2 MB by default is silly and if you have 10 GB of ram putting 100 MB for stack is not even a waste becouse if it is not used it only consumes "logical" ram pages afair but reall ram is not even attached
(downside is it will not run on pc that have less that 100 MB ram as it couldnt alloocate stac i guess but some must assume some numbers today probably, and sadly i would assume at least 2-4 GB and assuming less is optimisation)

(I also dont checked if there are some hardcoded limits for stack size
like it cant be bigger than 1 Gb or so, could be checked)

some vaules some can obtain just by printfing pointers in c application, pointers to stack objectm, pointer to aray begoning pointer to some
function, maybe pointer to dlls attached (its function or datya) and
pointers to heap storage

note some experimentation

void foo(int how)
{
int b = 90;

printf("\n b %p ", &b);

if(how>0) foo(how-1);

}

int main(void)
{

int a = 100;
printf(" main %p , a %p", main, &a);

foo(10);

// (.... here rest of bigger program skipped as i dont wanted to start
new project foor test

}

the result

main 00402BC0 , a 0022FF48
b 0022FF4C
b 0022FF0C
b 0022FEDC
b 0022FEAC
b 0022FE7C
b 0022FE4C
b 0022FE1C
b 0022FDEC
b 0022FDBC
b 0022FD8C
b 0022FD5C

the entry point is about as i said, stack seem to be probably from
0x0023 0000 down below to 0x0003 0000, dont know if its weird if a
variable is 'below' the first b - it seem meybe weird but i dont hinked
why is that, i may yet run a crash test

void foo(int how)
{
int b = 90;
int tab[32*1024];

tab[0] = how;

printf("\n b %p tab %p ", &b, tab);

if(how>0) foo(how-1);

}

int main(void)
{

int a = 100;
printf(" main %p , a %p", main, &a);

foo(15);

//...
}


result

main 00402C10 , a 0022FF4C
b 0020FF0C tab 0020FF10
b 001EFEDC tab 001EFEE0
b 001CFEAC tab 001CFEB0
b 001AFE7C tab 001AFE80
b 0018FE4C tab 0018FE50
b 0016FE1C tab 0016FE20
b 0014FDEC tab 0014FDF0
b 0012FDBC tab 0012FDC0
b 0010FD8C tab 0010FD90
b 000EFD5C tab 000EFD60
b 000CFD2C tab 000CFD30
b 000AFCFC tab 000AFD00
b 0008FCCC tab 0008FCD0
b 0006FC9C tab 0006FCA0
b 0004FC6C tab 0004FC70

floating window appear "there occured a problem with this application..
do send a data on this problem to microsoft?"

so it is like expected

(hovevevr if i would be bill gates i would tell them to clearly note
what kind of error this is if this is stack overflow say it is stack
overflow)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

fir wrote:

fir wrote:

[answer to m.mclean..i post it separately as for me that low level
things are specially interesting and worth separate message imo..though
i kno sadly there are not much low lewel winapi likers people here, like
me who likes low lewel and uses winapi]

this is not strictly true

well important knowledge which not mantyy programers know i think is
that how the layout of program im memory of you system is exactly

and i think this knowledge should be learn "by heart" just to increase
understanding

i know somewhat how it looks like in win32 :

generally the addres space aplication have os from 0x0000 0000 to 0x7fff
ffff - which is only 2 gigabytes

(hovever i like it and still prefer writing my windows programs on win32
than win 64, 2 gigabytes of ram is enough for me)

your program is by default placed at 0x0040 0000 (which is 4MB from
start of adres space)..there is smal pe header loaded to ram then your
assembly binary code (typical entry point it is first assemby
instruction to run is at 0x00401000 ) then you got loaded const data
(.data and .rdata)
after the machine code then you got, static empty arrays (.bss) (which
are
usually big like 100 MB or more depending how many static arrays you
got) (allso smaller sections also could be placed there .rsrc for
example, .tls, .idata (imports), .CRT, .tls)

the dlls your program links to are placed from the top it is from 0x7fff
ffff down below, both system ones, part side ones or yours own

system ones are optimised to not have .bss which consumes most of the
memory so system dlls do not occupy lot of ram (hovevevr system dlls
loads and i for example write pure winapi programs and still that system
dlls loaded in my program space are nearly 20 od system dlls)

heap you got BETWEEN end of your code and begin of dlls, so if your
program uses 300 MB od static tables (my fault as i used tod eclate a
lot of static tables in various files) and your dlls in sum use 500 MB
(of their .bss mostly) then your heap is limited to 1.3 GB on win32

at least this is what i know


the stack in turn is betwwwen your app start that +4MB and the starting
point, im not exactly syre but its probably something about +3M down do
+1M approximatelly

stack could be set to bigger in your exe heder your exe has 9may be
modified by -something switch in gcc comandline) and i not tested it
afair (or rather tested but forgot the strict conclusions) but i dont
se nthing specially wrong even in setting this stack to 100 MB

2 MB by default is silly and if you have 10 GB of ram putting 100 MB for
stack is not even a waste becouse if it is not used it only consumes
"logical" ram pages afair but reall ram is not even attached
(downside is it will not run on pc that have less that 100 MB ram as it
couldnt alloocate stac i guess but some must assume some numbers today
probably, and sadly i would assume at least 2-4 GB and assuming less is
optimisation)

(I also dont checked if there are some hardcoded limits for stack size
like it cant be bigger than 1 Gb or so, could be checked)

some vaules some can obtain just by printfing pointers in c application,
pointers to stack objectm, pointer to aray begoning pointer to some
function, maybe pointer to dlls attached (its function or datya) and
pointers to heap storage

note some experimentation

void foo(int how)
{
int b = 90;

printf("\n b %p ", &b);

if(how>0) foo(how-1);

}

int main(void)
{

int a = 100;
printf(" main %p , a %p", main, &a);

foo(10);

// (.... here rest of bigger program skipped as i dont wanted to start
new project foor test

}

the result

main 00402BC0 , a 0022FF48
b 0022FF4C
b 0022FF0C
b 0022FEDC
b 0022FEAC
b 0022FE7C
b 0022FE4C
b 0022FE1C
b 0022FDEC
b 0022FDBC
b 0022FD8C
b 0022FD5C

the entry point is about as i said, stack seem to be probably from
0x0023 0000 down below to 0x0003 0000, dont know if its weird if a
variable is 'below' the first b - it seem meybe weird but i dont hinked
why is that, i may yet run a crash test

void foo(int how)
{
int b = 90;
int tab[32*1024];

tab[0] = how;

printf("\n b %p tab %p ", &b, tab);

if(how>0) foo(how-1);

}

int main(void)
{

int a = 100;
printf(" main %p , a %p", main, &a);

foo(15);

//...
}

result

main 00402C10 , a 0022FF4C
b 0020FF0C tab 0020FF10
b 001EFEDC tab 001EFEE0
b 001CFEAC tab 001CFEB0
b 001AFE7C tab 001AFE80
b 0018FE4C tab 0018FE50
b 0016FE1C tab 0016FE20
b 0014FDEC tab 0014FDF0
b 0012FDBC tab 0012FDC0
b 0010FD8C tab 0010FD90
b 000EFD5C tab 000EFD60
b 000CFD2C tab 000CFD30
b 000AFCFC tab 000AFD00
b 0008FCCC tab 0008FCD0
b 0006FC9C tab 0006FCA0
b 0004FC6C tab 0004FC70

floating window appear "there occured a problem with this application..
do send a data on this problem to microsoft?"

so it is like expected

(hovevevr if i would be bill gates i would tell them to clearly note
what kind of error this is if this is stack overflow say it is stack overflow)

yet some crash test with stack set to 100 MB (-Wl,--stack,104857600)


void foo(int how)
{
int b = 90;
int tab[2*1024*1024];

tab[0] = how;

printf("\n b %p tab %p ", &b, tab);

if(how>0) foo(how-1);

}

int main(void)
{

int a = 100;
printf(" main %p , a %p", main, &a);

foo(11);

//.....
}

main 00402C10 , a 0680FF4C
b 0600FF0C tab 0600FF10
b 0580FEDC tab 0580FEE0
b 0500FEAC tab 0500FEB0
b 0480FE7C tab 0480FE80
b 0400FE4C tab 0400FE50
b 0380FE1C tab 0380FE20
b 0300FDEC tab 0300FDF0
b 0280FDBC tab 0280FDC0
b 0200FD8C tab 0200FD90
b 0180FD5C tab 0180FD60
b 0100FD2C tab 0100FD30
b 0080FCFC tab 0080FD00

one more of depth and crashes but with longer delay until the floating
window of error appear

besides setting stack to 100 MB seem to work ok

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

fir wrote:

fir wrote:

fir wrote:

[answer to m.mclean..i post it separately as for me that low level
things are specially interesting and worth separate message imo..though
i kno sadly there are not much low lewel winapi likers people here, like >>> me who likes low lewel and uses winapi]

this is not strictly true

well important knowledge which not mantyy programers know i think is
that how the layout of program im memory of you system is exactly

and i think this knowledge should be learn "by heart" just to increase
understanding

i know somewhat how it looks like in win32 :

generally the addres space aplication have os from 0x0000 0000 to 0x7fff >>> ffff - which is only 2 gigabytes

(hovever i like it and still prefer writing my windows programs on win32 >>> than win 64, 2 gigabytes of ram is enough for me)

your program is by default placed at 0x0040 0000 (which is 4MB from
start of adres space)..there is smal pe header loaded to ram then your
assembly binary code (typical entry point it is first assemby
instruction to run is at 0x00401000 ) then you got loaded const data
(.data and .rdata)
after the machine code then you got, static empty arrays (.bss) (which
are
usually big like 100 MB or more depending how many static arrays you
got) (allso smaller sections also could be placed there .rsrc for
example, .tls, .idata (imports), .CRT, .tls)

the dlls your program links to are placed from the top it is from 0x7fff >>> ffff down below, both system ones, part side ones or yours own

system ones are optimised to not have .bss which consumes most of the
memory so system dlls do not occupy lot of ram (hovevevr system dlls
loads and i for example write pure winapi programs and still that system >>> dlls loaded in my program space are nearly 20 od system dlls)

heap you got BETWEEN end of your code and begin of dlls, so if your
program uses 300 MB od static tables (my fault as i used tod eclate a
lot of static tables in various files) and your dlls in sum use 500 MB
(of their .bss mostly) then your heap is limited to 1.3 GB on win32

at least this is what i know


the stack in turn is betwwwen your app start that +4MB and the starting
point, im not exactly syre but its probably something about +3M down do
+1M approximatelly

stack could be set to bigger in your exe heder your exe has 9may be
modified by -something switch in gcc comandline) and i not tested it
afair (or rather tested but forgot the strict conclusions) but i dont
se nthing specially wrong even in setting this stack to 100 MB

2 MB by default is silly and if you have 10 GB of ram putting 100 MB for >>> stack is not even a waste becouse if it is not used it only consumes
"logical" ram pages afair but reall ram is not even attached
(downside is it will not run on pc that have less that 100 MB ram as it
couldnt alloocate stac i guess but some must assume some numbers today
probably, and sadly i would assume at least 2-4 GB and assuming less is
optimisation)

(I also dont checked if there are some hardcoded limits for stack size
like it cant be bigger than 1 Gb or so, could be checked)

some vaules some can obtain just by printfing pointers in c application, >>> pointers to stack objectm, pointer to aray begoning pointer to some
function, maybe pointer to dlls attached (its function or datya) and
pointers to heap storage

note some experimentation

void foo(int how)
{
int b = 90;

printf("\n b %p ", &b);

if(how>0) foo(how-1);

}

int main(void)
{

int a = 100;
printf(" main %p , a %p", main, &a);

foo(10);

// (.... here rest of bigger program skipped as i dont wanted to start
new project foor test

}

the result

main 00402BC0 , a 0022FF48
b 0022FF4C
b 0022FF0C
b 0022FEDC
b 0022FEAC
b 0022FE7C
b 0022FE4C
b 0022FE1C
b 0022FDEC
b 0022FDBC
b 0022FD8C
b 0022FD5C

the entry point is about as i said, stack seem to be probably from
0x0023 0000 down below to 0x0003 0000, dont know if its weird if a
variable is 'below' the first b - it seem meybe weird but i dont hinked
why is that, i may yet run a crash test

void foo(int how)
{
int b = 90;
int tab[32*1024];

tab[0] = how;

printf("\n b %p tab %p ", &b, tab);

if(how>0) foo(how-1);

}

int main(void)
{

int a = 100;
printf(" main %p , a %p", main, &a);

foo(15);

//...
}


result

main 00402C10 , a 0022FF4C
b 0020FF0C tab 0020FF10
b 001EFEDC tab 001EFEE0
b 001CFEAC tab 001CFEB0
b 001AFE7C tab 001AFE80
b 0018FE4C tab 0018FE50
b 0016FE1C tab 0016FE20
b 0014FDEC tab 0014FDF0
b 0012FDBC tab 0012FDC0
b 0010FD8C tab 0010FD90
b 000EFD5C tab 000EFD60
b 000CFD2C tab 000CFD30
b 000AFCFC tab 000AFD00
b 0008FCCC tab 0008FCD0
b 0006FC9C tab 0006FCA0
b 0004FC6C tab 0004FC70

floating window appear "there occured a problem with this application..
do send a data on this problem to microsoft?"

so it is like expected

(hovevevr if i would be bill gates i would tell them to clearly note
what kind of error this is if this is stack overflow say it is stack
overflow)

yet some crash test with stack set to 100 MB (-Wl,--stack,104857600)

void foo(int how)
{
int b = 90;
int tab[2*1024*1024];

tab[0] = how;

printf("\n b %p tab %p ", &b, tab);

if(how>0) foo(how-1);

}

int main(void)
{

int a = 100;
printf(" main %p , a %p", main, &a);

foo(11);

//.....
}

main 00402C10 , a 0680FF4C
b 0600FF0C tab 0600FF10
b 0580FEDC tab 0580FEE0
b 0500FEAC tab 0500FEB0
b 0480FE7C tab 0480FE80
b 0400FE4C tab 0400FE50
b 0380FE1C tab 0380FE20
b 0300FDEC tab 0300FDF0
b 0280FDBC tab 0280FDC0
b 0200FD8C tab 0200FD90
b 0180FD5C tab 0180FD60
b 0100FD2C tab 0100FD30
b 0080FCFC tab 0080FD00

one more of depth and crashes but with longer delay until the floating
window of error appear

besides setting stack to 100 MB seem to work ok

as far as it seems when you put stack bigger than 2MB the layout of ram
is like that


0-4M: (dont know some probably reserved)
4M+: your exe with your exe .bss (static tables)
:stack (of declared size)
:heap (all empty space between stack and dlls)
below 2G (from the and down below) : dlls

in fact there are 2 dlls (what i sen in olly debug who shows that all
(ws2_32 and ws2help) which are not throwed in this dll region
but was put in that lowest 4MB area - dont know what it is and why
but besides that most things are generally clear

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20/03/2024 14:02, fir wrote:

i know somewhat how it looks like in win32 :

generally the addres space aplication have os from 0x0000 0000 to 0x7fff
ffff - which is only 2 gigabytes

(hovever i like it and still prefer writing my windows programs on win32
than win 64, 2 gigabytes of ram is enough for me)

your program is by default placed at 0x0040 0000 (which is 4MB from
start of adres space)..

That's no longer the case with 64-bit machines, not if you use products
like gcc. This program:

#include "stdio.h"
int main(void) {
printf("%p\n", main);
}

displays 00007ff64a931591 when compiled with gcc. Even on 32-bits using
`gcc -m32`, it shows 0076155c.

at least this is what i know

the stack in turn is betwwwen your app start that +4MB and the starting point, im not exactly syre but its probably something about +3M down do
+1M approximatelly

stack could be set to bigger in your exe heder your exe has 9may be
modified by -something switch in gcc comandline) and i not tested it
afair (or rather tested but forgot the strict conclusions) but i dont
se nthing specially wrong even in setting this stack to 100 MB

2 MB by default is silly and if you have 10 GB of ram putting 100 MB for stack is not even a waste becouse if it is not used it only consumes "logical" ram pages afair but reall ram is not even attached

I don't think using a giant stack just one for the benefit of one badly-designed function in one library inside a big application is a
good approach.

Maybe the routine is never called. Or it's called once then never called
again but the stack is now committed.

Your floodfill routine uses 48 bytes per call (with my compiler; it
varies). To floodfill all the pixels in a 3000x4000 pixel image for
example, would need nearly 600MB of stack, and would involve calls
nested 12 million deep.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

fir wrote:

is like that

0-4M: (dont know some probably reserved)
4M+: your exe with your exe .bss (static tables)
:stack (of declared size)
:heap (all empty space between stack and dlls)
below 2G (from the and down below) : dlls

so in sum i would say that both heap and stack are somewhat limited - by
user present ram, stack seems a bit more limited as you need to declare
its size

hovever as there is this space between exe and dlls, and yet stack grows
down they could both make undeclared as some would not need to declare
stack size in fact it just grow until it clashes with heap area

so maybe this stack declaration is kinda mistake at least on win32 or
maybe it could be ony treated "one way" the declaration could say stack
is at least 100 MB but may be bigger....hovever user also could load
more dlls in runtime so they are needed to be put in adres space tooo

stack besides has soem serious advantages over heap..and maybe i shopuld
use it more

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

bart wrote:

On 20/03/2024 14:02, fir wrote:

i know somewhat how it looks like in win32 :

generally the addres space aplication have os from 0x0000 0000 to
0x7fff ffff - which is only 2 gigabytes

(hovever i like it and still prefer writing my windows programs on
win32 than win 64, 2 gigabytes of ram is enough for me)

your program is by default placed at 0x0040 0000 (which is 4MB from
start of adres space)..

That's no longer the case with 64-bit machines, not if you use products
like gcc. This program:

#include "stdio.h"
int main(void) {
printf("%p\n", main);
}

displays 00007ff64a931591 when compiled with gcc. Even on 32-bits using
`gcc -m32`, it shows 0076155c.

at least this is what i know


the stack in turn is betwwwen your app start that +4MB and the
starting point, im not exactly syre but its probably something about
+3M down do +1M approximatelly

stack could be set to bigger in your exe heder your exe has 9may be
modified by -something switch in gcc comandline) and i not tested it
afair (or rather tested but forgot the strict conclusions) but i dont
se nthing specially wrong even in setting this stack to 100 MB

2 MB by default is silly and if you have 10 GB of ram putting 100 MB
for stack is not even a waste becouse if it is not used it only
consumes "logical" ram pages afair but reall ram is not even attached

I don't think using a giant stack just one for the benefit of one badly-designed function in one library inside a big application is a
good approach.

but you call this function badly designed becouse it can overflow stack

- if it cant it is not badly designed then (unles you say on something
other)

this recursion in fact is not badly designed imo - you only need to be
aware of constraints of data you used it to (and if you care of
constraints of your code you could also somewhat care of constraints on
data)

its suboptimal as to speed but i wouldnt cal it "badly designed"

as i said in another thread the error may be to declare stack size,
it not necessarely need to be declared maybe - then you use stack until
the ram will end - as today people use normal ram, nearly none
application is ready to situatuion that ram ends and heap alocations
fail..so with stack may be tha same

Maybe the routine is never called. Or it's called once then never called again but the stack is now committed.

Your floodfill routine uses 48 bytes per call (with my compiler; it
varies). To floodfill all the pixels in a 3000x4000 pixel image for
example, would need nearly 600MB of stack, and would involve calls
nested 12 million deep.

there was an shortcut in it you dont need to pass the 2 colors in calls
so i think it rather should use int x int y and ret adress it is 12
bytes (on 32 bit, i compile 32 bit only)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

fir wrote:

bart wrote:

On 20/03/2024 14:02, fir wrote:

i know somewhat how it looks like in win32 :

generally the addres space aplication have os from 0x0000 0000 to
0x7fff ffff - which is only 2 gigabytes

(hovever i like it and still prefer writing my windows programs on
win32 than win 64, 2 gigabytes of ram is enough for me)

your program is by default placed at 0x0040 0000 (which is 4MB from
start of adres space)..

That's no longer the case with 64-bit machines, not if you use products
like gcc. This program:

#include "stdio.h"
int main(void) {
printf("%p\n", main);
}

displays 00007ff64a931591 when compiled with gcc. Even on 32-bits using
`gcc -m32`, it shows 0076155c.

at least this is what i know


the stack in turn is betwwwen your app start that +4MB and the
starting point, im not exactly syre but its probably something about
+3M down do +1M approximatelly

stack could be set to bigger in your exe heder your exe has 9may be
modified by -something switch in gcc comandline) and i not tested it
afair (or rather tested but forgot the strict conclusions) but i dont
se nthing specially wrong even in setting this stack to 100 MB

2 MB by default is silly and if you have 10 GB of ram putting 100 MB
for stack is not even a waste becouse if it is not used it only
consumes "logical" ram pages afair but reall ram is not even attached

I don't think using a giant stack just one for the benefit of one
badly-designed function in one library inside a big application is a
good approach.

but you call this function badly designed becouse it can overflow stack

- if it cant it is not badly designed then (unles you say on something
other)

this recursion in fact is not badly designed imo - you only need to be
aware of constraints of data you used it to (and if you care of
constraints of your code you could also somewhat care of constraints on
data)

its suboptimal as to speed but i wouldnt cal it "badly designed"

as i said in another thread the error may be to declare stack size,
it not necessarely need to be declared maybe - then you use stack until
the ram will end - as today people use normal ram, nearly none
application is ready to situatuion that ram ends and heap alocations
fail..so with stack may be tha same

Maybe the routine is never called. Or it's called once then never called
again but the stack is now committed.

Your floodfill routine uses 48 bytes per call (with my compiler; it
varies). To floodfill all the pixels in a 3000x4000 pixel image for
example, would need nearly 600MB of stack, and would involve calls
nested 12 million deep.

there was an shortcut in it you dont need to pass the 2 colors in calls
so i think it rather should use int x int y and ret adress it is 12
bytes (on 32 bit, i compile 32 bit only)

i wouldnt say its badly designed but for sure its kinda brute-force
but not in kinds of like cpu and iterations (like counting milion
objects collisions with another milion objets) but more bruteforce in
stack usage - but brute force methods are so nice..they just dont work
becouse of big numbers

possibly there may be written a method of thi recolorisation wich uses
50 bytes of ram, but here i wonder if use even 300 Mb of ram for a blink
of an eye time is not standable

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

fir wrote:

fir wrote:

bart wrote:

On 20/03/2024 14:02, fir wrote:

i know somewhat how it looks like in win32 :

generally the addres space aplication have os from 0x0000 0000 to
0x7fff ffff - which is only 2 gigabytes

(hovever i like it and still prefer writing my windows programs on
win32 than win 64, 2 gigabytes of ram is enough for me)

your program is by default placed at 0x0040 0000 (which is 4MB from
start of adres space)..

That's no longer the case with 64-bit machines, not if you use products
like gcc. This program:

#include "stdio.h"
int main(void) {
printf("%p\n", main);
}

displays 00007ff64a931591 when compiled with gcc. Even on 32-bits using
`gcc -m32`, it shows 0076155c.

at least this is what i know


the stack in turn is betwwwen your app start that +4MB and the
starting point, im not exactly syre but its probably something about
+3M down do +1M approximatelly

stack could be set to bigger in your exe heder your exe has 9may be
modified by -something switch in gcc comandline) and i not tested it
afair (or rather tested but forgot the strict conclusions) but i dont
se nthing specially wrong even in setting this stack to 100 MB

2 MB by default is silly and if you have 10 GB of ram putting 100 MB
for stack is not even a waste becouse if it is not used it only
consumes "logical" ram pages afair but reall ram is not even attached

I don't think using a giant stack just one for the benefit of one
badly-designed function in one library inside a big application is a
good approach.

but you call this function badly designed becouse it can overflow stack

- if it cant it is not badly designed then (unles you say on something
other)

this recursion in fact is not badly designed imo - you only need to be
aware of constraints of data you used it to (and if you care of
constraints of your code you could also somewhat care of constraints on
data)

its suboptimal as to speed but i wouldnt cal it "badly designed"

as i said in another thread the error may be to declare stack size,
it not necessarely need to be declared maybe - then you use stack until
the ram will end - as today people use normal ram, nearly none
application is ready to situatuion that ram ends and heap alocations
fail..so with stack may be tha same

Maybe the routine is never called. Or it's called once then never called >>> again but the stack is now committed.

Your floodfill routine uses 48 bytes per call (with my compiler; it
varies). To floodfill all the pixels in a 3000x4000 pixel image for
example, would need nearly 600MB of stack, and would involve calls
nested 12 million deep.

there was an shortcut in it you dont need to pass the 2 colors in calls
so i think it rather should use int x int y and ret adress it is 12
bytes (on 32 bit, i compile 32 bit only)

i wouldnt say its badly designed but for sure its kinda brute-force
but not in kinds of like cpu and iterations (like counting milion
objects collisions with another milion objets) but more bruteforce in
stack usage - but brute force methods are so nice..they just dont work becouse of big numbers

possibly there may be written a method of thi recolorisation wich uses
50 bytes of ram, but here i wonder if use even 300 Mb of ram for a blink
of an eye time is not standable

also not how this call queue (ir it would be in c strict runtime (by
strict runtime i mean this what is compiled-in by compiler like inside a program, not a runtime library) )would improve things

with this call queue pixel in one generation just spawns a 1-pixel thin
border around it - then in next generation it spawns another thin border
- and the ram consuption if im not wrong is limited to this older border
that is processed and the newer wjich is spawned so even for 10000x10000
image the ram consumption should be small

they dhould do it in sixties

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

bart wrote:

Maybe the routine is never called. Or it's called once then never called again but the stack is now committed.

as far as i know it is not commited..im not 100 procent sure (as it
would probably need to use soem tool that shows that, maybe there are
some) but probably what i think is rught

windows will swap unused pages away from ram and it work in runtime
i mean if you declare 300 MB stack use it once and then for an hour you
use only 2 MB of this the 298 MB of physical ram will nt be "taken"

it is not hard to do it in system i think just as aplication acces ram
thry some table you may monitor once a time which regions are alocated
and non used and "detatch " phisical ram ftom thsi area - then attach it
if there is an acces -0 where this detach and attach is not very slow
operation

thats how i see it..i readed something about this but not much and long
time ago

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

fir wrote:

fir wrote:

bart wrote:

On 20/03/2024 14:02, fir wrote:

i know somewhat how it looks like in win32 :

generally the addres space aplication have os from 0x0000 0000 to
0x7fff ffff - which is only 2 gigabytes

(hovever i like it and still prefer writing my windows programs on
win32 than win 64, 2 gigabytes of ram is enough for me)

your program is by default placed at 0x0040 0000 (which is 4MB from
start of adres space)..

That's no longer the case with 64-bit machines, not if you use products
like gcc. This program:

#include "stdio.h"
int main(void) {
printf("%p\n", main);
}

displays 00007ff64a931591 when compiled with gcc. Even on 32-bits using
`gcc -m32`, it shows 0076155c.

at least this is what i know


the stack in turn is betwwwen your app start that +4MB and the
starting point, im not exactly syre but its probably something about
+3M down do +1M approximatelly

stack could be set to bigger in your exe heder your exe has 9may be
modified by -something switch in gcc comandline) and i not tested it
afair (or rather tested but forgot the strict conclusions) but i dont
se nthing specially wrong even in setting this stack to 100 MB

2 MB by default is silly and if you have 10 GB of ram putting 100 MB
for stack is not even a waste becouse if it is not used it only
consumes "logical" ram pages afair but reall ram is not even attached

I don't think using a giant stack just one for the benefit of one
badly-designed function in one library inside a big application is a
good approach.

but you call this function badly designed becouse it can overflow stack

- if it cant it is not badly designed then (unles you say on something
other)

this recursion in fact is not badly designed imo - you only need to be
aware of constraints of data you used it to (and if you care of
constraints of your code you could also somewhat care of constraints on
data)

its suboptimal as to speed but i wouldnt cal it "badly designed"

as i said in another thread the error may be to declare stack size,
it not necessarely need to be declared maybe - then you use stack until
the ram will end - as today people use normal ram, nearly none
application is ready to situatuion that ram ends and heap alocations
fail..so with stack may be tha same

Maybe the routine is never called. Or it's called once then never called >>> again but the stack is now committed.

Your floodfill routine uses 48 bytes per call (with my compiler; it
varies). To floodfill all the pixels in a 3000x4000 pixel image for
example, would need nearly 600MB of stack, and would involve calls
nested 12 million deep.

there was an shortcut in it you dont need to pass the 2 colors in calls
so i think it rather should use int x int y and ret adress it is 12
bytes (on 32 bit, i compile 32 bit only)

i wouldnt say its badly designed but for sure its kinda brute-force
but not in kinds of like cpu and iterations (like counting milion
objects collisions with another milion objets) but more bruteforce in
stack usage - but brute force methods are so nice..they just dont work becouse of big numbers

possibly there may be written a method of thi recolorisation wich uses
50 bytes of ram, but here i wonder if use even 300 Mb of ram for a blink
of an eye time is not standable

i think tge method that not uses ram but is also kinda brute force is
putting a colorislin "fly" that may only move on old color and new color
and just make it random move +-1 min 4 directions - after some time it
should visit all old color area (though it has one bad side effect if
old color borders in new coor it also wil fly thru that and that is an error

but maybe it should spread some unique reserved color and then after
all flying replace all pixels in image of this unique by new color

also could use more flies than one can for example run a thousand of
flies (bot in real random moves do not propagate such fast - so it is
only silly example of bruteforcing or something like that

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

fir wrote:

bart wrote:

Maybe the routine is never called. Or it's called once then never called
again but the stack is now committed.

as far as i know it is not commited..im not 100 procent sure (as it
would probably need to use soem tool that shows that, maybe there are
some) but probably what i think is rught

windows will swap unused pages away from ram and it work in runtime
i mean if you declare 300 MB stack use it once and then for an hour you
use only 2 MB of this the 298 MB of physical ram will nt be "taken"

it is not hard to do it in system i think just as aplication acces ram
thry some table you may monitor once a time which regions are alocated
and non used and "detatch " phisical ram ftom thsi area - then attach it
if there is an acces -0 where this detach and attach is not very slow operation

thats how i see it..i readed something about this but not much and long
time ago

im quite convinced at last that it worx for static arrays so it also
should work for stack ..this is difference process explorer shows as
"private bytes" and "working set"

for example my aplication shows it uses 230 MB of "private bytes"
(this is becouse i used lot of statc arrays for various files in code
that sum up to 230 MB and it shows it uses 3MB of "working set"
- which i understand as real attached physical ram it uses

i hope im not wrong though im not totally sure as i not readed a lot on this

this is also why im not sure if i should use more heap (reallock) based),
more stack, or more static - static should be faster and if the cost os
only that "private bytes" wit show high value im not sure if this is nor erasonable cost (becouse heap based in present c is not so much nice)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)