Re: Can 'graphics' be a file descriptor?

On 1/2/2025 3:06 PM, Keith Thompson wrote:

wij <wyniijj5@gmail.com> writes:

On Wed, 2025-01-01 at 14:33 -0800, Keith Thompson wrote:

wij <wyniijj5@gmail.com> writes:

On Wed, 2025-01-01 at 01:29 -0800, Keith Thompson wrote:

[...]

A file *descriptor* is a small integer referring to some file-like
entity, used with open/close/read/write.  There's no such thing in
standard C; it's a POSIX concept.

[...]

I would like to have opinions about the idea "graphics being a file
descriptor".  The implement is irrevent for the discussion. Some
imagination is required.

>
Why do you insist on referring to "file descriptors"?  That's a specific
term with a specific meaning: a small integer value used in POSIX I/O
(not in standard C).

>
I do not insist anything. I would just like to have an opinion on the idea
"graphics being a file descriptor".

 So you insist on talking about "file descriptors".
 Standard C doesn't have file descriptors.  Consider discussing this in
comp.unix.programmer.
 

It is also kinda moot...
If it were "integer handle" or even "integer value in the same numbering space as file handles", I would be like "yeah, sure, whatever".
POSIX sockets also share the same numbering space, and some of the same calls (Windows sockets do not, and many functions gain an WSA prefix and changes to capitalization and similar).
If one wants it so that read/write/lseek/etc do something useful with them, this is a different matter.
What happens then, does one represent a window as a BMP file or something, which one writes to to update the contents?... This is likely more overhead than is worthwhile.
I guess it could have been a funky alternate reality, say:
   /proc/wm/win_XXXX: Contains window and similar;
   /proc/wm/winstack: Contains the current window stack order
     Say, window numbers in back-to-front order.
     If a window number is absent, corresponding window is minimized.
I guess, say, possible window device layout:
   0000000: WINDOWHEADER (Location, Size, WM status, ...)
   0000400: BITMAPINFOHEADER or similar
     Space for optional/extended headers or palette.
   0001000: Bitmap contents.
But, would it make sense?... Debatable.
Main probable benefit would be to make shared memory easier because "just use mmap" becomes an option.
All this likely also assumes the existence of a mechanism for userland processes/services to map file-interfaces over to procfs or equivalent (well, or put them in "/var/wm" or similar, and assume that they are just mmap'ed files).
Other methods, like sockets or local RPC, still likely make more sense.
...