[SOLVED] receive window properties by child of child

[CorruptedByCPU]

Hello!

First, I will present a small description of the console window in the Cyjon system.

1. The user starts the process named "console", this process creates a window of a defined size in pixels and becomes its owner, the process has its own IO data stream.
2. "console" starts the next process called "shell" and becomes its parent, the output of the "shell" process is connected to the "console" input stream, so everything that is sent to the output - "console" automatically receives and displays in his own window
3.all programs started through "shell" inherit the output stream from "shell", so I know that everything will go to the input stream of "console"

"shell" can ask the parent for the width and height of the window in characters ... and everything is fine

I have a problem when the "shell" starts its own process, e.g. the "hello" program,

I don't know how "hello" is supposed to get information about the window size, if its parent is "shell" and it doesn't know which process owns the window

Should the "shell" process forward queries about the window properties to its parent? and then send them back to the descendants?

Or maybe every child process of the "console" program should receive information about what window it is running in? or who owns it ...

[klange]

Unless you're going for a system where graphical applications run nested within each other, the idea of passing information about a window owned by a parent process to its children doesn't make much sense. Terminal emulators are a bit of a special case, and in POSIX this is where some of the extended functionality of a "PTY" comes into play. The terminal emulator uses a special ioctl call on the pty to assign a size to it. Traditionally, this is just height and width in characters, but many modern systems also add information about the size in pixels (which can be useful if you implement a graphic output escape code system, such as Sixel). Any child process that has a file descriptor for the pty can then request the size of the terminal through another ioctl call. It doesn't matter that your "hello" is a child of the "shell" because it has a direct reference to the terminal "object" that contains information on its size.

[nullplan]

Normal (i.e. UNIX) solution for this is to associate window size with I/O stream. That way, anyone who can access the I/O stream can read the window size. In Linux, there is a window size structure that is associated with all terminals, be they serial, virtual, or pseudo. In your case, the console window would create a pseudo terminal and tell it how big the window is (by using an ioctl() to specify the window size), and then shell or hello or whatever can ask the stream for its window size. Now, in theory, malicious programs could set a new window size, but in practice that rarely ever happens, is usually not an issue, and the terminal emulator can detect it and change it back.

Other possibility, also used in many systems, is to set a WINDOWID environment variable. That gets inherited to anything in that part of the process tree, and any program that is interested can contact the window system and ask it how large the given window is.

[CorruptedByCPU]

[...] Any child process that has a file descriptor for the pty can then request the size of the terminal [...] It doesn't matter that your "hello" is a child of the "shell" because it has a direct reference to the terminal "object" that contains information on its size.

[...] solution for this is to associate window size with I/O stream. That way, anyone who can access the I/O stream can read the window size [...] console window would create a pseudo terminal and tell it how big the window is [...]

Thanks a lot

It made me to think that the pointer to the standard input of the "console" program could be a stream - which links to a character device in eg. /dev/console{PID}
and this device will have the properties of the window (and content) created by the console

I completely forgot about the character devices in /dev (I haven't finished the implementation)