https://www.youtube.com/watch?v=XAzUoizwnXM
i dint watched it whole but it comes to my mind that those socket communication indeed should be probably made using fopen/fread/fwrite/fgetc/fputc
i was doing only basics of socket programming anver liked it and
remember almost nothing - it is becouse i dont liek stupid things
and those sockets looks stupid
i guess using this fopen it would be much better..
whot would you need i assume you need to fopen connection to distant machine..not sure if it should be one the same for read write or two
one for read and one for write..then i think the network card should
have buffer whete there is stacked incoming data, same for outcoming
data,a nd thats all as to basics probably..no hanging controll no
additional threads..just like working with files
whough additional soft could be written too, based on thai but it should
be sane thing something based like with working with files (knowing
those files are ram files and are contents of incoming and outcoming buffer
thise sockets todajy i dont remember but in my vague mameory it feels
like shit
feel free to comment on this topic if you want
fir pisze:
https://www.youtube.com/watch?v=XAzUoizwnXMmaybe someone who has some experience with socked programming know how
i dint watched it whole but it comes to my mind that those socket
communication indeed should be probably made using
fopen/fread/fwrite/fgetc/fputc
i was doing only basics of socket programming anver liked it and
remember almost nothing - it is becouse i dont liek stupid things
and those sockets looks stupid
i guess using this fopen it would be much better..
whot would you need i assume you need to fopen connection to distant
machine..not sure if it should be one the same for read write or two
one for read and one for write..then i think the network card should
have buffer whete there is stacked incoming data, same for outcoming
data,a nd thats all as to basics probably..no hanging controll no
additional threads..just like working with files
whough additional soft could be written too, based on thai but it
should be sane thing something based like with working with files
(knowing those files are ram files and are contents of incoming and
outcoming buffer
thise sockets todajy i dont remember but in my vague mameory it feels
like shit
feel free to comment on this topic if you want
the basic communication would look like using this fopen scheme
main()
{
˙˙ FILE* f = fopen("1.2.3.4:555");
˙ fprintf(f, "hello there\n"); fflush(f);
˙ for(int i=0; i<100; i++)
˙ {
˙˙˙ static char buf[4096];
˙˙˙ if(fgets(buf, sizeof(buf), f))
˙˙˙˙˙˙ printf("incoming: %s", buf);
˙˙˙ Sleep(100); //wait 100 ms
˙ }
}
something like that?
i dint watched it whole but it comes to my mind that those socket communication indeed should be probably made using fopen/fread/fwrite/fgetc/fputc
Sleep(100); //wait 100 ms
On Mon, 8 Jun 2026 18:16:10 +0200, fir wrote:
Sleep(100); //wait 100 ms
That?s usually a dumb thing to do. It?s either too slow if something
comes in/goes out more quickly, or too much overhead if communication
is slower than that. And it just gets worse if you?re trying to juggle multiple connections (as a server commonly does).
Try using this <https://manpages.debian.org/poll(2)>, at least ...
Lawrence D?Oliveiro pisze:
On Mon, 8 Jun 2026 18:16:10 +0200, fir wrote:
˙˙˙˙˙ Sleep(100); //wait 100 ms
That?s usually a dumb thing to do. It?s either too slow if something
comes in/goes out more quickly, or too much overhead if communication
is slower than that. And it just gets worse if you?re trying to juggle
multiple connections (as a server commonly does).
Try using this <https://manpages.debian.org/poll(2)>, at least ...
i will answer more mabe later coz i had some health crisis and if i do i cant cofus
but the topic is sorta interesting to me possibly worth getting in few
hours or days
as to "this is domb thing" i dont think so - this topic is about architectural simplicity against winsock mess and this is nice
architectural simplicity
you know what sleep() function is its extremally often used basic
windows function which sleeps main thread for n miliseconds, every
or nearly every (afait) windows app uses it so its totally notmall
˙i dont know and i would need to check it but as far as i understood
network card recives incoming data and stores it in its own buffer
(its (afait) outside of cpu work, and buffer has some size so maybe if
you put this sleep as 1 mmilisecond that the buffer of network card
will not be overfloved... how todays ntwork speeds are - it is more than
say i GB/s? with 1 ms sleep the incoming data would be 1 MB at this
speed so its not too much
ofc thw application do other things than only waiting, it also my update frame time (10 -20 ms)˙ but still that simple scenario could work imo
interesting thing is hovevevr if this network card has its own ram how
its stores t in more detail (which i dont know) but logically it is
probably some ram buffer which may be indeed treated as an open file
and read by fgets/fread etc
you know what sleep() function is its extremally often used basic
windows function which sleeps main thread for n miliseconds, every
or nearly every (afait) windows app uses it so its totally notmall
On Tue, 9 Jun 2026 08:56:00 +0200, fir wrote:
you know what sleep() function is its extremally often used basic
windows function which sleeps main thread for n miliseconds, every
or nearly every (afait) windows app uses it so its totally notmall
Maybe normal in Windows, but in regular multitasking OSes, we have
these standard techniques for maximizing responsiveness while
minimizing resource usage. Which is why systems like Linux can scale gracefully to tens or even hundreds of thousands of simultaneous peer connections.
On Tue, 9 Jun 2026 08:56:00 +0200, fir wrote:
you know what sleep() function is its extremally often used basic
windows function which sleeps main thread for n miliseconds, every
or nearly every (afait) windows app uses it so its totally notmall
Maybe normal in Windows, but in regular multitasking OSes, we have
these standard techniques for maximizing responsiveness while
minimizing resource usage. Which is why systems like Linux can scale gracefully to tens or even hundreds of thousands of simultaneous peer connections.
On Tue, 6/9/2026 5:10 AM, Lawrence D?Oliveiro wrote:
On Tue, 9 Jun 2026 08:56:00 +0200, fir wrote:
you know what sleep() function is its extremally often used basic
windows function which sleeps main thread for n miliseconds, every
or nearly every (afait) windows app uses it so its totally notmall
Maybe normal in Windows, but in regular multitasking OSes, we have
these standard techniques for maximizing responsiveness while
minimizing resource usage. Which is why systems like Linux can scale
gracefully to tens or even hundreds of thousands of simultaneous peer
connections.
This isn't particularly a good place to get Windows internals details.
You can use Sysinternals Process Explorer, run it as administrator,
and it has a tick counter for processes, such that you can "measure"
how many CPU clock cycles are used per update of the PE readout.
Most of the svchost, for example, DON'T USE ANY CYCLES AT ALL.
A select few svchost are cycle-pigs, and during Windows Update for example, you can see one of the svchost is railed. Which is to be expected.
It's very busy. it has a thousand packages to evaluate.
I have a power meter on the machine (on the AC plug). I will
now measure Windows desktop idle power, then boot some Linux
and compare. Windows is on a 4TB SSD. The four Linux share a 1TB SSD,
making the test a bit easier to run.
(All DEs set to the same screen resolution)
Windows 11 Home - 1920x1080 33.9W Idle
LMDE7 (cinnamon DE) 40.3W Idle
Linux Mint 223 Mate 45.7W Idle
Linux Mint 223 XFCE 46.4W Idle
Devuan 6 (cinnamon DE w.Nvidia) 34.7W Idle
Only Devuan 6 with the non-systemd init system and running X11, comes close to Windows 11.
Paul
Lawrence D?Oliveiro pisze:
On Tue, 9 Jun 2026 08:56:00 +0200, fir wrote:this standard techniques are not necesarelly much good imo...ans sleep
you know what sleep() function is its extremally often used basic
windows function which sleeps main thread for n miliseconds, every
or nearly every (afait) windows app uses it so its totally notmall
Maybe normal in Windows, but in regular multitasking OSes, we have
these standard techniques for maximizing responsiveness while
minimizing resource usage. Which is why systems like Linux can scale
gracefully to tens or even hundreds of thousands of simultaneous peer
connections.
is architecturally simple and not bad imo
this is also not inneficient - its efficient as it returns power to
system (somore app uses sleep more lightweight it is i would say)
On 09/06/2026 11:34, fir wrote:
Lawrence D?Oliveiro pisze:
On Tue, 9 Jun 2026 08:56:00 +0200, fir wrote:this standard techniques are not necesarelly much good imo...ans sleep
you know what sleep() function is its extremally often used basic
windows function which sleeps main thread for n miliseconds, every
or nearly every (afait) windows app uses it so its totally notmall
Maybe normal in Windows, but in regular multitasking OSes, we have
these standard techniques for maximizing responsiveness while
minimizing resource usage. Which is why systems like Linux can scale
gracefully to tens or even hundreds of thousands of simultaneous peer
connections.
is architecturally simple and not bad imo
this is also not inneficient - its efficient as it returns power to
system (somore app uses sleep more lightweight it is i would say)
Yes.˙ A simple loop with sleep and then checking for new input is not scalable when you are doing lots of them at once, such as for a web
server.˙ But it is perfectly good for small, simple systems or during testing and developing, and saves a lot of effort compared to using
poll(), select(), or other such solutions.˙ It usually doesn't matter if
the extra wakeups and checks use a couple of percent of cpu time.˙ (It
does matter, of course, when you have hundreds or thousands of such
loops on a server.)
David Brown pisze:
On 09/06/2026 11:34, fir wrote:
Lawrence D?Oliveiro pisze:
On Tue, 9 Jun 2026 08:56:00 +0200, fir wrote:this standard techniques are not necesarelly much good imo...ans
you know what sleep() function is its extremally often used basic
windows function which sleeps main thread for n miliseconds, every
or nearly every (afait) windows app uses it so its totally notmall
Maybe normal in Windows, but in regular multitasking OSes, we have
these standard techniques for maximizing responsiveness while
minimizing resource usage. Which is why systems like Linux can scale
gracefully to tens or even hundreds of thousands of simultaneous peer
connections.
sleep is architecturally simple and not bad imo
this is also not inneficient - its efficient as it returns power to
system (somore app uses sleep more lightweight it is i would say)
Yes.˙ A simple loop with sleep and then checking for new input is not
scalable when you are doing lots of them at once, such as for a web
server.˙ But it is perfectly good for small, simple systems or during
testing and developing, and saves a lot of effort compared to using
poll(), select(), or other such solutions.˙ It usually doesn't matter
if the extra wakeups and checks use a couple of percent of cpu time.
(It does matter, of course, when you have hundreds or thousands of
such loops on a server.)
im not thinkin on the server..i am talking on most simple architecture
for reading/writing data via network especially one that can be build
arounf fopen/fclose and those functions used to read write to files
at least tcp conection seen can be totally done like that fopen(
connection) fgets, fputs, fclose() though loop and sleep also need to be invvolved
fir pisze:
David Brown pisze:as to servers though i dont think the situation would be quite different
On 09/06/2026 11:34, fir wrote:
Lawrence D?Oliveiro pisze:
On Tue, 9 Jun 2026 08:56:00 +0200, fir wrote:this standard techniques are not necesarelly much good imo...ans
you know what sleep() function is its extremally often used basic
windows function which sleeps main thread for n miliseconds, every >>>>>> or nearly every (afait) windows app uses it so its totally notmall
Maybe normal in Windows, but in regular multitasking OSes, we have
these standard techniques for maximizing responsiveness while
minimizing resource usage. Which is why systems like Linux can scale >>>>> gracefully to tens or even hundreds of thousands of simultaneous peer >>>>> connections.
sleep is architecturally simple and not bad imo
this is also not inneficient - its efficient as it returns power to
system (somore app uses sleep more lightweight it is i would say)
Yes.˙ A simple loop with sleep and then checking for new input is not
scalable when you are doing lots of them at once, such as for a web
server.˙ But it is perfectly good for small, simple systems or during
testing and developing, and saves a lot of effort compared to using
poll(), select(), or other such solutions.˙ It usually doesn't matter
if the extra wakeups and checks use a couple of percent of cpu time.
(It does matter, of course, when you have hundreds or thousands of
such loops on a server.)
im not thinkin on the server..i am talking on most simple architecture
for reading/writing data via network especially one that can be build
arounf fopen/fclose and those functions used to read write to files
at least tcp conection seen can be totally done like that fopen(
connection) fgets, fputs, fclose() though loop and sleep also need to
be invvolved
you got
˙for(;;)
˙{
˙˙˙˙ fread(..., f);
˙˙˙˙ //do something
˙˙˙˙ fwrite(..., f);
˙˙˙˙ sleep(1);
˙}
when you got many conections there is no more loops and sleeps just more
f's in a loop
and as server has its limit it must be some entry compter that
redirects connections to servers if you have hundreds of them
no? so it seems not much more complex
i must rethink hovever how exactly it would look like when two
computers who communicates (and which are like working
in 50-100 fps mode indeed communicate (but maybe i will do it later)
On Mon, 8 Jun 2026 18:16:10 +0200, fir wrote:
Sleep(100); //wait 100 ms
That?s usually a dumb thing to do. It?s either too slow if something
comes in/goes out more quickly, or too much overhead if communication
is slower than that. And it just gets worse if you?re trying to juggle multiple connections (as a server commonly does).
Try using this <https://manpages.debian.org/poll(2)>, at least ...
On Tue, 9 Jun 2026 08:56:00 +0200, fir wrote:
you know what sleep() function is its extremally often used basic
windows function which sleeps main thread for n miliseconds, every
or nearly every (afait) windows app uses it so its totally notmall
Maybe normal in Windows, but in regular multitasking OSes, we have
these standard techniques for maximizing responsiveness while
minimizing resource usage. Which is why systems like Linux can scale gracefully to tens or even hundreds of thousands of simultaneous peer connections.
https://www.youtube.com/watch?v=XAzUoizwnXM
i dint watched it whole but it comes to my mind that those socket communication indeed should be probably made using fopen/fread/fwrite/fgetc/fputc
i was doing only basics of socket programming anver liked it and
remember almost nothing - it is becouse i dont liek stupid things
and those sockets looks stupid
i guess using this fopen it would be much better..
A select few svchost are cycle-pigs, and during Windows Update for
example, you can see one of the svchost is railed. Which is to be
expected. It's very busy. it has a thousand packages to evaluate.
ir_uring? ;^)
On 6/9/2026 2:10 AM, Lawrence D?Oliveiro wrote:
... in regular multitasking OSes, we have these standard techniques
for maximizing responsiveness while minimizing resource usage.
Which is why systems like Linux can scale gracefully to tens or
even hundreds of thousands of simultaneous peer connections.
Well, for servers/clients in windows, IOCP is key.
Lawrence D?Oliveiro pisze:
this standard techniques are not necesarelly much good imo...ans
On Tue, 9 Jun 2026 08:56:00 +0200, fir wrote:
you know what sleep() function is its extremally often used basic
windows function which sleeps main thread for n miliseconds, every
or nearly every (afait) windows app uses it so its totally notmall
Maybe normal in Windows, but in regular multitasking OSes, we have
these standard techniques for maximizing responsiveness while
minimizing resource usage. Which is why systems like Linux can
scale gracefully to tens or even hundreds of thousands of
simultaneous peer connections.
sleep is architecturally simple and not bad imo
this is also not inneficient - its efficient as it returns power to
system (somore app uses sleep more lightweight it is i would say)
sad nevs ai says that TCP not guarantees that whole pack would be
received and it can be only part... so it complicates code using it
a bit
On Tue, 9 Jun 2026 13:54:51 -0700, Chris M. Thomasson wrote:
ir_uring? ;^)
io_uring, you mean?
That, too, is a possibility, for even higher performance.
<https://manpages.debian.org/io_uring(7)>
On Tue, 9 Jun 2026 13:55:25 -0700, Chris M. Thomasson wrote:
On 6/9/2026 2:10 AM, Lawrence D?Oliveiro wrote:
... in regular multitasking OSes, we have these standard techniques
for maximizing responsiveness while minimizing resource usage.
Which is why systems like Linux can scale gracefully to tens or
even hundreds of thousands of simultaneous peer connections.
Well, for servers/clients in windows, IOCP is key.
IOCP is based on the asynchronous I/O model from DEC?s old VMS
operating system, which Dave Cutler also masterminded before moving to Microsoft to create Windows NT.
Nobody else seems to have thought it a worthwhile enough model to
copy, though. I think it requires you to have multiple I/O requests in flight, one for each connection you want to watch. This might make for
a more complicated programming model, as opposed to the simplicity of poll(2)/epoll(2).
The most critical known test of Windows Server performance was
probably the London Stock Exchange fiasco. After crowing about winning
the contract ahead of Linux-based competitors, Microsoft had to eat
humble pie after the whole setup fell flat on its face.
And was replaced with a Linux-based alternative.
IOCP is the way to go on Windows. Fwiw, I used it quite a bit around 25+ years ago back on Windows NT 4.0 Then GQCSEX came out:
https://learn.microsoft.com/en-us/windows/win32/fileio/ getqueuedcompletionstatusex-func
That is a fun one that returns more than one completion request.
However, you have to know how to use it correctly! For instance, I would gather the io completions and sort them as usually wsasends, wsarecvs, acceptex, connectex, ect into separate per thread stacks. Then execute
them in batches sometimes on another thread pool. I remember an old
paper, cohort scheduling.
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/ tr-2001-39.pdf?msockid=156c5513e5e96cdb283d4228e46a6db8
The io worker threads should run full steam ahead and not necessarily do
any user processing. They should only block when there is no io to do at all.
struct cohort
{
˙˙˙ per_io* m_recv;
˙˙˙ per_io* m_send;
˙˙˙ per_io* m_accept;
˙˙˙ per_io* m_connect;
˙˙˙ //...
};
Just heads for single linked lists of per io data wrt WSAOVERLAPPED.
Pass execute the cohort usually in another thread pool.
On Tue, 9 Jun 2026 13:54:51 -0700, Chris M. Thomasson wrote:
ir_uring? ;^)
io_uring, you mean?
That, too, is a possibility, for even higher performance.
<https://manpages.debian.org/io_uring(7)>
IOCP is the way to go on Windows.
On 6/9/2026 4:47 PM, Lawrence D?Oliveiro wrote:
That, too, is a possibility, for even higher performance.
<https://manpages.debian.org/io_uring(7)>
Oh I think so.
I just remembered some of the "fun" functions for IOCP on Windows. TransmitPackets and TransmitFile.
https://learn.microsoft.com/en-us/windows/win32/api/mswsock/nc-mswsock-lpfn_transmitpackets
Petty cool, except iirc the client versions of nt 4.0 nerfed them to
only two concurrent in flight calls at a time.
AcceptEx and ConnectEx were pretty cool as well.
https://learn.microsoft.com/en-us/windows/win32/api/mswsock/nf-mswsock-acceptex
https://learn.microsoft.com/en-us/windows/win32/api/mswsock/nc-mswsock-lpfn_connectex
On Tue, 9 Jun 2026 13:53:28 +0200, fir wrote:
sad nevs ai says that TCP not guarantees that whole pack would be
received and it can be only part... so it complicates code using it
a bit
Why? Surely you would not try to handle an incoming request or
response until you were sure you had received the whole thing,
wouldn?t you?
On Tue, 9 Jun 2026 11:34:36 +0200, fir wrote:
Lawrence D?Oliveiro pisze:
this standard techniques are not necesarelly much good imo...ans
On Tue, 9 Jun 2026 08:56:00 +0200, fir wrote:
you know what sleep() function is its extremally often used basic
windows function which sleeps main thread for n miliseconds, every
or nearly every (afait) windows app uses it so its totally notmall
Maybe normal in Windows, but in regular multitasking OSes, we have
these standard techniques for maximizing responsiveness while
minimizing resource usage. Which is why systems like Linux can
scale gracefully to tens or even hundreds of thousands of
simultaneous peer connections.
sleep is architecturally simple and not bad imo
You keep saying that, even after I point out why it?s a bad idea.
this is also not inneficient - its efficient as it returns power to
system (somore app uses sleep more lightweight it is i would say)
Think of how you could do enough peak throughput to saturate a gigabit Ethernet link. This is at the low end of network connection speeds
these days -- higher-performance configurations might have an order of magnitude or two greater bandwidth.
To manage it, you?d need to push through about 120 megabytes per
second. With your sleep-every-100ms poll, this means each I/O request
would need a buffer size of about 12 megabytes. This is ridiculously
large. And of course the 100ms latency would be unacceptable for many
uses -- think of a multiuser game server, for example.
On Tue, 9 Jun 2026 21:42:58 -0700, Chris M. Thomasson wrote:
On 6/9/2026 4:47 PM, Lawrence D?Oliveiro wrote:
That, too, is a possibility, for even higher performance.
<https://manpages.debian.org/io_uring(7)>
Oh I think so.
I think more suited for block-device (disk/SSD) I/O, rather than
network I/O. Most network I/O (say, up to a few gigabits per second)
would most likely hit a bottleneck in the physical network interface,
rather than in the rate at which the userland code can produce/consume
the data.
Also, this: <https://manpages.debian.org/aio(7)> -- an actual POSIX
spec, not Linux-specific, perhaps not having the best performance ...
On Tue, 9 Jun 2026 21:52:39 -0700, Chris M. Thomasson wrote:
IOCP is the way to go on Windows.I think one reason why it?s never been adopted cross-platform is that
it requires threading to be useful. Whereas the *nix poll(2) technique
is scalable across single-threaded and multi-threaded usage.
Microsoft needs to fix its I/O handling to be more friendly to
*nix-style ways of doing things. Otherwise the Windows-specific gaps
listed on this sort of thing
<https://docs.python.org/3/library/select.html> just look
embarrassing.
On 6/9/2026 11:21 PM, Lawrence D?Oliveiro wrote:
On Tue, 9 Jun 2026 21:42:58 -0700, Chris M. Thomasson wrote:
On 6/9/2026 4:47 PM, Lawrence D?Oliveiro wrote:
That, too, is a possibility, for even higher performance.
<https://manpages.debian.org/io_uring(7)>
Oh I think so.
I think more suited for block-device (disk/SSD) I/O, rather than
network I/O. Most network I/O (say, up to a few gigabits per second)
would most likely hit a bottleneck in the physical network interface,
rather than in the rate at which the userland code can produce/consume
the data.
Also, this: <https://manpages.debian.org/aio(7)> -- an actual POSIX
spec, not Linux-specific, perhaps not having the best performance ...
io_uring should work fine for network I/O. io_uring?s benefits only
appear at extreme scale?
Lawrence D?Oliveiro pisze:
On Tue, 9 Jun 2026 11:34:36 +0200, fir wrote:this 100 ms was an example not more meaning than using "foo" name if you
Lawrence D?Oliveiro pisze:
this standard techniques are not necesarelly much good imo...ans
On Tue, 9 Jun 2026 08:56:00 +0200, fir wrote:
you know what sleep() function is its extremally often used basic
windows function which sleeps main thread for n miliseconds, every
or nearly every (afait) windows app uses it so its totally notmall
Maybe normal in Windows, but in regular multitasking OSes, we have
these standard techniques for maximizing responsiveness while
minimizing resource usage. Which is why systems like Linux can
scale gracefully to tens or even hundreds of thousands of
simultaneous peer connections.
sleep is architecturally simple and not bad imo
You keep saying that, even after I point out why it?s a bad idea.
this is also not inneficient - its efficient as it returns power to
system (somore app uses sleep more lightweight it is i would say)
Think of how you could do enough peak throughput to saturate a gigabit
Ethernet link. This is at the low end of network connection speeds
these days -- higher-performance configurations might have an order of
magnitude or two greater bandwidth.
To manage it, you?d need to push through about 120 megabytes per
second. With your sleep-every-100ms poll, this means each I/O request
would need a buffer size of about 12 megabytes. This is ridiculously
large. And of course the 100ms latency would be unacceptable for many
uses -- think of a multiuser game server, for example.
can change "foo" into "boo" then you can turn 100 ms into 0.1 ms
i hope youre not think i would put 100 ms in a situation when you need 1
ms or 0.1 ms...if you think so yure exceptionally vrong
this polling in active loop is generally good becouse it is so simple it
nt rises complications..you dont need additionsl thread, you dont hang
on input etc.. note also polling is very almost extremally cheep
becouse if˙ you do some check then rise sleep
for(;;)
{
if(someting_here) {}
sleep(0.1)
}
then loop and if takes few cycles, where sleep 0.1 ms takes about 300
000 cycles (switching cpu off to another route tales also some) so the
cost is microscopic... i dont think alternative methods are faster
On 6/10/2026 12:06 AM, fir wrote:
Lawrence D?Oliveiro pisze:
On Tue, 9 Jun 2026 11:34:36 +0200, fir wrote:this 100 ms was an example not more meaning than using "foo" name if
Lawrence D?Oliveiro pisze:
this standard techniques are not necesarelly much good imo...ans
On Tue, 9 Jun 2026 08:56:00 +0200, fir wrote:
you know what sleep() function is its extremally often used basic
windows function which sleeps main thread for n miliseconds, every >>>>>> or nearly every (afait) windows app uses it so its totally notmall
Maybe normal in Windows, but in regular multitasking OSes, we have
these standard techniques for maximizing responsiveness while
minimizing resource usage. Which is why systems like Linux can
scale gracefully to tens or even hundreds of thousands of
simultaneous peer connections.
sleep is architecturally simple and not bad imo
You keep saying that, even after I point out why it?s a bad idea.
this is also not inneficient - its efficient as it returns power to
system (somore app uses sleep more lightweight it is i would say)
Think of how you could do enough peak throughput to saturate a gigabit
Ethernet link. This is at the low end of network connection speeds
these days -- higher-performance configurations might have an order of
magnitude or two greater bandwidth.
To manage it, you?d need to push through about 120 megabytes per
second. With your sleep-every-100ms poll, this means each I/O request
would need a buffer size of about 12 megabytes. This is ridiculously
large. And of course the 100ms latency would be unacceptable for many
uses -- think of a multiuser game server, for example.
you can change "foo" into "boo" then you can turn 100 ms into 0.1 ms
i hope youre not think i would put 100 ms in a situation when you need
1 ms or 0.1 ms...if you think so yure exceptionally vrong
this polling in active loop is generally good becouse it is so simple
it nt rises complications..you dont need additionsl thread, you dont hang
on input etc.. note also polling is very almost extremally cheep
becouse if˙ you do some check then rise sleep
for(;;)
{
if(someting_here) {}
sleep(0.1)
}
then loop and if takes few cycles, where sleep 0.1 ms takes about 300
000 cycles (switching cpu off to another route tales also some) so the
cost is microscopic... i dont think alternative methods are faster
why sleep? You should be waiting for IO to complete. The only time a io thread should block is when there is no IO to do. The server is idle.
On Tue, 9 Jun 2026 13:55:25 -0700, Chris M. Thomasson wrote:
On 6/9/2026 2:10 AM, Lawrence D?Oliveiro wrote:
... in regular multitasking OSes, we have these standard techniques
for maximizing responsiveness while minimizing resource usage.
Which is why systems like Linux can scale gracefully to tens or
even hundreds of thousands of simultaneous peer connections.
Well, for servers/clients in windows, IOCP is key.
IOCP is based on the asynchronous I/O model from DEC?s old VMS
operating system, which Dave Cutler also masterminded before moving to >Microsoft to create Windows NT.
Nobody else seems to have thought it a worthwhile enough model to
copy, though. I think it requires you to have multiple I/O requests in >flight, one for each connection you want to watch. This might make for
a more complicated programming model, as opposed to the simplicity of >poll(2)/epoll(2).
Chris M. Thomasson pisze:
On 6/10/2026 12:06 AM, fir wrote:
Lawrence D?Oliveiro pisze:
On Tue, 9 Jun 2026 11:34:36 +0200, fir wrote:this 100 ms was an example not more meaning than using "foo" name if
Lawrence D?Oliveiro pisze:
this standard techniques are not necesarelly much good imo...ans
On Tue, 9 Jun 2026 08:56:00 +0200, fir wrote:
you know what sleep() function is its extremally often used basic >>>>>>> windows function which sleeps main thread for n miliseconds, every >>>>>>> or nearly every (afait) windows app uses it so its totally notmall >>>>>>Maybe normal in Windows, but in regular multitasking OSes, we have >>>>>> these standard techniques for maximizing responsiveness while
minimizing resource usage. Which is why systems like Linux can
scale gracefully to tens or even hundreds of thousands of
simultaneous peer connections.
sleep is architecturally simple and not bad imo
You keep saying that, even after I point out why it?s a bad idea.
this is also not inneficient - its efficient as it returns power to
system (somore app uses sleep more lightweight it is i would say)
Think of how you could do enough peak throughput to saturate a gigabit >>>> Ethernet link. This is at the low end of network connection speeds
these days -- higher-performance configurations might have an order of >>>> magnitude or two greater bandwidth.
To manage it, you?d need to push through about 120 megabytes per
second. With your sleep-every-100ms poll, this means each I/O request
would need a buffer size of about 12 megabytes. This is ridiculously
large. And of course the 100ms latency would be unacceptable for many
uses -- think of a multiuser game server, for example.
you can change "foo" into "boo" then you can turn 100 ms into 0.1 ms
i hope youre not think i would put 100 ms in a situation when you
need 1 ms or 0.1 ms...if you think so yure exceptionally vrong
this polling in active loop is generally good becouse it is so simple
it nt rises complications..you dont need additionsl thread, you dont
hang
on input etc.. note also polling is very almost extremally cheep
becouse if˙ you do some check then rise sleep
for(;;)
{
if(someting_here) {}
sleep(0.1)
}
then loop and if takes few cycles, where sleep 0.1 ms takes about 300
000 cycles (switching cpu off to another route tales also some) so the
cost is microscopic... i dont think alternative methods are faster
why sleep? You should be waiting for IO to complete. The only time a
io thread should block is when there is no IO to do. The server is idle.
why you think YOU SHOULD be waiting? waiting makes some complications
(like for example you can wait only on one thing - so its like BRAIN
OFF) in general you should monitor conditions activelly and react accordingly imo
On Mon, 8 Jun 2026 18:16:10 +0200, fir wrote:
Sleep(100); //wait 100 ms
That?s usually a dumb thing to do.
It?s either too slow if something
comes in/goes out more quickly, or too much overhead if communication
is slower than that. And it just gets worse if you?re trying to juggle multiple connections (as a server commonly does).
Try using this <https://manpages.debian.org/poll(2)>, at least ...
why you think YOU SHOULD be waiting? waiting makes some
complications (like for example you can wait only on one thing ...
Windows I/O is unified and async across all device types ? that?s
the whole point of IOCP.
If anything, Unix is the one still trying to catch up with a real
async model (see: io_uring).
Actually, its lower level than IOCP. We have to manage our own ring
buffers.
But IOCP and io_uring has an interesting mapping... They are fairly
damn similar! IOCP and io_uring map onto each other in a way that?s
almost eerie. They?re not identical, but conceptually they solve the
same problem with almost the same architecture, just at different
abstraction levels...
On 6/8/2026 5:28 PM, Lawrence D?Oliveiro wrote:
On Mon, 8 Jun 2026 18:16:10 +0200, fir wrote:
Sleep(100); //wait 100 ms
That?s usually a dumb thing to do.
More ignorant than dumb wrt to fir?
i was doing only basics of socket programming anver liked it and
remember almost nothing - it is becouse i dont liek stupid things
and those sockets looks stupid
On Tue, 9 Jun 2026 23:01:28 -0700, Chris M. Thomasson wrote:
I just remembered some of the "fun" functions for IOCP on Windows.
TransmitPackets and TransmitFile.
https://learn.microsoft.com/en-us/windows/win32/api/mswsock/nc-mswsock-lpfn_transmitpackets
Why do you need separate calls for ?sockets? versus ?files??
I was looking for equivalent Linux calls, and found a remarkable number:
<https://manpages.debian.org/copy_file_range(2)> <https://manpages.debian.org/sendfile(2)> <https://manpages.debian.org/splice(2)> <https://manpages.debian.org/vmsplice(2)>
Petty cool, except iirc the client versions of nt 4.0 nerfed them to
only two concurrent in flight calls at a time.
AcceptEx and ConnectEx were pretty cool as well.
https://learn.microsoft.com/en-us/windows/win32/api/mswsock/nf-mswsock-acceptex
https://learn.microsoft.com/en-us/windows/win32/api/mswsock/nc-mswsock-lpfn_connectex
Mainly to avoid a separate I/O call to send/receive the first lot of
data? Does it do that much for performance?
On 6/9/2026 11:47 PM, Lawrence D?Oliveiro wrote:
Mainly to avoid a separate I/O call to send/receive the first lot
of data? Does it do that much for performance?
Send it right from memory. It handles everything. It completes with
a status. It way more efficient than sending a file via WSASend'.
On Wed, 10 Jun 2026 00:31:38 -0700, Chris M. Thomasson wrote:
Actually, its lower level than IOCP. We have to manage our own ring
buffers.
But IOCP and io_uring has an interesting mapping... They are fairly
damn similar! IOCP and io_uring map onto each other in a way that?s
almost eerie. They?re not identical, but conceptually they solve the
same problem with almost the same architecture, just at different
abstraction levels...
I think a key point of io_uring is to minimize the frequency of user/kernel-mode transitions.
One limitation of Windows is that, unlike *nix systems, you cannot
share open file descriptions (particularly network connections, named
pipes, I/O completion ports, etc) between processes.
On 2026-06-08, fir <profesor.fir@gmail.com> wrote:
https://www.youtube.com/watch?v=XAzUoizwnXM
i dint watched it whole but it comes to my mind that those socket
communication indeed should be probably made using
fopen/fread/fwrite/fgetc/fputc
That's how it is in the Plan 9 operating system. It takes the
"everything is a file" paradigm that Unix started on. Unix diverged
from that paradigm in implementing new things like networking.
i was doing only basics of socket programming anver liked it and
remember almost nothing - it is becouse i dont liek stupid things
and those sockets looks stupid
i guess using this fopen it would be much better..
"Using fopen" is better is basically "using strings is better"
in disguise. When you use fopen to open a network client or server >connection, all the connection parameters have to be encoded into
a character string, instead of binary structures.
That makes some things easy, such as binding to networking from a new >programming language (no "FFI" required, just buffered file I/O and
string munging).
The strings are inefficient, though; they have to be formatted
and parsed. They lack type safety. You can put wrong values
into a binary address structure, but in a string you can cause
a syntax error. And worse, injection security holes and whatnot.
Sharing a single IOCP between different processes, is well. Probably
going to not work. Never did that anyway.
On Thu, 11 Jun 2026 13:27:22 -0700, Chris M. Thomasson wrote:
On 6/9/2026 11:47 PM, Lawrence D?Oliveiro wrote:
Mainly to avoid a separate I/O call to send/receive the first lot
of data? Does it do that much for performance?
Send it right from memory. It handles everything. It completes with
a status. It way more efficient than sending a file via WSASend'.
But that only works for a small amount of data. For which you might as
well use datagrams (e.g. UDP) rather than a full virtual circuit
(e.g. TCP).
On 6/11/2026 6:35 PM, Lawrence D?Oliveiro wrote:
On Thu, 11 Jun 2026 13:27:22 -0700, Chris M. Thomasson wrote:
On 6/9/2026 11:47 PM, Lawrence D?Oliveiro wrote:
Mainly to avoid a separate I/O call to send/receive the first lot
of data? Does it do that much for performance?
Send it right from memory. It handles everything. It completes with
a status. It way more efficient than sending a file via WSASend'.
But that only works for a small amount of data. For which you might as
well use datagrams (e.g. UDP) rather than a full virtual circuit
(e.g. TCP).
What that is besides the point in a sense, category error, perhaps? TransmitPackets is an efficient way to send some things, winnt client
nerf aside for a moment. Actually, around 25+ years ago, I had a system where you would make a TCP connection, and use UDP for sending a file.
The packets had file offsets where the receiver knew where to write them
to say a memory mapped file. The TCP connection would handle basic
tasks, the UDP for for bulk data transfer. A fun experiment.
Actually, on Windows we should use TransmitPackets wherever we can.
https://www.youtube.com/watch?v=XAzUoizwnXM
i dint watched it whole but it comes to my mind that those socket communication indeed should be probably made using fopen/fread/fwrite/ fgetc/fputc
i was doing only basics of socket programming anver liked it and
remember almost nothing - it is becouse i dont liek stupid things
and those sockets looks stupid
i guess using this fopen it would be much better..
whot would you need i assume you need to fopen connection to distant machine..not sure if it should be one the same for read write or two
one for read and one for write..then i think the network card should
have buffer whete there is stacked incoming data, same for outcoming
data,a nd thats all as to basics probably..no hanging controll no
additional threads..just like working with files
whough additional soft could be written too, based on thai but it should
be sane thing something based like with working with files (knowing
those files are ram files and are contents of incoming and outcoming buffer thise sockets todajy i dont remember but in my vague mameory it feels
like shit
feel free to comment on this topic if you want
On Sat, 13 Jun 2026 14:32:24 -0700, Chris M. Thomasson wrote:
Actually, on Windows we should use TransmitPackets wherever we can.
I was wondering why there are two separate API functions,
?TransmitPackets? versus ?TransmitFile?. It turns out the latter <https://learn.microsoft.com/en-us/windows/win32/api/mswsock/nf-mswsock-transmitfile>
... only supports connection-oriented sockets of type SOCK_STREAM,
SOCK_SEQPACKET, and SOCK_RDM. Sockets of type SOCK_DGRAM and
SOCK_RAW are not supported. The TransmitPackets function can be
used with sockets of type SOCK_DGRAM.
So there is some kind of overlap of functionality, but the two are
optimized for slightly different application areas.
Oddly, the docs for the former <https://learn.microsoft.com/en-us/windows/win32/api/mswsock/nc-mswsock-lpfn_transmitpackets>
make no mention of SOCK_DGRAM. Is this call in fact suitable for *all*
socket connection types? However, note this caveat:
Expect better performance results when using the TransmitPackets
function on Windows Server 2003.
Doesn?t that apply to newer versions? Are you supposed to stick with
Server 2003 to get the best out of it? Also, this:
The TransmitPackets function is optimized according to the
operating system on which it is used:
? On Windows server editions, the TransmitPackets function is
optimized for high performance.
? On Windows client editions, the TransmitPackets function is
optimized for minimum memory and resource utilization.
So you need to use different calls to get high performance depending
on the edition of Windows you?re running on?
Seems like there?s a hodge-podge of motley functionality there, added
to and modified over time by different groups with no clear overall
vision driving things.
Conway?s Law applies, I guess ...
On 6/13/2026 5:45 PM, Lawrence D?Oliveiro wrote:
<https://learn.microsoft.com/en-us/windows/win32/api/mswsock/nc-mswsock-lpfn_transmitpackets>
... note this caveat:
Expect better performance results when using the TransmitPackets
function on Windows Server 2003.
Doesn?t that apply to newer versions? Are you supposed to stick
with Server 2003 to get the best out of it?
It applies to new versions.
What do you think of AcceptEx and ConnectEx? ;^)
On Sun, 14 Jun 2026 13:55:58 -0700, Chris M. Thomasson wrote:
On 6/13/2026 5:45 PM, Lawrence D?Oliveiro wrote:
<https://learn.microsoft.com/en-us/windows/win32/api/mswsock/nc-mswsock-lpfn_transmitpackets>
... note this caveat:
Expect better performance results when using the TransmitPackets
function on Windows Server 2003.
Doesn?t that apply to newer versions? Are you supposed to stick
with Server 2003 to get the best out of it?
It applies to new versions.
But the docs don?t say so. You?re just assuming that.
What do you think of AcceptEx and ConnectEx? ;^)
They seem optimized for circuit-oriented connections which
send/receive very small amounts of data ... and unencrypted ones, at
that. Is this a common use-case in the Windows world?
On 6/15/2026 9:36 PM, Lawrence D?Oliveiro wrote:
On Sun, 14 Jun 2026 13:55:58 -0700, Chris M. Thomasson wrote:
On 6/13/2026 5:45 PM, Lawrence D?Oliveiro wrote:
<https://learn.microsoft.com/en-us/windows/win32/api/mswsock/nc-
mswsock-lpfn_transmitpackets>
... note this caveat:
˙˙˙˙˙ Expect better performance results when using the TransmitPackets >>>> ˙˙˙˙˙ function on Windows Server 2003.
Doesn?t that apply to newer versions? Are you supposed to stick
with Server 2003 to get the best out of it?
It applies to new versions.
But the docs don?t say so. You?re just assuming that.
TransmitPackets/TransmitFile works on new windows. do you mean the performance benefit carries forward, or the API itself works? API works fine.
What do you think of AcceptEx and ConnectEx? ;^)
They seem optimized for circuit-oriented connections which
send/receive very small amounts of data ... and unencrypted ones, at
that. Is this a common use-case in the Windows world?
unencrypted ones? Why should they encrypt? The user needs to do that
before it sends anything.
On 6/15/2026 9:36 PM, Lawrence D?Oliveiro wrote:
They seem optimized for circuit-oriented connections which
send/receive very small amounts of data ... and unencrypted ones,
at that. Is this a common use-case in the Windows world?
unencrypted ones? Why should they encrypt? The user needs to do that
before it sends anything.
On Tue, 16 Jun 2026 13:08:49 -0700, Chris M. Thomasson wrote:
On 6/15/2026 9:36 PM, Lawrence D?Oliveiro wrote:
They seem optimized for circuit-oriented connections which
send/receive very small amounts of data ... and unencrypted ones,
at that. Is this a common use-case in the Windows world?
unencrypted ones? Why should they encrypt? The user needs to do that
before it sends anything.
The gold-standard protocol for doing this, namely TLS, requires a Diffie-Hellman exchange to set up the one-off session key for the
connection. That takes more than one packet in each direction.
fir pisze:
https://www.youtube.com/watch?v=XAzUoizwnXMmaybe someone who has some experience with socked programming know how
i dint watched it whole but it comes to my mind that those socket
communication indeed should be probably made using fopen/fread/fwrite/
fgetc/fputc
i was doing only basics of socket programming anver liked it and
remember almost nothing - it is becouse i dont liek stupid things
and those sockets looks stupid
i guess using this fopen it would be much better..
whot would you need i assume you need to fopen connection to distant
machine..not sure if it should be one the same for read write or two
one for read and one for write..then i think the network card should
have buffer whete there is stacked incoming data, same for outcoming
data,a nd thats all as to basics probably..no hanging controll no
additional threads..just like working with files
whough additional soft could be written too, based on thai but it
should be sane thing something based like with working with files
(knowing those files are ram files and are contents of incoming and
outcoming buffer
thise sockets todajy i dont remember but in my vague mameory it feels
like shit
feel free to comment on this topic if you want
the basic communication would look like using this fopen scheme
main()
{
˙˙ FILE* f = fopen("1.2.3.4:555");
˙ fprintf(f, "hello there\n"); fflush(f);
˙ for(int i=0; i<100; i++)
˙ {
˙˙˙ static char buf[4096];
˙˙˙ if(fgets(buf, sizeof(buf), f))
˙˙˙˙˙˙ printf("incoming: %s", buf);
˙˙˙ Sleep(100); //wait 100 ms
˙ }
}
something like that?
On 6/16/2026 8:11 PM, Lawrence D?Oliveiro wrote:
On Tue, 16 Jun 2026 13:08:49 -0700, Chris M. Thomasson wrote:
On 6/15/2026 9:36 PM, Lawrence D?Oliveiro wrote:
They seem optimized for circuit-oriented connections which
send/receive very small amounts of data ... and unencrypted ones,
at that. Is this a common use-case in the Windows world?
unencrypted ones? Why should they encrypt? The user needs to do
that before it sends anything.
The gold-standard protocol for doing this, namely TLS, requires a
Diffie-Hellman exchange to set up the one-off session key for the
connection. That takes more than one packet in each direction.
ConnectEx can optionally send data. That data is a bag o bytes.
Encrypted or not. How one sets that up is up to them.
On Wed, 17 Jun 2026 12:13:19 -0700, Chris M. Thomasson wrote:
On 6/16/2026 8:11 PM, Lawrence D?Oliveiro wrote:
On Tue, 16 Jun 2026 13:08:49 -0700, Chris M. Thomasson wrote:
On 6/15/2026 9:36 PM, Lawrence D?Oliveiro wrote:
They seem optimized for circuit-oriented connections which
send/receive very small amounts of data ... and unencrypted ones,
at that. Is this a common use-case in the Windows world?
unencrypted ones? Why should they encrypt? The user needs to do
that before it sends anything.
The gold-standard protocol for doing this, namely TLS, requires a
Diffie-Hellman exchange to set up the one-off session key for the
connection. That takes more than one packet in each direction.
ConnectEx can optionally send data. That data is a bag o bytes.
Encrypted or not. How one sets that up is up to them.
Not really enough to set up an encryption session, as I said. Just
seems optimized for circuit-oriented connections which send/receive
small amounts of unencrypted data.
Is this a common use-case in the Windows world?
On 6/17/2026 4:47 PM, Lawrence D?Oliveiro wrote:
On Wed, 17 Jun 2026 12:13:19 -0700, Chris M. Thomasson wrote:
On 6/16/2026 8:11 PM, Lawrence D?Oliveiro wrote:
The gold-standard protocol for doing this, namely TLS, requires a
Diffie-Hellman exchange to set up the one-off session key for the
connection. That takes more than one packet in each direction.
ConnectEx can optionally send data. That data is a bag o bytes.
Encrypted or not. How one sets that up is up to them.
Not really enough to set up an encryption session, as I said. Just
seems optimized for circuit-oriented connections which send/receive
small amounts of unencrypted data.
Is this a common use-case in the Windows world?
Well, ConnectEx can send the initial DH exchange bytes right on connect.
But that is up to the user... Right?
(could almost go as far as to mimic Windows drive letters ...
On Wed, 17 Jun 2026 18:41:57 -0500, BGB wrote:
(could almost go as far as to mimic Windows drive letters ...
Oh gods, no ...
On Wed, 17 Jun 2026 20:26:00 -0700, Chris M. Thomasson wrote:
On 6/17/2026 4:47 PM, Lawrence D?Oliveiro wrote:
On Wed, 17 Jun 2026 12:13:19 -0700, Chris M. Thomasson wrote:
On 6/16/2026 8:11 PM, Lawrence D?Oliveiro wrote:
The gold-standard protocol for doing this, namely TLS, requires a
Diffie-Hellman exchange to set up the one-off session key for the
connection. That takes more than one packet in each direction.
ConnectEx can optionally send data. That data is a bag o bytes.
Encrypted or not. How one sets that up is up to them.
Not really enough to set up an encryption session, as I said. Just
seems optimized for circuit-oriented connections which send/receive
small amounts of unencrypted data.
Is this a common use-case in the Windows world?
Well, ConnectEx can send the initial DH exchange bytes right on connect.
But that is up to the user... Right?
The TLS setup exchange is diagrammed here <https://www.rfc-editor.org/info/rfc8446/#section-2>. There are three phases:
1) Key exchange: ClientHello + ServerHello -- one message in each direction
2) Server parameters -- two messages from server to client
3) Authentication -- three messages in each direction.
Hard to see how to fit all that into a single ConnectEx + AcceptEx ...
On 6/18/2026 12:30 AM, Lawrence D?Oliveiro wrote:
On Wed, 17 Jun 2026 20:26:00 -0700, Chris M. Thomasson wrote:
On 6/17/2026 4:47 PM, Lawrence D?Oliveiro wrote:
On Wed, 17 Jun 2026 12:13:19 -0700, Chris M. Thomasson wrote:
On 6/16/2026 8:11 PM, Lawrence D?Oliveiro wrote:
The gold-standard protocol for doing this, namely TLS, requires a
Diffie-Hellman exchange to set up the one-off session key for the
connection. That takes more than one packet in each direction.
ConnectEx can optionally send data. That data is a bag o bytes.
Encrypted or not. How one sets that up is up to them.
Not really enough to set up an encryption session, as I said. Just
seems optimized for circuit-oriented connections which send/receive
small amounts of unencrypted data.
Is this a common use-case in the Windows world?
Well, ConnectEx can send the initial DH exchange bytes right on connect. >>> But that is up to the user... Right?
The TLS setup exchange is diagrammed here
<https://www.rfc-editor.org/info/rfc8446/#section-2>. There are three
phases:
˙˙ 1) Key exchange: ClientHello + ServerHello -- one message in each
direction
˙˙ 2) Server parameters -- two messages from server to client
˙˙ 3) Authentication -- three messages in each direction.
Hard to see how to fit all that into a single ConnectEx + AcceptEx ...
The ConnectEx can be the ClientHello at least. ;^)
On 6/18/2026 12:30 AM, Lawrence D?Oliveiro wrote:
The TLS setup exchange is diagrammed here
<https://www.rfc-editor.org/info/rfc8446/#section-2>. There are
three phases:
1) Key exchange: ClientHello + ServerHello -- one message in
each direction
2) Server parameters -- two messages from server to client
3) Authentication -- three messages in each direction.
Hard to see how to fit all that into a single ConnectEx + AcceptEx
...
The ConnectEx can be the ClientHello at least. ;^)
Just that it is also not a huge leap from:
tcp://whatever
udp://whatever
http://whatever
ftp://whatever
...
To:
c:/whatever...
On Thu, 18 Jun 2026 03:49:55 -0500, BGB wrote:
Just that it is also not a huge leap from:
tcp://whatever
udp://whatever
http://whatever
ftp://whatever
...
To:
c:/whatever...
Yes it is.
In the former, that part before the colon is a protocol. In the
latter, it is now down to just indicating a filesystem drive. And not
even in a unique fashion, like with a volume UUID or something, but
with an arbitarily-assigned ?drive letter? which cannot be guaranteed
to be unique or persistent.
Remember, we already have
file://whatever
for denoting files on the local filesystem. That allows the ?whatever?
part to span the entire filesystem, not just one volume/drive.
On 6/18/2026 6:06 PM, Lawrence D?Oliveiro wrote:
On Thu, 18 Jun 2026 03:49:55 -0500, BGB wrote:
Just that it is also not a huge leap from:
˙˙˙ tcp://whatever
˙˙˙ udp://whatever
˙˙˙ http://whatever
˙˙˙ ftp://whatever
˙˙˙ ...
To:
˙˙˙ c:/whatever...
Yes it is.
In the former, that part before the colon is a protocol. In the
latter, it is now down to just indicating a filesystem drive. And not
even in a unique fashion, like with a volume UUID or something, but
with an arbitarily-assigned ?drive letter? which cannot be guaranteed
to be unique or persistent.
Well, on older Windows.
On newer systems, the OS remembers and will assign the same drives to
the same letter on each boot.
But, yeah, probably wouldn't do it the Windows way. Either they could be specified as mounts (in mtab or such), or possibly treated as aliases, say:
˙ c:/ aliases to /mnt/c
Though, granted, not much particular reason to do this...
Remember, we already have
˙˙˙˙ file://whatever
for denoting files on the local filesystem. That allows the ?whatever?
part to span the entire filesystem, not just one volume/drive.
Maybe, but you wouldn't need "file://" for "fopen()" or similar, since
it is sort of an implied default in this case.
Then again, going into the weeds on this:
Would, say:
˙ cd ftp://foo.org/pub/
˙ ls
Even really make sense?...
Or, would it be better to ask people to at least mount it into the VFS
or similar?...
Well, or other mysteries, like, say:
Should usermode applications be allowed to export COM-like interfaces
that could then be mounted into the VFS?...
Say, for example, an application exports an IFileSystem or IMount
interface to the VFS, and then one can issue a "mount" on it. Would need some way for the VFS do deal gracefully if the application becomes unresponsive or crashes though (preferably without nuking the whole OS
in the process).
Vs, say, assuming programs that export interfaces (as services) to be at least semi trsusted / stable...
On newer [Windows], the OS remembers and will assign the same drives
to the same letter on each boot.
Maybe, but you wouldn't need "file://" for "fopen()" or similar,
since it is sort of an implied default in this case.
May seem like a waste to burn a thread on each object listener, but
no real better option at present.
Then again, going into the weeds on this:
Would, say:
cd ftp://foo.org/pub/
ls
Even really make sense?...
Or, would it be better to ask people to at least mount it into the VFS
or similar?...
On 19/06/2026 08:20, BGB wrote:
On 6/18/2026 6:06 PM, Lawrence D?Oliveiro wrote:
On Thu, 18 Jun 2026 03:49:55 -0500, BGB wrote:
Just that it is also not a huge leap from:
˙˙˙ tcp://whatever
˙˙˙ udp://whatever
˙˙˙ http://whatever
˙˙˙ ftp://whatever
˙˙˙ ...
To:
˙˙˙ c:/whatever...
Yes it is.
In the former, that part before the colon is a protocol. In the
latter, it is now down to just indicating a filesystem drive. And not
even in a unique fashion, like with a volume UUID or something, but
with an arbitarily-assigned ?drive letter? which cannot be guaranteed
to be unique or persistent.
Well, on older Windows.
On newer systems, the OS remembers and will assign the same drives to
the same letter on each boot.
I am not sure what you call "newer", but IIRC Windows has done that
since Windows 3.1.˙ The only letters you could assign yourself were for network drives, and they were persistent if you choose "persistent=yes".
Later versions of Windows (maybe NT4 or W2K?˙ I can't remember the
details) let you choose the letter to use for other drives, such as additional harddrives, CD-ROMs and later still, USB drives.˙ Those
choices were persistent.
Automatically chosen drive letters were, of course, inconsistent.˙ And
when you have a lot of drives and network shares, they run out.
But, yeah, probably wouldn't do it the Windows way. Either they could
be specified as mounts (in mtab or such), or possibly treated as
aliases, say:
˙˙ c:/ aliases to /mnt/c
Drive letters make sense when users wanted to distinguish between their
3.5" floppy "A:" and their 5.25" floppy "B:".˙ They were still usable
when you had a hard drive with one partition.˙ Once it was realistic to
have two drives in the one PC, and more than one partition on a disk,
they were outdated and too restrictive for comfort.
On 19/06/2026 07:56, David Brown wrote:
On 19/06/2026 08:20, BGB wrote:
On 6/18/2026 6:06 PM, Lawrence D?Oliveiro wrote:
On Thu, 18 Jun 2026 03:49:55 -0500, BGB wrote:
Just that it is also not a huge leap from:
˙˙˙ tcp://whatever
˙˙˙ udp://whatever
˙˙˙ http://whatever
˙˙˙ ftp://whatever
˙˙˙ ...
To:
˙˙˙ c:/whatever...
Yes it is.
In the former, that part before the colon is a protocol. In the
latter, it is now down to just indicating a filesystem drive. And not
even in a unique fashion, like with a volume UUID or something, but
with an arbitarily-assigned ?drive letter? which cannot be guaranteed
to be unique or persistent.
Well, on older Windows.
On newer systems, the OS remembers and will assign the same drives to
the same letter on each boot.
I am not sure what you call "newer", but IIRC Windows has done that
since Windows 3.1.˙ The only letters you could assign yourself were for
network drives, and they were persistent if you choose "persistent=yes".
Later versions of Windows (maybe NT4 or W2K?˙ I can't remember the
details) let you choose the letter to use for other drives, such as
additional harddrives, CD-ROMs and later still, USB drives.˙ Those
choices were persistent.
Automatically chosen drive letters were, of course, inconsistent.˙ And
when you have a lot of drives and network shares, they run out.
But, yeah, probably wouldn't do it the Windows way. Either they could
be specified as mounts (in mtab or such), or possibly treated as
aliases, say:
˙˙ c:/ aliases to /mnt/c
Drive letters make sense when users wanted to distinguish between their
3.5" floppy "A:" and their 5.25" floppy "B:".˙ They were still usable
when you had a hard drive with one partition.˙ Once it was realistic to
have two drives in the one PC, and more than one partition on a disk,
they were outdated and too restrictive for comfort.
How would you distinguish between two floppy drives on a Unix-like file >system?
If writing a common shell script for other people to use on their own >machines, would you be able to use the same designations?
On 19/06/2026 07:56, David Brown wrote:
On 19/06/2026 08:20, BGB wrote:
On 6/18/2026 6:06 PM, Lawrence D?Oliveiro wrote:
On Thu, 18 Jun 2026 03:49:55 -0500, BGB wrote:
Just that it is also not a huge leap from:
˙˙˙ tcp://whatever
˙˙˙ udp://whatever
˙˙˙ http://whatever
˙˙˙ ftp://whatever
˙˙˙ ...
To:
˙˙˙ c:/whatever...
Yes it is.
In the former, that part before the colon is a protocol. In the
latter, it is now down to just indicating a filesystem drive. And not
even in a unique fashion, like with a volume UUID or something, but
with an arbitarily-assigned ?drive letter? which cannot be guaranteed
to be unique or persistent.
Well, on older Windows.
On newer systems, the OS remembers and will assign the same drives to
the same letter on each boot.
I am not sure what you call "newer", but IIRC Windows has done that
since Windows 3.1.˙ The only letters you could assign yourself were
for network drives, and they were persistent if you choose
"persistent=yes".
Later versions of Windows (maybe NT4 or W2K?˙ I can't remember the
details) let you choose the letter to use for other drives, such as
additional harddrives, CD-ROMs and later still, USB drives.˙ Those
choices were persistent.
Automatically chosen drive letters were, of course, inconsistent.˙ And
when you have a lot of drives and network shares, they run out.
But, yeah, probably wouldn't do it the Windows way. Either they could
be specified as mounts (in mtab or such), or possibly treated as
aliases, say:
˙˙ c:/ aliases to /mnt/c
Drive letters make sense when users wanted to distinguish between
their 3.5" floppy "A:" and their 5.25" floppy "B:".˙ They were still
usable when you had a hard drive with one partition.˙ Once it was
realistic to have two drives in the one PC, and more than one
partition on a disk, they were outdated and too restrictive for comfort.
How would you distinguish between two floppy drives on a Unix-like file system?
If writing a common shell script for other people to use on their own machines, would you be able to use the same designations?
In article <11132u8$37hrh$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
On 19/06/2026 07:56, David Brown wrote:
On 19/06/2026 08:20, BGB wrote:
On 6/18/2026 6:06 PM, Lawrence D?Oliveiro wrote:
On Thu, 18 Jun 2026 03:49:55 -0500, BGB wrote:
Just that it is also not a huge leap from:
˙˙˙ tcp://whatever
˙˙˙ udp://whatever
˙˙˙ http://whatever
˙˙˙ ftp://whatever
˙˙˙ ...
To:
˙˙˙ c:/whatever...
Yes it is.
In the former, that part before the colon is a protocol. In the
latter, it is now down to just indicating a filesystem drive. And not >>>>> even in a unique fashion, like with a volume UUID or something, but
with an arbitarily-assigned ?drive letter? which cannot be guaranteed >>>>> to be unique or persistent.
Well, on older Windows.
On newer systems, the OS remembers and will assign the same drives to
the same letter on each boot.
I am not sure what you call "newer", but IIRC Windows has done that
since Windows 3.1.˙ The only letters you could assign yourself were for
network drives, and they were persistent if you choose "persistent=yes". >>>
Later versions of Windows (maybe NT4 or W2K?˙ I can't remember the
details) let you choose the letter to use for other drives, such as
additional harddrives, CD-ROMs and later still, USB drives.˙ Those
choices were persistent.
Automatically chosen drive letters were, of course, inconsistent.˙ And
when you have a lot of drives and network shares, they run out.
But, yeah, probably wouldn't do it the Windows way. Either they could
be specified as mounts (in mtab or such), or possibly treated as
aliases, say:
˙˙ c:/ aliases to /mnt/c
Drive letters make sense when users wanted to distinguish between their
3.5" floppy "A:" and their 5.25" floppy "B:".˙ They were still usable
when you had a hard drive with one partition.˙ Once it was realistic to
have two drives in the one PC, and more than one partition on a disk,
they were outdated and too restrictive for comfort.
How would you distinguish between two floppy drives on a Unix-like file
system?
Based on the directory name where you mount them.
If writing a common shell script for other people to use on their own
machines, would you be able to use the same designations?
You don't. You parameterize it. Why would I want to restrict a
shell script to only working with the contents of floppy disks?
Obligatory plan 9 example:
cpu% grep floppy /dev/drivers
#f floppy
cpu% ls '#f'
'#f/fd0ctl'
'#f/fd0disk'
'#f/fd1ctl'
'#f/fd1disk'
cpu% bind -a '#f' /dev
cpu% ls -l /dev/fd0disk
--rw-rw---- f 0 bootes bootes 1474560 Sep 20 2021 /dev/fd0disk
cpu% dossrv
dossrv: serving #s/dos
cpu% mount -c /srv/dos /n/floppy0 /dev/fd0disk
cpu% mount -c /srv/dos /n/floppy1 /dev/fd1disk
cpu%
This was all wrapped up into a shell script:
cpu% cat /bin/a:
#!/bin/rc
rfork e
flop=/dev/fd0disk
if(! test -r $flop)
flop='#f'/fd0disk
if(! test -f /srv/dos)
dossrv >/dev/null </dev/null >[2]/dev/null
unmount /n/a:>[2]/dev/null
mount -c /srv/dos /n/a: $flop
unmount /n/a >[2]/dev/null
mount -c /srv/dos /n/a $flop
cpu%
The floppy device is built into the kernel. The names relative
to `/n` are arbitrary; the contents of both floppies are now
available on /n/floppy0 and /n/floppy1 respectively. `dossrv`
is a program that implements a few variations of FAT
filesystems.
The key observation is that shoehorning everything into `open`
is the wrong model; instead, conceptually splitting into
separate `mount` and access operations simplifies and permits
composition. Making `mount` unprivileged and allowing the user
to control their view of the file namespace makes all of this
natural.
On 19/06/2026 11:42, Bart wrote:
On 19/06/2026 07:56, David Brown wrote:
On 19/06/2026 08:20, BGB wrote:
On 6/18/2026 6:06 PM, Lawrence D?Oliveiro wrote:
On Thu, 18 Jun 2026 03:49:55 -0500, BGB wrote:
Just that it is also not a huge leap from:
˙˙˙ tcp://whatever
˙˙˙ udp://whatever
˙˙˙ http://whatever
˙˙˙ ftp://whatever
˙˙˙ ...
To:
˙˙˙ c:/whatever...
Yes it is.
In the former, that part before the colon is a protocol. In the
latter, it is now down to just indicating a filesystem drive. And not >>>>> even in a unique fashion, like with a volume UUID or something, but
with an arbitarily-assigned ?drive letter? which cannot be guaranteed >>>>> to be unique or persistent.
Well, on older Windows.
On newer systems, the OS remembers and will assign the same drives
to the same letter on each boot.
I am not sure what you call "newer", but IIRC Windows has done that
since Windows 3.1.˙ The only letters you could assign yourself were
for network drives, and they were persistent if you choose
"persistent=yes".
Later versions of Windows (maybe NT4 or W2K?˙ I can't remember the
details) let you choose the letter to use for other drives, such as
additional harddrives, CD-ROMs and later still, USB drives.˙ Those
choices were persistent.
Automatically chosen drive letters were, of course, inconsistent.
And when you have a lot of drives and network shares, they run out.
But, yeah, probably wouldn't do it the Windows way. Either they
could be specified as mounts (in mtab or such), or possibly treated
as aliases, say:
˙˙ c:/ aliases to /mnt/c
Drive letters make sense when users wanted to distinguish between
their 3.5" floppy "A:" and their 5.25" floppy "B:".˙ They were still
usable when you had a hard drive with one partition.˙ Once it was
realistic to have two drives in the one PC, and more than one
partition on a disk, they were outdated and too restrictive for comfort.
How would you distinguish between two floppy drives on a Unix-like
file system?
To be honest, I have never come across the need.˙ In my university days (with SunOS, then Solaris) the machines did not have floppies - most did
not even have hard disks.˙ By the time I started using Linux, at about
the turn of the century, floppies were out of fashion.
If writing a common shell script for other people to use on their own
machines, would you be able to use the same designations?
Filesystems are mounted on *nix systems.˙ The exact placement of mount points varies, as does the extent to which attached filesystems are automounted, or the user is informed and given a choice, or mounting is manual.˙ Different *nix systems have different habits, and in Linux it
can vary by distro or desktop.˙ And then administrators or users can
have their own choices.
Hardware is different - if I need to use a floppy these days, it would
be via a USB floppy drive.˙ More realistically, people would use USB
memory sticks now.˙ But someone might have several USB mass storage
devices attached - I would not presume to know which they want to use
for this script or program.˙ So I would say the script should either
require a path (for file / directory access - and I can't think why it
would be limited to a floppy), or a device name (for something like a
flash image writer).˙ It would likely be better to have a gui or menu
choice for some programs.˙ Getting lists of the available block devices, mounted systems, filesystem types, etc., and detailed information about
the devices, is not hard on Linux - but I don't know how portable that
might be to other *nix systems.
On 19/06/2026 12:46, David Brown wrote:
On 19/06/2026 11:42, Bart wrote:
On 19/06/2026 07:56, David Brown wrote:
On 19/06/2026 08:20, BGB wrote:
On 6/18/2026 6:06 PM, Lawrence D?Oliveiro wrote:
On Thu, 18 Jun 2026 03:49:55 -0500, BGB wrote:
Just that it is also not a huge leap from:
˙˙˙ tcp://whatever
˙˙˙ udp://whatever
˙˙˙ http://whatever
˙˙˙ ftp://whatever
˙˙˙ ...
To:
˙˙˙ c:/whatever...
Yes it is.
In the former, that part before the colon is a protocol. In the
latter, it is now down to just indicating a filesystem drive. And not >>>>>> even in a unique fashion, like with a volume UUID or something, but >>>>>> with an arbitarily-assigned ?drive letter? which cannot be guaranteed >>>>>> to be unique or persistent.
Well, on older Windows.
On newer systems, the OS remembers and will assign the same drives
to the same letter on each boot.
I am not sure what you call "newer", but IIRC Windows has done that
since Windows 3.1.˙ The only letters you could assign yourself were
for network drives, and they were persistent if you choose
"persistent=yes".
Later versions of Windows (maybe NT4 or W2K?˙ I can't remember the
details) let you choose the letter to use for other drives, such as
additional harddrives, CD-ROMs and later still, USB drives.˙ Those
choices were persistent.
Automatically chosen drive letters were, of course, inconsistent.
And when you have a lot of drives and network shares, they run out.
But, yeah, probably wouldn't do it the Windows way. Either they
could be specified as mounts (in mtab or such), or possibly treated >>>>> as aliases, say:
˙˙ c:/ aliases to /mnt/c
Drive letters make sense when users wanted to distinguish between
their 3.5" floppy "A:" and their 5.25" floppy "B:".˙ They were still
usable when you had a hard drive with one partition.˙ Once it was
realistic to have two drives in the one PC, and more than one
partition on a disk, they were outdated and too restrictive for
comfort.
How would you distinguish between two floppy drives on a Unix-like
file system?
To be honest, I have never come across the need.˙ In my university
days (with SunOS, then Solaris) the machines did not have floppies -
most did not even have hard disks.˙ By the time I started using Linux,
at about the turn of the century, floppies were out of fashion.
If writing a common shell script for other people to use on their own
machines, would you be able to use the same designations?
Filesystems are mounted on *nix systems.˙ The exact placement of mount
points varies, as does the extent to which attached filesystems are
automounted, or the user is informed and given a choice, or mounting
is manual.˙ Different *nix systems have different habits, and in Linux
it can vary by distro or desktop.˙ And then administrators or users
can have their own choices.
Hardware is different - if I need to use a floppy these days, it would
be via a USB floppy drive.˙ More realistically, people would use USB
memory sticks now.˙ But someone might have several USB mass storage
devices attached - I would not presume to know which they want to use
for this script or program.˙ So I would say the script should either
require a path (for file / directory access - and I can't think why it
would be limited to a floppy), or a device name (for something like a
flash image writer).˙ It would likely be better to have a gui or menu
choice for some programs.˙ Getting lists of the available block
devices, mounted systems, filesystem types, etc., and detailed
information about the devices, is not hard on Linux - but I don't know
how portable that might be to other *nix systems.
If you plug in a USB pen drive on Windows, it will be under a drive
letter, but that it is not guaranteed to be consistent, especially if
you plug in more than one.
So that is a problem. It would be useful, IMV, if the USB sockets were labeled with specific letters.
So, what's it like under Linux: if I plug a pen drive into my RPi, then
the files will be at:
˙ /media/bart/EEBEBEBEC313CA9B
Obviously. If I try another, then it's at /media/bart/NEW (note these
are case-sensitive), and a third was at /media/bart/0159078ED.
I assume that 'bart' is specific to my machine, so I can't assume
anything if, say, I wanted to hardcode a path into a program or script
that someone else runs.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 11 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 222:46:44 |
| Calls: | 219 |
| Files: | 21,505 |
| Messages: | 84,530 |