A running program needs memory for different kinds of things: the instructions it will execute, the long-lived variables it keeps around, temporary values while it computes, and so on. Operating systems usually organize a process's memory into multiple regions, where each region has a different purpose and different access permissions (for example: readable, writable, executable).

This region contains the machine instructions of the program (and often the instructions of the libraries it uses). It is typically mapped as readable and executable, but not writable. "Not writable" matters because it prevents accidental or malicious overwriting of the instructions while the program is running.

This region is often shareable across processes: if two processes are running the same executable (or using the same shared library), the OS can map the same physical pages as code for both processes. Each process still sees that memory at its own virtual addresses, but the underlying RAM can be shared to save memory.

This is the region that contains long-lived program data that exists for the whole duration of the process: global variables and static variables. It is commonly split into sub-regions based on mutability (whether the bytes should be allowed to change) and on how the initial values are provided at program start.

Not all global/static variables need explicit bytes stored in the executable file. If a global/static variable is uninitialized, or initialized to zero, the program still expects it to start as all zero bits, but it would be wasteful to store a huge run of zeros in the binary.

That is what the BSS region is for: it represents "zero-initialized data". The executable typically records only the size of this region, and when the program is loaded the kernel/loader ensures that the corresponding memory starts out filled with zeros.

The name BSS is historical: it is often explained as "Block Started by Symbol", which comes from older toolchains and assembly conventions. The important practical point is that BSS affects how much memory the program uses when it runs, but it does not necessarily take the same amount of space inside the executable file.

Sometimes you need memory that survives beyond the function that created it (for example, you build a data structure and return it to the caller). That kind of memory cannot live in a place that is automatically reclaimed when a function returns.

The heap is the part of the process memory used for these "manual lifetime" allocations. Your program asks for a block of N bytes (commonly via malloc), and later explicitly gives it back (via free) when it is no longer needed. In between, that block stays valid even if the function that allocated it already returned.

The stack is the memory a program uses for short-lived data while running functions. When a function starts, it gets some stack space for its local variables and temporary values. When the function returns, that space is automatically reclaimed.

The stack has a fixed maximum size (a limit set by the system and/or runtime). If the program uses too much stack space (for example, a function calling itself too many times, or very large local variables), it can exceed that limit and crash with a stack overflow.

When a process starts, it is given two sets of strings.

Arguments are the command line words you typed after the program name. They describe what this particular run should do (for example: which file to open).

Environment variables are part of the per-process "environment": a set of key/value strings that the OS attaches to a process when it starts. They are one of the main ways the shell passes context into every program you run: where to search for executables (PATH), what your home directory is (HOME), which locale to use (LANG/LC_*), what terminal you’re on (TERM), and a lot of desktop/session plumbing (DISPLAY, XDG_*). They are inherited by default: a process starts with a copy of its parent’s environment, and can add, remove, or change variables for its children.