From Newsgroup: comp.lang.c

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?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On Wed, 01 Jan 2025 15:48:32 +0800, wij wrote:

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

Relevance being?

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

What is 'graphics'?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

wij <wyniijj5@gmail.com> writes:

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.

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?

[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

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

wij <wyniijj5@gmail.com> writes:

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.

  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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 01/01/2025 11:05, wij wrote:

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

wij <wyniijj5@gmail.com> writes:

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.

  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.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On Wed, 2025-01-01 at 12:07 +0000, bart wrote:

On 01/01/2025 11:05, wij wrote:

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

wij <wyniijj5@gmail.com> writes:

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.

   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.

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?

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.

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

??? to my knowledge, in Linux 'everything' is file descriptor.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On Wed, 1 Jan 2025 12:07:07 +0000, bart wrote:

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
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

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

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.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

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

Indeed; cf. https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap03.html#tag_03_141:

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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

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

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

A small non-negative integer value.

Remember, negative integers are smaller than positive ones.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

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

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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 01/01/2025 13:40, wij wrote:

On Wed, 2025-01-01 at 12:07 +0000, bart wrote:

On 01/01/2025 11:05, wij wrote:

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

wij <wyniijj5@gmail.com> writes:

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.

   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.

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?

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.

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

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


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

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.

[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

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.

...

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On Thu, 02 Jan 2025 16:08:57 -0600, BGB wrote:

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

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.

:-)
--
Lew Pitcher
"In Skills We Trust"
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On Thu, 2 Jan 2025 16:08:57 -0600, BGB wrote:

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.

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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 1/2/2025 5:35 PM, Lew Pitcher wrote:

On Thu, 02 Jan 2025 16:08:57 -0600, BGB wrote:

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

[snip]

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.


...

:-)

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 1/2/2025 2:08 PM, BGB wrote:

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.

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

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.

...

--- Synchronet 3.20a-Linux NewsLink 1.114