Can 'graphics' be a file descriptor?

[wij]

In recent revision of libwy (a C++ library that wraps Clib functions), I feel
the so called 'graphics' can be a file descriptor.

================ q_mand2.cpp
/* Copyright is licensed by GNU LGPL, see file COPYING. by I.J.Wang 2024

Draw image of Mandelbrot set (can zoom-in, one thread, slower)

Build: make q_mand2
*/
#include <Wy.stdio.h>
#include <Wy.complex.h>
#include <CSCall/Face.h>
#include <CSCall/Array2D.h>

using namespace Wy;

//--------- Drawing --------
typedef Face::RGB32_Pixel Pixel;
constexpr Pixel White=Face::RGB32_White;
constexpr Pixel Black=Face::RGB32_Black;
const char GrSvr[]="../face/face"; // see ../face/README

typedef long double MandFType;
constexpr int MaxItrNum=255;

// [Ret] Conversion table from itrnum to Pixel
Array<Pixel> itrnum_pixel() {
Array<Pixel> tab;
for(int n=0; n<=MaxItrNum; ++n) {
// transform $itrnum to approximate temperature color
Pixel pix(Black);
pix[2]= (n&7)<<5;
pix[1]= ((n>>3)&7)<<5;
pix[0]= ((n>>6)&3)<<6;
tab << pix;
}
return tab;
};
const Array<Pixel> ctab( itrnum_pixel() );

constexpr unsigned int Dim=800;
MandFType dist_pd=(4.0/(Dim-1)); // mand distance per dot distance
MandFType mand_lft=-3.0;
MandFType mand_top=2.0;
Array2D<Pixel> mand_img(Dim,Dim);

// [Syn] Draw Mand. image in line range [lbgn,lend)
//
void draw_mand(const Hdr2D<Pixel>& hdr, int lbgn, int lend) {
for(int y=lbgn; y<lend; ++y) {
for(int x=0; x<static_cast<int>(hdr.width()); ++x) {
const Complex<MandFType> c( x*dist_pd +mand_lft, mand_top -y*dist_pd );
const MandFType MaxValue=2.0*abs(c);
Complex<MandFType> z;
int itrnum;
for(itrnum=0; itrnum<MaxItrNum; ++itrnum) {
z=(z*z)+c;
if(abs(z)>MaxValue) {
break;
}
};
hdr.write_point(x,y,ctab[itrnum]);
};
};
};

//--------------- Process mouse events
FifoFile frd,fwr;

class StrmRcvr : public Face::Receiver {
int m_px,m_py;
public:
StrmRcvr() : Face::Receiver() {};
StrmRcvr(RdBuf& strm) : Face::Receiver(strm) {};

Errno cb_headpkt(const char*) override { return Ok; };

Errno cb_MO(Wy::WeeStr mtype, int x, int y, unsigned int butt) override {
Errno r;
if(mtype=="press") {
if(butt&Face::LeftButton) {
m_px=x;
m_py=y;
}
} else if(mtype=="release") {
if(butt&Face::LeftButton) {
int dx,dy; // process the zoom-in box
if(x>=m_px) {
dx=x-m_px;
} else {
dx=m_px;
m_px=x;
x=dx;
dx-=m_px;
}
if(y>=m_py) {
dy=y-m_py;
} else {
dy=m_py;
m_py=y;
y=dy;
dy-=m_py;
}
if((dx<10)||(dy<10)) {
return Ok; // not to zoom-in
}
MandFType mand_rit= mand_lft+x*dist_pd;
MandFType mand_btm= mand_top-y*dist_pd;
mand_lft+= m_px*dist_pd;
mand_top-= m_py*dist_pd;
if(dx>=dy) {
dist_pd= (mand_rit-mand_lft)/Dim;
} else {
dist_pd= (mand_top-mand_btm)/Dim;
}
if(dx>10) {
draw_mand(mand_img.header(),0,mand_img.height()-1);
if((r=Face::put_image(fwr, mand_img.header()))!=Ok) {
WY_THROW(r);
}
}
}
} else {
}
return Ok;
};

Wy::Errno cb_error(Wy::Errno err, int id) override {
cerr << "q_mand2: " << Wy::wrd(err) << ", id=" << id << WY_ENDL;
return err;
};
};

int main(int argc, char *argv[]) try {
Errno r;
ProcessID cpid;

draw_mand(mand_img.header(),0,mand_img.height()-1);

if((r=popen(GrSvr,cpid,frd,fwr))!=Ok) {
WY_THROW(r);
}
if((r=Face::put_image(fwr, mand_img._data(),Dim,Dim))!=Ok) {
WY_THROW(r);
}

RdBuf strm(frd);
StrmRcvr rcvr(strm);
if((r=rcvr.pkt_dispatch())!=Ok) {
WY_THROW(r);
}

WaitStat wstt;
if((r=waitpid(cpid,&wstt,0))!=Ok) {
WY_THROW(r);
}
cout << "Child exit " << wstt.exit_status() << WY_ENDL;

cout << "OK" WY_ENDL;
return 0;
}
catch(const Errno& e) {
cerr << wrd(e) << WY_ENDL;
return -1; // e.c_errno();
}
catch(...) {
cerr << "main() caught(...)" WY_ENDL;
throw;
};

=================== end of q_mand2.cpp

We open 'graphics' with a pathname GrSvr (whatever) and get a file descriptor (fwr
and frd can be the same file descriptor if supported):

if((r=popen(GrSvr,cpid,frd,fwr))!=Ok) {
WY_THROW(r);
}

Then, we write (image or 'command') data to the file descriptor:

if((r=Face::put_image(fwr, mand_img._data(),Dim,Dim))!=Ok) {
WY_THROW(r);
}

(ByteFlow is actually a file descriptor, it is a base class of regular file,
fifo file, socket file character file...)

Perhaps, this is a 'GUI device', so we read GUI events:

RdBuf strm(frd);
StrmRcvr rcvr(strm);
if((r=rcvr.pkt_dispatch())!=Ok) {
WY_THROW(r);
}

Perfect fit! Any idea that 'graphics' be a file descriptor?

[Lawrence D'Oliveiro]

Post by wij
(ByteFlow is actually a file descriptor, it is a base class of regular
file, fifo file, socket file character file...)

Relevance being?

Post by wij
Perfect fit! Any idea that 'graphics' be a file descriptor?

What is 'graphics'?

[Keith Thompson]

Post by wij
In recent revision of libwy (a C++ library that wraps Clib functions), I feel
the so called 'graphics' can be a file descriptor.

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 don't think you're actually working with file descriptors, though it's
hard to tell.

Post by wij
if((r=popen(GrSvr,cpid,frd,fwr))!=Ok) {
WY_THROW(r);
}

popen() is a POSIX function. It takes two arguments, not four.

The code you posted is C++. Why are you posting it to comp.lang.c?

[...]

[wij]

Post by Keith Thompson

Post by wij
In recent revision of libwy (a C++ library that wraps Clib functions), I feel
the so called 'graphics' can be a file descriptor.

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 don't think you're actually working with file descriptors, though it's
hard to tell.

Post by wij
  if((r=popen(GrSvr,cpid,frd,fwr))!=Ok) {
    WY_THROW(r);
  }

popen() is a POSIX function.  It takes two arguments, not four.
The code you posted is C++.  Why are you posting it to comp.lang.c?
[...]

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.

[bart]

Post by wij

Post by Keith Thompson

Post by wij
In recent revision of libwy (a C++ library that wraps Clib functions), I feel
the so called 'graphics' can be a file descriptor.

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 don't think you're actually working with file descriptors, though it's
hard to tell.

Post by wij
  if((r=popen(GrSvr,cpid,frd,fwr))!=Ok) {
    WY_THROW(r);
  }

popen() is a POSIX function.  It takes two arguments, not four.
The code you posted is C++.  Why are you posting it to comp.lang.c?
[...]

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.

You'll need to explain what you mean by `graphics` or `'graphics`. What
is it now? What is it anyway?

Are you refering to the 'handles' that graphics libraries sometimes use
to refer to windows etc? If so what would be the advantages of having
them being file descriptors? Could those advantages be possible in any
other way?

How would it simplify your C++ code?

Some time ago, I had a scripting language where you could write:

print #x, "hello"

With x being either 'con' (the default if omitted), an open file handle,
a string destination, a printer or plotter handle, or the handle to an
image, window or control (button etc).

So this allowed you write text into any of those, via the convenience of
'print' which stringified or serialised many kinds of data, and also
kept track of the current text position.

Is this one of the advantages?

Actually I'm surprised that in Linux, everything isn't already a file
anyway.

[wij]

Post by bart

Post by wij

Post by Keith Thompson

Post by wij
In recent revision of libwy (a C++ library that wraps Clib functions), I feel
the so called 'graphics' can be a file descriptor.

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 don't think you're actually working with file descriptors, though it's
hard to tell.

Post by wij
   if((r=popen(GrSvr,cpid,frd,fwr))!=Ok) {
     WY_THROW(r);
   }

popen() is a POSIX function.  It takes two arguments, not four.
The code you posted is C++.  Why are you posting it to comp.lang.c?
[...]

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.

You'll need to explain what you mean by `graphics` or `'graphics`. What
is it now? What is it anyway?
Are you refering to the 'handles' that graphics libraries sometimes use
to refer to windows etc? If so what would be the advantages of having
them being file descriptors? Could those advantages be possible in any
other way?
How would it simplify your C++ code?

Yes, in MS-Windonw, file descriptor is probably still 'file handle' (as in DOS).
I am mainly referring to Linux (or systems that relies on file descriptor).
The usual graphics library, especially with GUI,... seriously interfere the
the 'normal' program. E.g. you are not expected to have a clean source program
that simply edits a picture file.

Post by bart
    print #x, "hello"
With x being either 'con' (the default if omitted), an open file handle,
a string destination, a printer or plotter handle, or the handle to an
image, window or control (button etc).
So this allowed you write text into any of those, via the convenience of
'print' which stringified or serialised many kinds of data, and also
kept track of the current text position.
Is this one of the advantages?

Yes, looked like what I expect. But file descriptor is a stronger request (or
provision) than library codes. It will simply more and would standardize
'graphics' to some extent enough for 'normal programs' (commercial programs
alway seek breakthrough, you cannot expect to fully standardize it).

Are there any problem doing 'graphics' with your print script? I am mainly
looking for 'clean'/reusabe source code.

Post by bart
Actually I'm surprised that in Linux, everything isn't already a file
anyway.

??? to my knowledge, in Linux 'everything' is file descriptor.

[bart]

Post by wij

Post by bart

Post by wij

Post by Keith Thompson

Post by wij
In recent revision of libwy (a C++ library that wraps Clib functions), I feel
the so called 'graphics' can be a file descriptor.

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 don't think you're actually working with file descriptors, though it's
hard to tell.

Post by wij
   if((r=popen(GrSvr,cpid,frd,fwr))!=Ok) {
     WY_THROW(r);
   }

popen() is a POSIX function.  It takes two arguments, not four.
The code you posted is C++.  Why are you posting it to comp.lang.c?
[...]

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.

You'll need to explain what you mean by `graphics` or `'graphics`. What
is it now? What is it anyway?
Are you refering to the 'handles' that graphics libraries sometimes use
to refer to windows etc? If so what would be the advantages of having
them being file descriptors? Could those advantages be possible in any
other way?
How would it simplify your C++ code?

Yes, in MS-Windonw, file descriptor is probably still 'file handle' (as in DOS).
I am mainly referring to Linux (or systems that relies on file descriptor).
The usual graphics library, especially with GUI,... seriously interfere the
the 'normal' program. E.g. you are not expected to have a clean source program
that simply edits a picture file.

I don't know what that means. But an app that edits text files is going
to be different from one that edits images.

As for a clean program, what you posted was in C++, a language not known
for its clean, simple syntax. You might want to start there.

Post by wij

Post by bart
    print #x, "hello"
With x being either 'con' (the default if omitted), an open file handle,
a string destination, a printer or plotter handle, or the handle to an
image, window or control (button etc).
So this allowed you write text into any of those, via the convenience of
'print' which stringified or serialised many kinds of data, and also
kept track of the current text position.
Is this one of the advantages?

Yes, looked like what I expect. But file descriptor is a stronger request (or
provision) than library codes. It will simply more and would standardize
'graphics' to some extent enough for 'normal programs' (commercial programs
alway seek breakthrough, you cannot expect to fully standardize it).
Are there any problem doing 'graphics' with your print script? I am mainly
looking for 'clean'/reusabe source code.

My 'print #w' was specifically for text. There was a proper API for
actual graphics content within a window, which was both pixel-based and
model-based (using 2D/3D floating point data).

However, in early days, my dialog boxes were little more than text
windows rendered in graphics, and GUI elements were created with text
escape codes via 'print', IIRC. That was nearly 4 decades ago though.

I don't see a use for real graphics using a text or byte stream except
when the connection to the display device is some serial link. But even
then, at the user level I'd expect an API which hides those details:

w := createwindow(....)
draw_rectangle(w, x1, y1, x2, y2)

'w' is a handle; you don't care exactly what it is or how it works.

Post by wij
??? to my knowledge, in Linux 'everything' is file descriptor.

Perhaps I meant that everything can be accessed via a path within the
file system.

[Lawrence D'Oliveiro]

Post by bart
Actually I'm surprised that in Linux, everything isn't already a file
anyway.

There are three separate ideas you will come across in Linux:
* Everything is a file
* Everything is a file descriptor
* Everything is a filesystem

Examples of the first one: Unix sockets, named pipes, device files
Examples of the second one: pidfd, signalfd, timerfd, poll
Examples of the third one: procfs, sysfs, securityfs, cgroup2

[Keith Thompson]

[...]

Post by wij

Post by Keith Thompson
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.

[...]

Post by wij
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).

If you mean FILE* pointers, the discussion might have some relevance to
C. If you really mean POSIX file descriptors, comp.unix.programmer
might be a better place.

Sure, you could have a graphics system where a program interacts with
the display by reading and writing to FILE* pointers. You'd have to
encode the operations and returned data as streams of bytes. I'm not
convinced there would be much advantage.

[Alexis]

Post by Keith Thompson
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).
3.141 File Descriptor
A per-process unique, non-negative integer used to identify an open
file for the purpose of file access. The values 0, 1, and 2 have
special meaning and conventional uses, and are referred to as standard
input, standard output, and standard error, respectively. Programs
usually take their input from standard input, and write output on
standard output. Diagnostic messages are usually written on standard
error. The value of a newly-created file descriptor is from zero to
{OPEN_MAX}-1. A file descriptor can have a value greater than or equal
to {OPEN_MAX} if the value of {OPEN_MAX} has decreased (see sysconf)
since the file descriptor was opened. File descriptors may also be
used to implement message catalog descriptors and directory streams;
see also 3.241 Open File Description.

Alexis.

[Lawrence D'Oliveiro]

... a small integer value used in POSIX I/O ...

A small non-negative integer value.

Remember, negative integers are smaller than positive ones.

[wij]

[...]

Post by wij

Post by Keith Thompson
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.

[...]

Post by wij
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".

If you mean FILE* pointers, the discussion might have some relevance to
C.  If you really mean POSIX file descriptors, comp.unix.programmer
might be a better place.

In one scenario, I can take that as 'the opinion'.

Sure, you could have a graphics system where a program interacts with
the display by reading and writing to FILE* pointers.  You'd have to
encode the operations and returned data as streams of bytes.  I'm not
convinced there would be much advantage.

FILE* is full of 'upgrade' enough not to consider (technically this is only my 
30 year ago opinion. Nowadays, it becomes more complicated, seemingly only
functions to support old software in the name of 'standard'. In the confinement,
you are doomed not going too far, which should not be the goal of 'standard').
With file descriptor, there is at least mmap. The concern might be that 'the
display' may not simply be a range of memory (this is not a strong enough
reason for me). But this may still be fine, we can have option of I/O by read/
write or by mmap. These are hardware things. I had implemented a simple GUI in
DOS (DOS4G) and 3D rendering pipeline based on plain 'frame buffer'. That
experience tell me the idea "graphics being a file descriptor" is plausible
except I don't feel comfortable with this idea after these years. What involved
can be huge (desktop, graphics terminal, matrix, AI, parallel computing), but 
I think from C's point of view (building OS), something to draw image should be
simpler and discussable, at least just opinion should be fine.

[Keith Thompson]

Post by wij

[...]

Post by wij

Post by Keith Thompson
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.

[...]

Post by wij
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.

[...]

[BGB]

Post by Keith Thompson

Post by wij

[...]

Post by wij

Post by Keith Thompson
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.

[...]

Post by wij
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.

...

[Lew Pitcher]

Post by BGB

Post by Keith Thompson

Post by wij

[...]

Post by wij

Post by Keith Thompson
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.

[...]

Post by wij
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 refer you to the X11 specifications and example implementation found at
x.org

X is a networked protocol that performs graphics functions. The network
communications used by X, on Unix and unix-like systems, accesses a socket
(which others have pointed out is, on Unix a "file descriptor"-like object)

Granted, some dislike /how/ X uses network sockets for communication, and X
implementations (for Unixish systems) often provide alternatives such as
"unix domain sockets" and "shared memory" communications. Still, X has found
it "useful" to use these "file descriptor"-like objects to implement
"graphics" facilities.

[snip]

Post by BGB
Other methods, like sockets or local RPC, still likely make more sense.

Oh, I'm glad that the techniques and technologies in use for over 30 years
gain your (apparently grudging) approval.

:-)

[BGB]

Post by Lew Pitcher

Post by BGB

Post by Keith Thompson

Post by wij

[...]

Post by wij

Post by Keith Thompson
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.

[...]

Post by wij
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 refer you to the X11 specifications and example implementation found at
x.org
X is a networked protocol that performs graphics functions. The network
communications used by X, on Unix and unix-like systems, accesses a socket
(which others have pointed out is, on Unix a "file descriptor"-like object)
Granted, some dislike /how/ X uses network sockets for communication, and X
implementations (for Unixish systems) often provide alternatives such as
"unix domain sockets" and "shared memory" communications. Still, X has found
it "useful" to use these "file descriptor"-like objects to implement
"graphics" facilities.

Yeah, I already have a general idea how X works though...

The question there was more meant in the sense of, "What, exactly, is
the OP expecting here?...".

Then giving one example of a possible interpretation of "How might the
OP's question be turned into something that actually makes sense?...".

Post by Lew Pitcher
[snip]

Post by BGB
Other methods, like sockets or local RPC, still likely make more sense.

Oh, I'm glad that the techniques and technologies in use for over 30 years
gain your (apparently grudging) approval.

You misunderstand, I was not personally in favor of doing GUI via the
filesystem, and in fact think doing so is probably a bad idea.

But, was more entertaining the OP's idea in a hypothetical sense (eg: In
the form of "What if the OS window management were mapped to the
filesystem?"; well, as opposed to something like Unix sockets).




In my own makeshift OS, I mostly did it instead via a sort of local RPC
mechanism (interprocess RPC via a COM-like interface routed over the
system-call mechanism).

Client process invokes a method, which invokes a system call, which is
bounced over to the server task.

The server task basically exists in a thread that spins in an infinite
loop trying to accept calls, process the requests, and passing control
back to the caller (it then goes back to sleeping until another method
call arrives).


Sockets would have been another possible option, but would have a
latency that was at the whim of the OS scheduler.

Granted, it is possible that latency could be reduced on sockets if the
caller writes to the socket and then immediately calls "usleep();" or
similar, and if the OS has a mechanism to see that something was written
to the socket and then immediately wake up any task that was waiting for
input on that socket (say, via "poll()").

Well, as opposed to a "poll()" mechanism where it gets around to the
task, sees that it is still waiting on IO, and leaves it sleeping.
Granted, practical difference may not matter much if the system is
mostly idle. But, latency would be negatively effected in this case if
one has multiple running tasks which are effectively "eating the CPU".

But, for direct task-to-task control transfers, request/latency is not
as significantly effected by the existence of "CPU eater" processes, ...


Decided to leave out going into the whole thing of process scheduling
and trying to maintain semi-correct event timing (say, if one has
processes that are supposed to wake/run at specific times; and it is
"generally kinda bad" if the OS scheduler fails to wake the process when
it was scheduled to be woken up, *).

*: Say, for updating step/direction pins on a stepper driver or updates
for 1-2ms Servo-PWM pulses, ... Where the hardware may misbehave if
these signals are not updated at the correct times.


...

Post by Lew Pitcher
:-)

[Lawrence D'Oliveiro]

Post by BGB
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).

That’s a limitation of Windows. For example, POSIX systems allow select/
poll on any file descriptor, Windows does not.

Post by BGB
What happens then, does one represent a window as a BMP file or
something, which one writes to to update the contents?...

The old X11 protocol used a socket as its primary communication channel.
To this was soon added a shared-memory extension, for more rapid
information transfer when both client and server were on the same machine.

Wayland does something similar.

[Chris M. Thomasson]

Post by BGB

Post by Keith Thompson

Post by wij

[...]

Post by wij

Post by Keith Thompson
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.

[...]

Post by wij
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.

Think of creating a gui in a GLSL shader. Each pixel is run through the
fragment shader... ;^)

Post by BGB
  /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.
  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.
...