1. On windows, I hear c++ programmers talking about HEAP and STACK. Considering I make a MessageBox program in fasm, on disk it appears like this: the windows stamp("this program can't run in msdos.."), the name and attributes of sections, and the contents of sections. So, when it's loaded in memory, stopping at the entry point, the sp(esp or rsp) register points to the top of the stack. Is that the stack the c++ programmers talk about? What is the HEAP? How much of stack and heap my program can have? Are the c++ programmers refer to the stack only when it comes to subroutines, and not them main program?

2. The above question, but this time for linux (without windows stamp, of course)

3. I have seen some tests ( http://www.masm32.com/board/index.php?topic=64.0 ) on different memory allocation APIs
How come HeapAlloc and GlobalAlloc are faster than VirtualAlloc, if Heap and Global call Virtual themselves (as I've read)?

4. On a multicore CPU (let's say 4), is it possible to start 4 threads and force them only on 2 of the cores? (2 and 2 ; or 3 and 1) ?

5. How can I use the GPU instead of CPU (for a big time consuming calculation)? Fasm example please. Do GPU use other instruction set? Who's putting the GPU to work (the OS or the programmer through a different instruction set or through something else) ? Fasm example please

6. What is "granularity" in terms of VirtualAlloc in comparison with HeapAlloc? A representative picture would be nice

7. Considering the speed of SSD disks, is it better to store big data of your program in a lot of RAM, or make multiple read/write operations on SSD and use little RAM? Besides speed, also consider the destroying of SSD from so many operations

8. In a nutshell, how does the SQL manage to manipulate very big amount of data? In few words, how's the process? Is there something faster?

If you decide to answer the questions, please do and PLEASE don not just send me to google this or that, but explain in short and after that if you think a link would give more concise info, write the link.
Thank you big times!

1. You can declare the maximum stack size at assembly time with the stack directive.

2. Same as 1.

3. You shouldn't really decide which memory API to use based upon its "speed". Those functions have different purposes so the real reason to select one or the other to understand the differences. VirtualAlloc can set the access permissions and you can reserve address space to expand things later. HeapAlloc can't set permissions and expanding the allocation later can be costly. There are other differences also, too many to explain here.

4. You can use SetThreadAffinityMask to limit the CPUs each thread can run on.

6. VirtualAlloc uses the paging mechanism so each allocation is a multiple of the page size (usually 4kB). HeapAlloc can be byte granular, but it depends upon the implementation used.

7. "Better" is subjective. It depends upon the needs of your application.

8. When you ask about SQL I assume you mean the underlying DB. Generally the use of good indexes is a good start to managing large amounts of data.

1. What is HEAP and Stack to c++ coders? Something specific to c compiler? I get confused quickly when I hear a talking in c about stack and heap. Do c++ coders refer to stack only when they have subroutines (ie local variables on stack) ?
I know it's not about fasm, but I can't get an understandable answer from a c++ programmer

Also, please somebody answer no. 5

Heap is something you allocate by calling an API. Stack is something the OS allocates when a thread starts.

As for no 5,
There are examples of gpu programming on this forum. I will point you to one of my examples.
https://board.flatassembler.net/topic.php?t=13293

It has been awhile, but if I recall correctly, this cuda app uses the closest thing to gpu assembly you would want to use.

1/2. So, first of all you should look up what a stack is (as a data structure) and how it's used in Wikipedia. The stack everyone refers to is the call stack, it's used for subroutine calls (as the name suggests) and for local variables. The OS allocates one for each thread in the system.
The heap is NOT in this case the data structure that goes by the same name, but instead it's a system-managed memory pool available to the application; through the API functions offered by the OS, the applcation can allocate and/or deallocate chucks of memory dynamically on it.

6. The standard allocation size granularity for VirtualAlloc is 4k, and the standard allocation address granularity is 64k if no fixed virtual address is specified. HeapAlloc seems to have an unofficial 8 bytes granularity. Anyway these parameters can (and should) be queried using GetSystemInfo.

7. I/O is always slower than RAM access. On the other hand, trying to allocate too much memory could result in memory pages being moved to the page file, which is slow. I'd say it largely depends on the specific problem.