Question: Whenever I execute a C program, there are 3 standard files, `stdin`, `stdout`, `stderr`. Theses map to `/proc/self/fd/0`, `/proc/self/fd/1`, `/proc/self/fd/2` in Linux, which link to `/dev/pts/0` in my computer. This is pseudo-terminal, to which this process outputs to and takes inputs from.

What is the equivalent of this in Windows? Where do these `stdin`, `stdout`, `stderr` point to, when I execute same program in Windows?

Answer: 
On a Linux kernel, the `stdin`, `stdout` and `stderr` streams have corresponding entries in `/proc`. That `/proc` filesystem is an informational structure which provides visibility into the system; it is not the implementation of these streams.

Firstly, `stdout` is a C concept: an instance of a `FILE *` I/O stream. The operating system kernel (whether it be Linux or Windows) doesn't know anything about this. These streams hold operating system file descriptors/handles. A Linux or Windows program has a `stdout` stream due to being linked to a C library, which may not be true of a program that is not written in C, or a C-based language that uses a C run-time.

A process in an a Unix-like operating system has numbered file descriptors, starting at zero. The first three—0, 1 and 2—are, by convention, input, output and error.

In Microsoft Windows, there is a similar concept. A process has three handles of type `HANDLE` which serve the same purpose. When you create a process using `CreateProcess`, they are specified in the `STARTUPINFO` structure which has these members:

```
HANDLE hStdInput;
HANDLE hStdOutput;
HANDLE hStdError;

```

which are meaningful if the `STARTF_USESTDHANDLES` flag is specified.

Microsoft Windows doesn't have a `/proc` filesystem. It has API-based mechanisms for inspecting various system states. System utilities are written to these API's. For instance, the [Handle](https://learn.microsoft.com/en-us/sysinternals/downloads/handle) program can be used for inspecting what processes have what files open.
A similar application on Linux would traverse `/proc` under the hood.
They don't exist as files on Windows. Even though Windows NT has a object manager in the kernel where named kernel objects exist, the console is not part of it.

At the Win32 layer, those 3 handles are returned by [`GetStdHandle`](https://learn.microsoft.com/en-us/windows/console/getstdhandle). They are special handles and when `WriteFile`/`ReadFile` are called, they check for these special handles and reroutes the request to the console API internally. On the other hand, if a std handle is redirected then the handle can be a real file on disk or a pipe and normal I/O is performed. `CON`, `CONIN$` and `CONOUT$` are special names known by `CreateFile` and provides access to the console screen buffers but this is not exactly the same thing as the handles from `GetStdHandle`.

The C run-time library sits on top of Win32 and provides another level of abstraction. Internally it will have mappings to/from std, FILE\* and the native Win32 HANDLE.