This is not true of “almost all OS”. The kinds of memory areas represented are fairly typical, but there's no reason why they should be in any particular order, and there can be more than one piece of a given kind.
Under Linux, you can look at a process's address space with
cat /proc/$pid/maps where
$pid is the process ID, e.g.
cat /proc/$$/maps to look at the shell you're running
cat from, or
cat /proc/self/maps to look at the
cat process's own mappings. The command
pmap produces slightly nicer output.
08048000-08054000 r-xp 00000000 08:01 828061 /bin/cat
08054000-08055000 r--p 0000b000 08:01 828061 /bin/cat
08055000-08056000 rw-p 0000c000 08:01 828061 /bin/cat
08c7f000-08ca0000 rw-p 00000000 00:00 0 [heap]
b755a000-b7599000 r--p 00000000 08:01 273200 /usr/lib/locale/en_US.utf8/LC_CTYPE
b7599000-b759a000 rw-p 00000000 00:00 0
b759a000-b76ed000 r-xp 00000000 08:01 269273 /lib/tls/i686/cmov/libc-2.11.1.so
b76ed000-b76ee000 ---p 00153000 08:01 269273 /lib/tls/i686/cmov/libc-2.11.1.so
b76ee000-b76f0000 r--p 00153000 08:01 269273 /lib/tls/i686/cmov/libc-2.11.1.so
b76f0000-b76f1000 rw-p 00155000 08:01 269273 /lib/tls/i686/cmov/libc-2.11.1.so
b76f1000-b76f4000 rw-p 00000000 00:00 0
b770b000-b7712000 r--s 00000000 08:01 271618 /usr/lib/gconv/gconv-modules.cache
b7712000-b7714000 rw-p 00000000 00:00 0
b7714000-b7715000 r-xp 00000000 00:00 0 [vdso]
b7715000-b7730000 r-xp 00000000 08:01 263049 /lib/ld-2.11.1.so
b7730000-b7731000 r--p 0001a000 08:01 263049 /lib/ld-2.11.1.so
b7731000-b7732000 rw-p 0001b000 08:01 263049 /lib/ld-2.11.1.so
bfbec000-bfc01000 rw-p 00000000 00:00 0 [stack]
You can see the code and the read-write data (text and BSS) from the executable, then the heap, then a memory-mapped file, then a little more read-write data, then code, read-only data and read-write data from a shared library (text and BSS again), more read-write data, another shared library (more precisely, the dynamic linker), and finally the sole thread's stack.
Kernel code uses its own address ranges. On many platforms, Linux uses the upper part of the address space for the kernel, often the upper 1GB. Ideally, this space would be enough to map kernel code, kernel data, and the system memory (RAM) and every memory-mapped device. On typical 32-bit PCs of today, this isn't possible, which requires contortions that are only of interest to kernel hackers.
While kernel code is handling a system call, ideally (when the aforementioned contortions are not in place) the process's memory is mapped at the same addresses. This allows processes to pass data to the kernel, and the kernel can read from the pointer directly. It's not a big gain, though, since the pointers need to be validated anyway (so that the process can't trick the kernel into reading from memory that the process isn't supposed to have access to).
The memory zones inside the Linux kernel space are fairly complex. There are several different memory pools, and the main distinctions aren't about where the memory comes from but rather who it's shared with. If you're curious about them, start with LDD3.