Configuring SLINK64

The default stack size provided by SLINK64 is currently 32MB. This default can be changed by using the commands stack_size=val or stack=val but some users may prefer the simplicity of having a larger default value.

This stack size is the value that SLINK64 inserts into the PE header (as MasterHeader->OptionalHeader.SizeOfStackReserve) when building your executable or DLL.

A new version of SLINK64 can be downloaded via the link below and this comes with a file called Slink64.ini that is to be placed alongside Slink64.exe in your Silverfrost FTN95 folder. The ini file initially contains a value of 1024 that represents a default stack size of 1GB. Likewise a value of 32 replicates the current default which is the minimum that SLINK64 currently permits. This value can be changed at will. My tests so far seem to show no degradation when an unnecessarily large reserve stack size is used.

If users find this feature to be useful then we could later add a 'config' option to SLINK64 (similar to that in FTN95) that avoids the direct editing of the ini file.

Note that the ini file usually resides in a protected folder so direct editing of the file is normally not possible. Simply edit the file before copying it to your protected folder.

Here is the link... https://www.dropbox.com/s/umxj1h3usdd534y/Slink64.zip?dl=0

Quoted from PaulLaidler My tests so far seem to show no degradation when an unnecessarily large reserve stack size is used.

I am still confused how it works as i always was since 32bit. For example i can compile and run program allocating in stack local array 1.5GB in size with just default stack which was told is only minuscule 32 MB. And what means unnecessary large? Can you provide an example of stack larger than say 3GB?

I will look into this again and aim to give a more complete explanation but it could be a little while before I get back to you on this.

Here is an update regarding the maximum size of the FTN95 stack.

In the announcements for the release of v8.50 of FTN95 it was stated that

The size of the FTN95 stack is effectively no longer limited.

This turns out to be incorrect. The code for this change (within SLINK64) was in place but was not activated at a certain critical point.

We apologise for this oversight and will aim to have this implemented in the next full release. This will allow for a much larger stack size (above the 4GB limit) but the maximum size will still not be unlimited.

A large stack size is (perhaps only) required when using very large local arrays within subroutines.

For those are interested in the details, SLINK64 uses the stack size to set a value within the PE header of the resulting executable and this value is currently implemented correctly. However, SLINK64 also uses this value within some introductory code that it inserts as a prefix before the users code in the executable. It is this part that for the moment remains disabled.

Quoted from John-Silver PE header ?

https://en.wikipedia.org/wiki/Portable_Executable

1. Cool, will see how it works.

2. Interesting to note how smart was done crash handling in OpenGL. When you give it too much work to handle and its stacks are overflowed (large arrays), it may not plot on screen anything, but it DOES NOT crash, i saw only 1-2 cases in 20 years when crash happened. In rare cases when there is no memory left in the system (usual consumer processors have limits, some 32 GB, some 64 and some 128) the screen becomes scary black, freezes for few seconds, and then all recovers in its glory and color. I speculate that this was because many games are written in OpenGL and kids of game developers were bitten at school and also misbehaved with their fathers when their games crashed 😃))) Everyone remembers the times when OS and games were crashing. Everyone hated that. Clearwin should follow this path and do not crash till the last possibility was exhausted.

3. Do FTN95 make portable executables if this what was meant by PE? It always needed additional libraries to run