Where are stdin, stdout files located in Windows?-CodePudding

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?

CodePudding user response：

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 program can be used for inspecting what processes have what files open. A similar application on Linux would traverse /proc under the hood.

CodePudding user response：

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. 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.

CodePudding user response：

There is no direct equivalent of /dev/stdin and other Unix pseudo files.

You could create a named pipe (CreateNamedPipe) but it isn't exactly identical.

The windows files conIN$ and conOUT$ are similar, but they only read or write to the current window.