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.
On 19/06/2026 11:18, Dan Cross wrote:
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.
Machines that used floppy disks with drive letters tended to be used by >non-technical members of the public.
If I was doing technical support on the phone (which I actually did),
what would I tell someone to type in to refer to say the leftmost of
their two floppy drives:
Would it actually be "/n/floppy0", or would that depend on what had been
set up the client's specific machine? I assume it would have to be all
in the right case too?
The beauty of letter designations is that you just say 'type A colon';
it doesn't matter if they do A: or a: either as those OSes tended to be >case-insensitive.
This was also long before Windows, in my case on a CP/M clone.
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.
'Mount' wasn't a thing on those machines. It was usually plug-and-play.
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:
[snip]How would you distinguish between two floppy drives on a Unix-like
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. >>>
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.
In article <1113kuc$3cklj$2@dont-email.me>, Bart <bc@freeuk.com> wrote:
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:
[snip]How would you distinguish between two floppy drives on a Unix-like
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. >>>>
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.
Why letters and not descriptive volume names?
In article <1113jni$3cklj$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
On 19/06/2026 11:18, Dan Cross wrote:
In article <11132u8$37hrh$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >>>> On 19/06/2026 07:56, David Brown wrote:
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?
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.
Machines that used floppy disks with drive letters tended to be used by
non-technical members of the public.
If I was doing technical support on the phone (which I actually did),
what would I tell someone to type in to refer to say the leftmost of
their two floppy drives:
Move the goalposts much?
I was responding to a comment about a
shell script and Unix, not doing technical support over a
telephone for non-technical people.
This was also long before Windows, in my case on a CP/M clone.
I have been fortunate to not have to use Windows very much
throughout my career.
The original question had to do with `fopen`; someone brought up
Unix and shell scripts; I have no idea why you're talking about
CP/M, which copied DEC OSes.
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?
Bart <bc@freeuk.com> writes:
[...]
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?
I'd ask in a forum that discusses Unix-like systems, not one that
discusses the C programming language.
In article <1113jni$3cklj$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
This was also long before Windows, in my case on a CP/M clone.
I have been fortunate to not have to use Windows very much
throughout my career. That said, some of their kernel people
are amazing engineers.
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.
'Mount' wasn't a thing on those machines. It was usually plug-and-play.
The original question had to do with `fopen`; someone brought up
Unix and shell scripts; I have no idea why you're talking about
CP/M, which copied DEC OSes.
On 19/06/2026 17:18, Dan Cross wrote:
In article <1113jni$3cklj$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
If I was doing technical support on the phone (which I actually did),
what would I tell someone to type in to refer to say the leftmost of
their two floppy drives:
Move the goalposts much?
I haven't moved them at all. Someone made remarks about the scheme to >designate drives with letters, which is very simple and which everyone
could understand.
On 19/06/2026 17:31, Dan Cross wrote: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.
Why letters and not descriptive volume names?
These are letters that are physical labels next to each socket.
On 19/06/2026 18:33, Keith Thompson wrote:
Bart <bc@freeuk.com> writes:
[...]
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?
I'd ask in a forum that discusses Unix-like systems, not one that
discusses the C programming language.
Here's the thing: this is thread that has been wildly off-topic for
nearly 100 posts, even aside from the other off-topic threads.
Yet you pick on MY post and tell only ME to move the discussion elsewhere.
On Fri, 19 Jun 2026 01:20:14 -0500, BGB wrote:
On newer [Windows], the OS remembers and will assign the same drives
to the same letter on each boot.
You know, it’s a wonder to think, for an OS that was supposedly
designed for 16-bit machines, how many legacy features it inherits
from the 8-bit era.
Maybe, but you wouldn't need "file://" for "fopen()" or similar,
since it is sort of an implied default in this case.
For an OS-level call, yes. But there are lots of higher-level toolkits (particularly GUI-associated ones) that hook in a virtual-I/O layer
that allows accessing remote URLs as easily as opening local files.
May seem like a waste to burn a thread on each object listener, but
no real better option at present.
What, no event loop?
On 19/06/2026 17:18, Dan Cross wrote:
In article <1113jni$3cklj$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
On 19/06/2026 11:18, Dan Cross wrote:
In article <11132u8$37hrh$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >>>>> On 19/06/2026 07:56, David Brown wrote:
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?
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.
Machines that used floppy disks with drive letters tended to be used by
non-technical members of the public.
If I was doing technical support on the phone (which I actually did),
what would I tell someone to type in to refer to say the leftmost of
their two floppy drives:
Move the goalposts much?
I haven't moved them at all. Someone made remarks about the scheme to >designate drives with letters, which is very simple and which everyone
could understand.
I asked how that would have been done under Unix. Apparently, with some >difficulty; you needed to be an expert (well, working under Unix seems
to involve an awful lot of configuring anyway), and it's not even clear
who has to do do all that: me, or my client.
So my example showed that was it simpler to use the drive-letter scheme,
and out-of-the box; you don't need to /make/ it 'simple'.
I was responding to a comment about a
shell script and Unix, not doing technical support over a
telephone for non-technical people.
And the shell script presumably was part-answer to my question about
what replaces A: and B: on Unix.
This was also long before Windows, in my case on a CP/M clone.
I have been fortunate to not have to use Windows very much
throughout my career.
I've been even more fortunate in never needing to use Unix at all,
although I tried a few times.
The original question had to do with `fopen`; someone brought up
Unix and shell scripts; I have no idea why you're talking about
CP/M, which copied DEC OSes.
Because the earlier discussion was talking about Windows and drive
letters were associated with Windows, so I made the point that they go
back a lot further. Since people always like to stick it to Windows.
But I've used a couple of DEC OSes and don't remember drive letters.
Google AI tells me: "Drive letters originate from the CP/M operating
system in the 1970s and were popularized by MS-DOS."
On 19/06/2026 17:31, Dan Cross wrote:
[snip]
Why letters and not descriptive volume names?
These are letters that are physical labels next to each socket.
If I
give instructions to somebody to use physical socket 'A', they can do
that even if the machine is powered off.
If I look at the back of my TV, I have HDMI sockets marked 1, 2, 3. The
same numbering appears on the on-screen A/V menu. It's simple and it works.
Content- or device-related labels can be shown too interrogated from >whatever is plugged-in and active (that is, on-screen), but that is >secondary.
Of course, when there are no dedicated cables and it is all wireless,
then it gets harder and not so simple.
Bart <bc@freeuk.com> writes:
On 19/06/2026 17:18, Dan Cross wrote:
In article <1113jni$3cklj$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
<snip discussion of unix floppy disks>
If I was doing technical support on the phone (which I actually did),
what would I tell someone to type in to refer to say the leftmost of
their two floppy drives:
Move the goalposts much?
I haven't moved them at all. Someone made remarks about the scheme to
designate drives with letters, which is very simple and which everyone
could understand.
"Someone" named Bart, per chance?
Bart <bc@freeuk.com> writes:
On 19/06/2026 18:33, Keith Thompson wrote:
Bart <bc@freeuk.com> writes:
[...]
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?
I'd ask in a forum that discusses Unix-like systems, not one that
discusses the C programming language.
Here's the thing: this is thread that has been wildly off-topic for
nearly 100 posts, even aside from the other off-topic threads.
Yet you pick on MY post and tell only ME to move the discussion elsewhere.
perhaps it is because _you_ are most often the poster who
moves the thread off-topic?
In article <1113s0b$3f4nm$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
On 19/06/2026 17:31, Dan Cross wrote:
[snip]
Why letters and not descriptive volume names?
These are letters that are physical labels next to each socket.
Not on my system.
If I
give instructions to somebody to use physical socket 'A', they can do
that even if the machine is powered off.
Huh. Kinda hard to access the files on the "A:" drive when the
system is powered off.
I would find it frustrating to type
commands to a machine that isn't even running.
If I look at the back of my TV, I have HDMI sockets marked 1, 2, 3. The
same numbering appears on the on-screen A/V menu. It's simple and it works.
So the Unix scheme assigns each floppy drive a number. The only
substantive difference is that with Unix, you `mount` the
filesystem on the removable drive onto some directory, making
the files on that floppy appear as part of the global file
namespace.
Content- or device-related labels can be shown too interrogated from
whatever is plugged-in and active (that is, on-screen), but that is
secondary.
Of course, when there are no dedicated cables and it is all wireless,
then it gets harder and not so simple.
None of this has to do with `fopen`.
On Thu, 18 Jun 2026 04:36:43 -0700, Chris M. Thomasson wrote:
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. ;^)
And what does that achieve, really?
If saving the overhead of one system call is so significant, perhaps
you shouldn’t be using that OS for high-performance network operations
...
On 19/06/2026 20:58, Dan Cross wrote:
In article <1113s0b$3f4nm$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
On 19/06/2026 17:31, Dan Cross wrote:
[snip]
Why letters and not descriptive volume names?
These are letters that are physical labels next to each socket.
Not on my system.
This was hypothetical. That is, if USB sockets were labeled like my HDMI >example and those letters or numbers appeared also on menus.
If I
give instructions to somebody to use physical socket 'A', they can do
that even if the machine is powered off.
Huh. Kinda hard to access the files on the "A:" drive when the
system is powered off.
This is about plugging in the device, like I can plug in my PCV to HDMI1 >when the TV is still turned off.
I would find it frustrating to type
commands to a machine that isn't even running.
If I look at the back of my TV, I have HDMI sockets marked 1, 2, 3. TheSo the Unix scheme assigns each floppy drive a number. The only
same numbering appears on the on-screen A/V menu. It's simple and it works. >>
substantive difference is that with Unix, you `mount` the
filesystem on the removable drive onto some directory, making
the files on that floppy appear as part of the global file
namespace.
Content- or device-related labels can be shown too interrogated from
whatever is plugged-in and active (that is, on-screen), but that is
secondary.
Of course, when there are no dedicated cables and it is all wireless,
then it gets harder and not so simple.
None of this has to do with `fopen`.
Yet it hasn't stopped you having your say about a topic before declaring
it as off-topic.
On 6/18/2026 4:03 PM, Lawrence D’Oliveiro wrote:
If saving the overhead of one system call is so significant,
perhaps you shouldn’t be using that OS for high-performance network
operations ...
Humm... I think you are missing the point? ConnectEx/AcceptEx has
the option to send/recv data. That's it.
When you use ConnectEx or AcceptEx to send or receive data
immediately with the connection establishment, you aren't just
"shaving off a system call"; you are minimizing the idle time of the
IOCP...
On 6/19/2026 1:59 AM, Lawrence D’Oliveiro wrote:
I guess one can distinguish here what belongs in the VFS and shell, vs
On Fri, 19 Jun 2026 01:20:14 -0500, BGB wrote:
Maybe, but you wouldn't need "file://" for "fopen()" or similar,
since it is sort of an implied default in this case.
For an OS-level call, yes. But there are lots of higher-level toolkits
(particularly GUI-associated ones) that hook in a virtual-I/O layer
that allows accessing remote URLs as easily as opening local files.
what belongs in a file-browser or web browser.
As of yet, no file browser or web-browser, still basically at the level
of a very rudimentary GUI that has a shell window that can be used for
other programs.
What, no event loop?
A lot of normal programs use polling loops, but from the way
object-method dispatch works, it would not use a polling/loop or
event loop.
How would you distinguish between two floppy drives on a Unix-like
file system?
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.
They were a product of their time, but offer nothing going forward.
Copying the concept in any way for a new system is a daft idea.
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?...
That could be nice, at least for things that support a file and
directory model. It all depends on how you want to treat user
convenience, security, reliability, etc.
Or, would it be better to ask people to at least mount it into the VFS
or similar?...
You are likely to need a user name and password here somewhere.
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).
Like "fuse" on Linux (and similar things on other systems) ? Usermode
is the way to go for anything that is not speed critical.
Vs, say, assuming programs that export interfaces (as services) to be
at least semi trsusted / stable...
On Fri, 19 Jun 2026 13:42:56 -0700, Chris M. Thomasson wrote:
On 6/18/2026 4:03 PM, Lawrence D’Oliveiro wrote:
If saving the overhead of one system call is so significant,
perhaps you shouldn’t be using that OS for high-performance network
operations ...
Humm... I think you are missing the point? ConnectEx/AcceptEx has
the option to send/recv data. That's it.
That “that’s it” is precisely the point.
When you use ConnectEx or AcceptEx to send or receive data
immediately with the connection establishment, you aren't just
"shaving off a system call"; you are minimizing the idle time of the
IOCP...
If the userspace has to worry about keeping the kernel network stack
busy to that extent, then that’s another point in favour of the
simpler Linux way of doing things.
On Wed, 10 Jun 2026 00:24:35 -0700, Chris M. Thomasson wrote:
Windows I/O is unified and async across all device types — that’s
the whole point of IOCP.
Sure. That same sort of feature was integral both the previous OSes
Dave Cutler had a hand in: VAX/VMS and RSX-11.
If anything, Unix is the one still trying to catch up with a real
async model (see: io_uring).
You mean Linux? Yes, it did inherit the Unix idea of “all I/O is blocking”, so to do non-blocking calls you should spawn extra
processes -- or from the 1990s onwards, extra threads.
I agree, it might be nice to see a complete separation within the
kernel between I/O operation management and process scheduling.
But, let’s face it, even with the current model, Linux server
performance still leaves Windows for dead.
In article <1113t1c$3f4nm$2@dont-email.me>, Bart <bc@freeuk.com> wrote:
[...]
Google AI tells me: "[...]"
I don't think I've ever seen an instance where Google's AI is
right the first time.
What that really tells us is obviously something about AI-believers.Google AI tells me: "[...]"
[...]
Well, actually, a lot of people don't know how to use IOCP
efficiently. They also don't know how to program an efficient server
logic. On Linux, use io_uring. On Windows use IOCP.
I am talking about highly scalable servers under heavy load.
What is the analog of ConnectEx/AcceptEx on Linux?
On Fri, 19 Jun 2026 16:47:35 -0700, Chris M. Thomasson wrote:
Well, actually, a lot of people don't know how to use IOCP
efficiently. They also don't know how to program an efficient server
logic. On Linux, use io_uring. On Windows use IOCP.
If IOCP is the only way to achieve decent server performance on
Windows, no surprise that people find the *nix programming model
simpler.
And this is without even resorting to io_uring.
On Fri, 19 Jun 2026 16:40:07 -0700, Chris M. Thomasson wrote:
I am talking about highly scalable servers under heavy load.
So am I.
What is the analog of ConnectEx/AcceptEx on Linux?
Doesn’t need one. It can whip Windows’ arse quite nicely without it.
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) ...
But I've used a couple of DEC OSes and don't remember drive letters.
Google AI tells me: "Drive letters originate from the CP/M operating
system in the 1970s and were popularized by MS-DOS."
And this is without even resorting to io_uring.
io_uring is the way to go on Linux for high performance servers.
Actually, its more complicated than IOCP.
On 6/19/2026 7:50 PM, Lawrence D’Oliveiro wrote:
On Fri, 19 Jun 2026 16:40:07 -0700, Chris M. Thomasson wrote:
I am talking about highly scalable servers under heavy load.
So am I.
What is the analog of ConnectEx/AcceptEx on Linux?
Doesn’t need one. It can whip Windows’ arse quite nicely without it.
But it seems to have one? io_uring_enter... IORING_OP_ACCEPT and IORING_OP_CONNECT ?
Bart <bc@freeuk.com> writes:
On 19/06/2026 18:33, Keith Thompson wrote:
Bart <bc@freeuk.com> writes:
[...]
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?
I'd ask in a forum that discusses Unix-like systems, not one that
discusses the C programming language.
Here's the thing: this is thread that has been wildly off-topic for
nearly 100 posts, even aside from the other off-topic threads.
Yet you pick on MY post and tell only ME to move the discussion elsewhere.
perhaps it is because _you_ are most often the poster who
moves the thread off-topic?
On Fri, 19 Jun 2026 14:47:31 -0500, BGB wrote:
On 6/19/2026 1:59 AM, Lawrence D’Oliveiro wrote:
I guess one can distinguish here what belongs in the VFS and shell, vs
On Fri, 19 Jun 2026 01:20:14 -0500, BGB wrote:
Maybe, but you wouldn't need "file://" for "fopen()" or similar,
since it is sort of an implied default in this case.
For an OS-level call, yes. But there are lots of higher-level toolkits
(particularly GUI-associated ones) that hook in a virtual-I/O layer
that allows accessing remote URLs as easily as opening local files.
what belongs in a file-browser or web browser.
I should mention that Linux has a filesystem plugin API called FUSE,
which allows filesystem implementations to be done in userland. Not everything has to be a kernel module.
Example: secure remote access to filesystems on other machines via SSH <https://github.com/libfuse/sshfs>.
On 6/19/2026 7:49 PM, Lawrence D’Oliveiro wrote:
On Fri, 19 Jun 2026 16:47:35 -0700, Chris M. Thomasson wrote:
io_uring is the way to go on Linux for high performance servers.
Actually, its more complicated than IOCP.
Compared to Windows machines with its pseudorandom system for
assigning COM port numbers,
On 19/06/2026 18:33, Keith Thompson wrote:
Bart <bc@freeuk.com> writes:
[...]
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?
I'd ask in a forum that discusses Unix-like systems, not one that
discusses the C programming language.
Here's the thing: this is thread that has been wildly off-topic for
nearly 100 posts, even aside from the other off-topic threads.
Yet you pick on MY post and tell only ME to move the discussion elsewhere.
On Fri, 19 Jun 2026 17:25:01 +0200
David Brown <david.brown@hesbynett.no> wrote:
Compared to Windows machines with its pseudorandom system for
assigning COM port numbers,
There is a system in the madness. Behavior depends on either your USB-to-serial device has USB serial Id or lacks it.
If it has Id then the same port will be assigned to the same device regardless of the USB port that device plugged in this time.
Otherwise port number is assigned per USB port. Mostly.
Cheap FTDI clones tend to not implement serial ID.
Silicon Lab based converters tends to be of better quality, not just relatively to clones, but also relatively to genuine FTDI controllers.
On 21/06/2026 00:42, Michael S wrote:
On Fri, 19 Jun 2026 17:25:01 +0200
David Brown <david.brown@hesbynett.no> wrote:
Compared to Windows machines with its pseudorandom system for
assigning COM port numbers,
There is a system in the madness. Behavior depends on either your USB-to-serial device has USB serial Id or lacks it.
If it has Id then the same port will be assigned to the same device regardless of the USB port that device plugged in this time.
Otherwise port number is assigned per USB port. Mostly.
It is the "mostly" that is the killer.
The port numbers are usually stable if you plug the same devices into
the same physical ports. But sometimes if you have had a number of
new devices attached in the meantime, then go back to the old ones,
Windows might forget the previous numbers, or even re-use them, and
your old devices get new numbers. Mixing devices from different manufacturers appears to make things worse, but I have not done
extensive trials.
If you just have a few devices that you use regularly, it's okay - so
for most of our developers the port numbers don't get too high within
the lifetime of a useable Windows system. For some test machines
it's a different matter - when you build boards with a USB-to-serial
chip onboard, if those chips have serial numbers then you chew
through COM port numbers at an alarming rate. It is just one of many
reasons why we usually try to use Linux (especially Pi's) for test
machines.
Cheap FTDI clones tend to not implement serial ID.
Silicon Lab based converters tends to be of better quality, not just relatively to clones, but also relatively to genuine FTDI
controllers.
I don't remember ever using an FTDI clone - FTDI devices and cables
are not expensive enough for it to make sense for us. And FTDI
devices have worked fine for our needs. I have used a few Silicon
Labs devices too, but I don't see anything to suggest they are
"better quality" - pretty much every USB-to-serial converter from
every manufacturer works fine and does its job.
Some do cause more
pain with Windows then others, with different drivers and
requirements, but that's Windows and/or driver problems, and usually
those problems are surmountable. In the end, it is usually up to the customer - if they want a USB-to-serial converter on their board, and
they've picked a type, that's what they get. Given a free choice, we generally go for FTDI ourselves. (Most common is that boards have a
simple header with TTL signals and we use an external FTDI cable -
the biggest use of serial ports between boards and PC's is for
debugging and testing.)
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
On 6/19/2026 7:49 PM, Lawrence D’Oliveiro wrote:
On Fri, 19 Jun 2026 16:47:35 -0700, Chris M. Thomasson wrote:
io_uring is the way to go on Linux for high performance servers.
Actually, its more complicated than IOCP.
The posix asynchronous I/O facilities (e.g lio_listio(2)) were
used in the Oracle ODM (Operating System Dependent module)
of the RDMS product for high performance unix implementations
with lots of spindles more than a quarter century ago.
On Fri, 19 Jun 2026 19:53:15 -0700, Chris M. Thomasson wrote:
On 6/19/2026 7:50 PM, Lawrence D’Oliveiro wrote:
On Fri, 19 Jun 2026 16:40:07 -0700, Chris M. Thomasson wrote:
I am talking about highly scalable servers under heavy load.
So am I.
What is the analog of ConnectEx/AcceptEx on Linux?
Doesn’t need one. It can whip Windows’ arse quite nicely without it.
But it seems to have one? io_uring_enter... IORING_OP_ACCEPT and
IORING_OP_CONNECT ?
I can’t find anything that uses it.
On 6/19/2026 8:59 PM, Lawrence D’Oliveiro wrote:
On Fri, 19 Jun 2026 19:53:15 -0700, Chris M. Thomasson wrote:
On 6/19/2026 7:50 PM, Lawrence D’Oliveiro wrote:
On Fri, 19 Jun 2026 16:40:07 -0700, Chris M. Thomasson wrote:
I am talking about highly scalable servers under heavy load.
So am I.
What is the analog of ConnectEx/AcceptEx on Linux?
Doesn’t need one. It can whip Windows’ arse quite nicely without
it.
But it seems to have one? io_uring_enter... IORING_OP_ACCEPT and
IORING_OP_CONNECT ?
I can’t find anything that uses it.
So what does that mean? They are there, right?
On Sun, 21 Jun 2026 12:18:39 +0200
David Brown <david.brown@hesbynett.no> wrote:
On 21/06/2026 00:42, Michael S wrote:
On Fri, 19 Jun 2026 17:25:01 +0200
David Brown <david.brown@hesbynett.no> wrote:
Cheap FTDI clones tend to not implement serial ID.
Silicon Lab based converters tends to be of better quality, not just
relatively to clones, but also relatively to genuine FTDI
controllers.
I don't remember ever using an FTDI clone - FTDI devices and cables
are not expensive enough for it to make sense for us. And FTDI
devices have worked fine for our needs. I have used a few Silicon
Labs devices too, but I don't see anything to suggest they are
"better quality" - pretty much every USB-to-serial converter from
every manufacturer works fine and does its job.
I wish it was true.
Unfortunately I had seen misdesigned hardware more than one time,
including hardware from major manufactorer, like Aten.
One case I can not forget is USB-1.1 device that claimed to support
912 Kbps, but had 64-byte recieve and transmit queues. Of course, USB
polling rate is 1KHz, so it can't work even in theory, much less in
practice.
Some do cause more
pain with Windows then others, with different drivers and
requirements, but that's Windows and/or driver problems, and usually
those problems are surmountable. In the end, it is usually up to the
customer - if they want a USB-to-serial converter on their board, and
they've picked a type, that's what they get. Given a free choice, we
generally go for FTDI ourselves. (Most common is that boards have a
simple header with TTL signals and we use an external FTDI cable -
the biggest use of serial ports between boards and PC's is for
debugging and testing.)
As long as requirements are minimal, everything goes.
Try something just a little bit more demanding, like programming flash
on ST or TI microcontroller by means of vendor-supplied utility, and
many USB-to-serial converters will cause you problems.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,124 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 15:10:50 |
| Calls: | 14,380 |
| Files: | 186,385 |
| D/L today: |
1,432 files (605M bytes) |
| Messages: | 2,541,993 |