On 2024-08-18, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On 2024-08-17 23:51, Lawrence D'Oliveiro wrote:
>> On Sat, 17 Aug 2024 12:58:31 +0200, Dmitry A. Kazakov wrote:
>>
>>> Windows inter-process API are far more advanced than what UNIX ever had.
>>> It would be enough to mention famous file locks.
>>
>> Except those file locks are more of a liability than an asset.
>
> Like so many things in UNIX...
>
>> They are
>> what prevent you from continuing to use a Windows system while it is being
>> updated, for example.
>
> Windows mutex gets collected when the last process using it dies. UNIX
> file lock does not.

Windows mutexes are mainly useful only for ensuring the dubious feature of
allowing only one instance of an application to run.

If a mutex is actually used to protect shared data against concurrent
access, and the owner dies while holding the mutex, the next thread
to try to grab the mutex must be informed so it can try to recover
the shared data into a sane state.

POSIX process-shared mutexes have this "robust" feature as an option.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2024-08-18, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> If you want to compare Windows vs UNIX API, create a table and list
> commonly used process communication things. In the cells write the API
> call. E.g. mutex, pipe, pulse event etc.

PulseEvent is an unreliable API left over from 16 bit Windows.
It can only work meaningfully under cooperative multitasking on
a single processor.

Even Windows NT apologists from 1996 era comp.sys.os.advocacy
knew things like this; when/where were you beamed in from?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 18/08/2024 18:36, James Harris wrote:
> On 18/08/2024 15:55, David Brown wrote:
>
> ...
>
>> What does "static" mean inside square brackets in a C function prototype?
>
> I know there's a better newsgroup for it but, since you brought it up
> and it does also fit here, I should say that I had no idea that a C
> program could have square brackets in a function prototype and I cannot
> think of ever seeing such a thing.
>

I didn't mean we should go into detail about such features - it's just
an example of a feature of the core language of C that most C
programmers don't know about, and the lack of that knowledge does not
prevent them being able to write code in C. It is not a useful feature.

If you write "int foo(int xs[static 10]);", then it is undefined
behaviour to call "foo" with an argument that does not point to an array
of at least 10 elements (and it is therefore also UB to call it with a
null pointer). In theory, this could give a few more opportunities for
static error checking or optimisation. In practice, compilers will give
you exactly the same checks and optimisations without the "static".

> I presume you do mean C and not some sort of compiler extension.

Yes.

>
> As for static, IIRC labelling as "static" any external name (i.e. one
> not in a function) would make it private to the CU and not visible
> outside but that is just a guess.

It is also used for local variables in functions - these then have the
same scope as another local variable in the same place, but have
program-static lifetime.

But the use in array parameters is not related to either of these, and
is IMHO a potentially confusing and basically useless additional use of
the keyword.

(If anyone knows of it being useful in this context, please say so!)

>
> Or perhaps you meant a static formal parameter. Again, not something
> I've ever come across and would be curious as to what it meant.
>
> Would you care to say more about what you had in mind?
>
>

On 2024-08-18 18:52, Kaz Kylheku wrote:
> On 2024-08-18, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> If you want to compare Windows vs UNIX API, create a table and list
>> commonly used process communication things. In the cells write the API
>> call. E.g. mutex, pipe, pulse event etc.
>
> PulseEvent is an unreliable API left over from 16 bit Windows.

It has a race condition, yes. But the argument is "Green are the grapes."

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 2024-08-18 18:46, Kaz Kylheku wrote:

> If a mutex is actually used to protect shared data against concurrent
> access, and the owner dies while holding the mutex, the next thread
> to try to grab the mutex must be informed so it can try to recover
> the shared data into a sane state.

There is no recovery if a protected operation crashes, because the state
of the object is unknown.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

David Brown <david.brown@hesbynett.no> writes:
[...]
> Without looking it up, what does the C standard library "fegetmode"
> function do?

Nothing, it's specific to GNU libc.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

Muttley@dastardlyhq.com writes:
> Most (all?) versions of unix use copy-on-write when forking so while the
> processes are only reading its no different to threading. I doubt windows
> implements CoW since - in user space at least - it can't do fork and you
> wouldn't need it for executing a brand new process from scratch.

It does. It’s still a handy optimization for the mutable parts of
executables and (particularly) shared libraries even in the absence of
fork.

AIUI the kernel API gives you enough to implement fork (and that’s how
the POSIX subsystem worked when that was still a thing), but good luck
finding any public documentation about it.

> Windows sockets are not integers,

They are an unsigned integer type, I think 64 bits currently.

--
https://www.greenend.org.uk/rjk/

On Sun, 18 Aug 2024 10:10:09 +0200, Dmitry A. Kazakov wrote:

> On 2024-08-17 23:51, Lawrence D'Oliveiro wrote:
>
>> On Sat, 17 Aug 2024 12:58:31 +0200, Dmitry A. Kazakov wrote:
>>
>>> Windows inter-process API are far more advanced than what UNIX ever
>>> had. It would be enough to mention famous file locks.
>>
>> Except those file locks are more of a liability than an asset.
>
> Like so many things in UNIX...

People voluntarily choose to use Unix-type OSes. There’s a reason why
Unix-type OSes are the official de-facto standard in the computing world,
not Windows.

>> They are what prevent you from continuing to use a Windows system while
>> it is being updated, for example.
>
> Windows mutex gets collected when the last process using it dies. UNIX
> file lock does not.

What happens to a file lock when there is no file for it to lock?

>>> The reason why processes are not included is that they are used to
>>> deal with some OS or design flaw that forces you to spawn some script
>>> or application.
>>
>> Or because the *nix tradition of being able to spawn a pipeline of
>> multiple processes, all cooperating to perform a common task, is
>> difficult and expensive, or even unreliable, under Windows.
>
> It is as expensive under Windows as it is under UNIX.

No it isn’t. An example is Git, which initially was built around the fork-
multiple-processes model as with traditional *nix software, and ran fine
that way on Linux, but had to compromise on that idea a bit in order to
gain acceptance under Windows.

Remember, the current Windows (aka Windows NT) was masterminded by Dave
Cutler, who came from the nest of Unix-haters at DEC. He carried over many
of the characteristics of his last major brainchild there, VMS. One of
them is that creating multiple processes is expensive, so you try to avoid
it.

> Windows has a pipe object named and anonymous. No problem.

One problem: you can’t use them with poll/select calls.

> P.S. It is no wonder that Windows process API are far beyond UNIX.

Linux has clone(2). This can create regular POSIX-style processes, as well
as regular POSIX-style threads. And quite a few things in-between.

> On the other hand, Windows NT was developed by people influenced with
> the VMS design. VMS had a very elaborated process communication API.

And single drive letters?

> They usually require processes be able to run on different nodes.

Massive parallelism is something else Linux does better than Windows.

On Sun, 18 Aug 2024 18:13:37 +0200, Dmitry A. Kazakov wrote:

> Windows did many things wrong, but accessing file descriptors by numbers
> is beyond even Windows. In Windows a file is an OS object. You access it
> getting an opaque handle to. Note that a handle can be marshaled from
> one process to another. Try that with process-local numbers!

Actually, that is a standard feature of “Unix” sockets, as available on
Linux, the BSDs, and all the other *nixes: being able to pass file
descriptors for open files from one process to another.

["Followup-To:" header set to comp.unix.programmer.]
["Newsgroups:" comp.unix.shell has been dropped.]
with <v9pvoo$1sn55$1@dont-email.me> Dmitry A. Kazakov wrote:
> On 2024-08-17 11:01, Muttley@dastardlyhq.com wrote:
>> On Fri, 16 Aug 2024 15:02:20 -0000 (UTC)
>> kalevi@kolttonen.fi (Kalevi Kolttonen) gabbled:

>>> So it is indeed a vague question of what belongs in given
>>> programming languages.
>> Indeed. And this gives rise to inconsistency. Why is threading now
>> considered a core part of C++ but multi process isn't? Perhaps
>> because Windows is hopeless at the latter in user space but it could
>> just be personal preference within the C++ steering committee, who
>> knows.
> Windows inter-process API are far more advanced than what UNIX ever
> had. It would be enough to mention famous file locks. These days

But at what cost? (Hint: <CVE-2024-38063>.)

*SKIP* [ 6 lines 1 level deep]

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

On 2024-08-18, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On 2024-08-18 18:46, Kaz Kylheku wrote:
>
>> If a mutex is actually used to protect shared data against concurrent
>> access, and the owner dies while holding the mutex, the next thread
>> to try to grab the mutex must be informed so it can try to recover
>> the shared data into a sane state.
>
> There is no recovery if a protected operation crashes, because the state
> of the object is unknown.

That is false; the object's state can be analyzed and repaired. How
easily you can do that depends on the data structure and algorithms
used to manipulate it. Think of recoverable file systems.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2024-08-19 06:54, Kaz Kylheku wrote:
> On 2024-08-18, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On 2024-08-18 18:46, Kaz Kylheku wrote:
>>
>>> If a mutex is actually used to protect shared data against concurrent
>>> access, and the owner dies while holding the mutex, the next thread
>>> to try to grab the mutex must be informed so it can try to recover
>>> the shared data into a sane state.
>>
>> There is no recovery if a protected operation crashes, because the state
>> of the object is unknown.
>
> That is false; the object's state can be analyzed and repaired.

The object must be designed in a special way in order to support roll
backs etc. Such techniques exclude concurrent access, e.g. memory is
never overwritten etc.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 2024-08-19 01:14, Lawrence D'Oliveiro wrote:
> On Sun, 18 Aug 2024 10:10:09 +0200, Dmitry A. Kazakov wrote:
>
>> On 2024-08-17 23:51, Lawrence D'Oliveiro wrote:
>>
>>> On Sat, 17 Aug 2024 12:58:31 +0200, Dmitry A. Kazakov wrote:
>>>
>>>> Windows inter-process API are far more advanced than what UNIX ever
>>>> had. It would be enough to mention famous file locks.
>>>
>>> Except those file locks are more of a liability than an asset.
>>
>> Like so many things in UNIX...
>
> People voluntarily choose to use Unix-type OSes. There’s a reason why
> Unix-type OSes are the official de-facto standard in the computing world,
> not Windows.

Both OSes contributed to the Dark Ages of computing. The reasons are not
technical, because both were worst on the market. The similar process
happened with programming languages, e.g. C and with the hardware
architectures, e.g. x86. It is always a race to the bottom...

>>> They are what prevent you from continuing to use a Windows system while
>>> it is being updated, for example.
>>
>> Windows mutex gets collected when the last process using it dies. UNIX
>> file lock does not.
>
> What happens to a file lock when there is no file for it to lock?

Windows does not use lock files. Under Linux you must log in as the root
and remove the stray file lock manually. It happens in UNIX
administration all the time.

> Remember, the current Windows (aka Windows NT) was masterminded by Dave
> Cutler, who came from the nest of Unix-haters at DEC. He carried over many
> of the characteristics of his last major brainchild there, VMS. One of
> them is that creating multiple processes is expensive, so you try to avoid
> it.

A wise decision. The look of UNIX SysV process list was a sheer horror
to any user of RSX or VMS. No wonder UNIX was many times slower on same
machines. A VMS 1Mb machine supported 4 users running an interactive IDE
sessions (in LSE). UNIX users enjoyed Vi and permanent fatal crashes.
The early filesystem rewrote the master block, so after the crash you
could not boot anymore and have to restore the system from the tape.
Under RSX you could turn the main disk off and on without reboot.

The reason why Windows NT could no compete Linux on servers is
unbearable maintenance and being fat. Linux had a monolithic kernel. I
compiled it for each machine to include only drivers I needed. I did not
install X11 stuff. The result was twice leaner than Windows NT.

On the other hand you still cannot have decent gaming under Linux.

>> Windows has a pipe object named and anonymous. No problem.
>
> One problem: you can’t use them with poll/select calls.

You can. See overlapped I/O.

>> P.S. It is no wonder that Windows process API are far beyond UNIX.
>
> Linux has clone(2). This can create regular POSIX-style processes, as well
> as regular POSIX-style threads. And quite a few things in-between.
>
>> On the other hand, Windows NT was developed by people influenced with
>> the VMS design. VMS had a very elaborated process communication API.
>
> And single drive letters?

They are dozens characters long actually, if you mean the device names.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 18/08/2024 21:24, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> Without looking it up, what does the C standard library "fegetmode"
>> function do?
>
> Nothing, it's specific to GNU libc.
>

(This has been discussed in a follow-up in comp.lang.c, but others here
might not see that.)

The function is in standard C23, but not earlier C standard versions.
C23 has not yet been adopted by ISO (it is due in a couple of months),
so "fegetmode" is not part of current standard C. But it will be soon.

Anyway, the point is that most C programmers can write useful C code
without knowing about such functions. I didn't intend to pick a new C23
function as an example, just a relatively obscure C standard library
function, and the standard version I happened to have open at the time
was C23.

On Sun, 18 Aug 2024 18:13:37 +0200
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> boringly babbled:
>On 2024-08-18 17:45, Muttley@dastardlyhq.com wrote:
>> On Sun, 18 Aug 2024 12:19:10 +0200
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> boringly babbled:
>>> On 2024-08-18 10:30, Muttley@dastardlyhq.com wrote:
>>>
>>>> The windows process API is crippled which is why threading is the main
>>>> parallel processing method in Windows and has been since 3.0.
>>>
>>> Threading is the main method because of its performance in a tight
>>> coupled application. Crossing the process borders is very expensive.
>>
>> Most (all?) versions of unix use copy-on-write when forking
>
>You seems do not understand that spawning a process is not an issue of
>interprocess communications. It is synchronization, e.g. events, mutexes
>which is.

Huh? I'm talking about the cost of spawning a CoW process vs a thread.

>> Also shared memory is pretty cheap too.
>
>Again, you need to synchronize in order to access shared objects, not to
>mention elaboration of such objects, e.g. calling constructors and
>destructors. With threads there is a linker support in most languages.
>With processes you are on your own.

No idea what you're talking about. Wtf have constructors and destructors
got to do with forking a process? A process fork involves creating a new
process table entry with a copy of all the parents memory page pointers and
thats pretty much it, until the child process starts to change some page data
then CoW kicks in.

>In the same library you might find portable implementation of basic
>communication objects and compare Windows vs Linux vs BSD implementations:
>
> http://www.dmitry-kazakov.de/ada/components.htm#12
>
>> No idea what the pages of all that crap is.
>
>Hmm, if you ever dealt with networking applications you should have had
>some idea...

I've probably written more network applications than you can imagine and
the networking functionality side - on unix - is usually pretty simple (unless
you have to use OpenSSL then things can get tricky). I don't know why you would
need all those pages of code just to handle sockets.

>> Windows sockets are not integers ,
>
>Windows did many things wrong, but accessing file descriptors by numbers
>is beyond even Windows. In Windows a file is an OS object. You access it
>getting an opaque handle to. Note that a handle can be marshaled from
>one process to another. Try that with process-local numbers!

Open sockets are inherited by the child process after fork(). No marshalling
nonsense required.

>> they can't be multiplexed with file
>> descriptors, pipes etc in a single call.
>
>Of course it can. Windows overlapped I/O supports sockets.

Not last time I tried it (2019) it didn't.

>> Like what? Why does the OS need to manage "objects"?
>
>Like a graphic context or a mutex. Things that leak if the process dies
>unless the OS takes care of.

Unix uses X11 (or wayland if you're unlucky) for graphics - even MacOS with
XQuartx installed. When the process dies all its graphics contexts die with it
and the OS is not involved.

>> I'm not talking about now, I was talking about when NT came out. Learn to
>> read.
>
>Honestly I do not know what you are talking about. The option to change
>the scheduling interval existed in Windows NT.

*sigh* Never mind.

>If you want to compare Windows vs UNIX API, create a table and list
>commonly used process communication things. In the cells write the API
>call. E.g. mutex, pipe, pulse event etc.

I have something called "a life" so no, I'm not wasting hours just to keep
some random poster happy. I'm sure someone has already done it and it can be
googled.

On 19/08/2024 09:37, Dmitry A. Kazakov wrote:
> On 2024-08-19 01:14, Lawrence D'Oliveiro wrote:
>> On Sun, 18 Aug 2024 10:10:09 +0200, Dmitry A. Kazakov wrote:
>>
>>> On 2024-08-17 23:51, Lawrence D'Oliveiro wrote:
>>>
>>>> On Sat, 17 Aug 2024 12:58:31 +0200, Dmitry A. Kazakov wrote:
>>>>
>>>>> Windows inter-process API are far more advanced than what UNIX ever
>>>>> had. It would be enough to mention famous file locks.
>>>>
>>>> Except those file locks are more of a liability than an asset.
>>>
>>> Like so many things in UNIX...
>>
>> People voluntarily choose to use Unix-type OSes. There’s a reason why
>> Unix-type OSes are the official de-facto standard in the computing world,
>> not Windows.
>
> Both OSes contributed to the Dark Ages of computing. The reasons are not
> technical, because both were worst on the market.

What sort of time-frame are you thinking of here, what were the
alternatives that you think were "better", what markets or uses are you
considering, and in what way were other OS's "better" ?

There's no doubt that non-technical issues have had a big influence on
which OS's or types of OS have succeeded, but you seem to have something
specific in mind.

> The similar process
> happened with programming languages, e.g. C and with the hardware
> architectures, e.g. x86. It is always a race to the bottom...
>

The success of the x86 was very much a race to the bottom - it was
picked specifically to give a cheaper system rather than the technically
superior architecture (m68k) preferred by the engineers. Momentum and
backwards compatibility has kept it going ever since.

I am not as convinced with respect to C. It certainly has its flaws,
and it certainly has been, and continues to be, used in situations where
it is not a good choice of language. But I think much of the bad
reputation of C is the result of poor C programmers and poor use of the
language, rather than the language itself. Good programmers will write
good code in any language, bad programmers (or badly managed
programmers) will write bad code in any language.

>>>> They are what prevent you from continuing to use a Windows system while
>>>> it is being updated, for example.
>>>
>>> Windows mutex gets collected when the last process using it dies. UNIX
>>> file lock does not.
>>
>> What happens to a file lock when there is no file for it to lock?
>
> Windows does not use lock files.

Windows has locks on files, which are a different thing. While I can
understand the point of them, they can be a real inconvenience (try
deleting a directory tree when a file from that tree is in use).

> Under Linux you must log in as the root
> and remove the stray file lock manually. It happens in UNIX
> administration all the time.

As someone who has administrated Linux servers for decades, and used it
as my desktop OS on many machines, I am not sure I can ever remember
removing a stray lock file. Certainly needing to do so "all the time"
is a very wild exaggeration. Linux, like all systems, undoubtedly has
its flaws and weaknesses, but this is not one of them IME.

>
>> Remember, the current Windows (aka Windows NT) was masterminded by Dave
>> Cutler, who came from the nest of Unix-haters at DEC. He carried over
>> many
>> of the characteristics of his last major brainchild there, VMS. One of
>> them is that creating multiple processes is expensive, so you try to
>> avoid
>> it.
>
> A wise decision. The look of UNIX SysV process list was a sheer horror
> to any user of RSX or VMS. No wonder UNIX was many times slower on same
> machines. A VMS 1Mb machine supported 4 users running an interactive IDE
> sessions (in LSE). UNIX users enjoyed Vi and permanent fatal crashes.
> The early filesystem rewrote the master block, so after the crash you
> could not boot anymore and have to restore the system from the tape.
> Under RSX you could turn the main disk off and on without reboot.
>

Times change. Needs and uses change. Hardware changes.

Keeping things separate and modular has advantages in scalability,
security and stability. Keeping things monolithic has advantages in
efficiency (speed and memory) and consistency. There is no "right" answer.

> The reason why Windows NT could no compete Linux on servers is
> unbearable maintenance and being fat. Linux had a monolithic kernel. I
> compiled it for each machine to include only drivers I needed. I did not
> install X11 stuff. The result was twice leaner than Windows NT.
>
> On the other hand you still cannot have decent gaming under Linux.
>

I do almost all my gaming under Linux. Some games do work better under
Windows, but that is primarily because most games developers target
Windows as their main platform. It may also be because Linux systems
are more varied.

>>> Windows has a pipe object named and anonymous. No problem.
>>
>> One problem: you can’t use them with poll/select calls.
>
> You can. See overlapped I/O.
>
>>> P.S. It is no wonder that Windows process API are far beyond UNIX.
>>
>> Linux has clone(2). This can create regular POSIX-style processes, as
>> well
>> as regular POSIX-style threads. And quite a few things in-between.
>>
>>> On the other hand, Windows NT was developed by people influenced with
>>> the VMS design. VMS had a very elaborated process communication API.
>>
>> And single drive letters?
>
> They are dozens characters long actually, if you mean the device names.
>

I thought by "drive letters", he meant "drive letters" - "c:", "d:", etc.

On Mon, 19 Aug 2024 09:37:39 +0200, Dmitry A. Kazakov wrote:

> On 2024-08-19 01:14, Lawrence D'Oliveiro wrote:
>
> Both OSes contributed to the Dark Ages of computing. The reasons are not
> technical, because both were worst on the market.

To paraphrase Winston Churchill: “Unix is the worst OS in the world ...
apart from all the others.”

> Windows does not use lock files.

*nix systems don’t need them either.

> The reason why Windows NT could no compete Linux on servers is
> unbearable maintenance and being fat. Linux had a monolithic kernel. I
> compiled it for each machine to include only drivers I needed. I did not
> install X11 stuff. The result was twice leaner than Windows NT.

You don’t think the design of Windows NT contributed to that failure?

> On the other hand you still cannot have decent gaming under Linux.

Actually, you can. Look at the Steam Deck, which runs a purpose-built GUI
for handheld gaming. Microsoft has been talking about bringing out a
Windows “Handheld Mode” for about two years now, but still has nothing to
ship.

>> On Sun, 18 Aug 2024 10:10:09 +0200, Dmitry A. Kazakov wrote:
>>
>>> Windows has a pipe object named and anonymous. No problem.
>>
>> One problem: you can’t use them with poll/select calls.
>
> You can. See overlapped I/O.

I said “poll/select calls”. Do you not know what those are? On Windows,
they work with sockets, but not with pipes. Or even ordinary files. So
unlike *nix systems, you have to keep in mind the different kinds of files
you might be working with.

>> And single drive letters?
>
> They are dozens characters long actually, if you mean the device names.

Drive names are only single letters. You’re not talking about reserved
file names, are you?

On 2024-08-19 10:40, David Brown wrote:
> On 19/08/2024 09:37, Dmitry A. Kazakov wrote:

>> Both OSes contributed to the Dark Ages of computing. The reasons are
>> not technical, because both were worst on the market.
>
> What sort of time-frame are you thinking of here, what were the
> alternatives that you think were "better", what markets or uses are you
> considering, and in what way were other OS's "better" ?
>
> There's no doubt that non-technical issues have had a big influence on
> which OS's or types of OS have succeeded, but you seem to have something
> specific in mind.

I think the main reason is that we do not pay the actual costs of
software developing. OS, compiler require huge investments. Vendors
never passed these to the end users funding developing from other
sources. That effectively killed the market. Free software only
aggravated the situation. In effect it is akin to the socialist
production method which always kills quality.

> Windows has locks on files, which are a different thing.  While I can
> understand the point of them, they can be a real inconvenience (try
> deleting a directory tree when a file from that tree is in use).

Oh, yes! I understand why I should not remove a locked file, but I still
enjoy Linux's ability to remove anything an be it all damned!

The usual case is when Windows locks some file on the Linux Samba server
share for some mysterious reason. It is a sheer fun to log into the
server do "rm -rf" on the file and then go back to Windows: "eat that!"

>> Under Linux you must log in as the root and remove the stray file lock
>> manually. It happens in UNIX administration all the time.
>
> As someone who has administrated Linux servers for decades, and used it
> as my desktop OS on many machines, I am not sure I can ever remember
> removing a stray lock file.  Certainly needing to do so "all the time"
> is a very wild exaggeration.  Linux, like all systems, undoubtedly has
> its flaws and weaknesses, but this is not one of them IME.

In main case it is packet manager. I am too lazy to find how to turn off
automatic update checks. So when I try to run apt or dnf I have to kill
the lock.

> Times change.  Needs and uses change.  Hardware changes.
>
> Keeping things separate and modular has advantages in scalability,
> security and stability.  Keeping things monolithic has advantages in
> efficiency (speed and memory) and consistency.  There is no "right" answer.

Yes. E.g. in automotive you still need the system booted right after you
turned the key.

Initially an ability to trim the system and sometimes to patch a driver
was a huge advantage Linux had over Windows NT.

>> On the other hand you still cannot have decent gaming under Linux.
>
> I do almost all my gaming under Linux.  Some games do work better under
> Windows, but that is primarily because most games developers target
> Windows as their main platform.  It may also be because Linux systems
> are more varied.

"You are in an open field on the west side of a white house with a
boarded front door." That sort of games? (:-))

>>> And single drive letters?
>>
>> They are dozens characters long actually, if you mean the device names.
>
> I thought by "drive letters", he meant "drive letters" - "c:", "d:", etc.

The official file name of "C:" would be some messy string with lots of
backslashes. C: is a "DOS name." There are API to convert DOS names into
proper names. It is a mess. All Windows API is a mess.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 2024-08-19 10:45, Lawrence D'Oliveiro wrote:
> On Mon, 19 Aug 2024 09:37:39 +0200, Dmitry A. Kazakov wrote:
>
>> The reason why Windows NT could no compete Linux on servers is
>> unbearable maintenance and being fat. Linux had a monolithic kernel. I
>> compiled it for each machine to include only drivers I needed. I did not
>> install X11 stuff. The result was twice leaner than Windows NT.
>
> You don’t think the design of Windows NT contributed to that failure?

No. The design of Windows HAL was great. It is rather the business model
Microsoft pursued.

>> On the other hand you still cannot have decent gaming under Linux.
>
> Actually, you can. Look at the Steam Deck, which runs a purpose-built GUI
> for handheld gaming.

Well, handheld gaming to gaming is like masturbation to love. Sorry...

Microsoft has been talking about bringing out a
> Windows “Handheld Mode” for about two years now, but still has nothing to
> ship.
>
>>> On Sun, 18 Aug 2024 10:10:09 +0200, Dmitry A. Kazakov wrote:
>>>
>>>> Windows has a pipe object named and anonymous. No problem.
>>>
>>> One problem: you can’t use them with poll/select calls.
>>
>> You can. See overlapped I/O.
>
> I said “poll/select calls”. Do you not know what those are? On Windows,
> they work with sockets, but not with pipes. Or even ordinary files. So
> unlike *nix systems, you have to keep in mind the different kinds of files
> you might be working with.

Again. It is called overlapped I/O. You can start multiple
*asynchronous* I/O operations from a thread. It can be done on any sets
of file handles. When an I/O event happens on a handle the corresponding
event gets signaled. select() behavior is achieved by
WaitForMultipleObjects that waits for multiple events. Then you check
the overlapped results. If you never wait and only check the overlapped
results that would be polling.

>>> And single drive letters?
>>
>> They are dozens characters long actually, if you mean the device names.
>
> Drive names are only single letters. You’re not talking about reserved
> file names, are you?

No, I am talking about proper file paths under Windows. Letters is a DOS
layer on top of it. E.g. see QueryDosDeviceW call.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 19/08/2024 09:40, David Brown wrote:
> On 19/08/2024 09:37, Dmitry A. Kazakov wrote:

>> The similar process happened with programming languages, e.g. C and
>> with the hardware architectures, e.g. x86. It is always a race to the
>> bottom...
>>
>
> The success of the x86 was very much a race to the bottom - it was
> picked specifically to give a cheaper system rather than the technically
> superior architecture (m68k) preferred by the engineers.  Momentum and
> backwards compatibility has kept it going ever since.
>
> I am not as convinced with respect to C.  It certainly has its flaws,
> and it certainly has been, and continues to be, used in situations where
> it is not a good choice of language.  But I think much of the bad
> reputation of C is the result of poor C programmers and poor use of the
> language, rather than the language itself.

It is the language itself. So many stupid quirks which ended up as
indispensible 'features' which meant you had to keep them forever.

Features which, granted that C is generally considered unsafe, just make
it stupidly unsafe.

Plus not helped by tooling which insists on allowing ancient, unsafe
practices by default so that again, bad habits and uses of unsafe
features are perpetuated.

(You of course will insist that such tools must only used with an
appropriate set of options to tune the language dialect to safer one.

In that case, you surely wouldn't object to defaulting to a safer
dialect and requiring an option to build legacy code.)

> Good programmers will write
> good code in any language, bad programmers (or badly managed
> programmers) will write bad code in any language.

C makes it considerably easier. I can't reproduce this in my language
for example:

int F() {
F(1,2.3,"four",F,F());
}

gcc 14.1.0 passes this by default.

Or this:

void G(int* p) {p[12345];}

int main() {
int i=0;
G(&i);

int (*A)[10];

*(A[i]); // index then deref is valid (this one is wrong)
(*A)[i]; // so is deref then index!

}

Again, gcc 14.1.0 passes it. (If pushed, it will report things like
'statement with no effect' or missing initialisation. I can fix those,
but the program is still likely to crash if run.)

On Mon, 19 Aug 2024 12:39:33 +0200
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> boringly babbled:
>On 2024-08-19 10:40, David Brown wrote:
>> On 19/08/2024 09:37, Dmitry A. Kazakov wrote:
>> There's no doubt that non-technical issues have had a big influence on
>> which OS's or types of OS have succeeded, but you seem to have something
>> specific in mind.
>
>I think the main reason is that we do not pay the actual costs of
>software developing. OS, compiler require huge investments. Vendors
>never passed these to the end users funding developing from other
>sources. That effectively killed the market. Free software only
>aggravated the situation. In effect it is akin to the socialist
>production method which always kills quality.

You are a comedian arn't you. Its not a good idea to criticise the quality
of OSS when at the same time advocating for Windows, an OS thats had more
security holes than the entire cheese production of switzerland.

>Initially an ability to trim the system and sometimes to patch a driver
>was a huge advantage Linux had over Windows NT.

Linux can also load and unload drivers on the fly unlike Windows which AFAIK
still requires a reboot each time.

On 2024-08-19 16:59, Muttley@dastardlyhq.com wrote:
> On Mon, 19 Aug 2024 12:39:33 +0200

>> Initially an ability to trim the system and sometimes to patch a driver
>> was a huge advantage Linux had over Windows NT.
>
> Linux can also load and unload drivers on the fly unlike Windows which AFAIK
> still requires a reboot each time.

I was talking about monolithic kernel Linux had in 90's. Plug and play,
kernel modules came much later with much bigger machines. I ran Linux on
i386 25MHz 4Mb. Try it now.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On Mon, 19 Aug 2024 17:35:46 +0200
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> boringly babbled:
>On 2024-08-19 16:59, Muttley@dastardlyhq.com wrote:
>> On Mon, 19 Aug 2024 12:39:33 +0200
>
>>> Initially an ability to trim the system and sometimes to patch a driver
>>> was a huge advantage Linux had over Windows NT.
>>
>> Linux can also load and unload drivers on the fly unlike Windows which AFAIK
>> still requires a reboot each time.
>
>I was talking about monolithic kernel Linux had in 90's. Plug and play,
>kernel modules came much later with much bigger machines. I ran Linux on
>i386 25MHz 4Mb. Try it now.

Loadable driver modules have been in linux since kernel 1.1 which was mid
90s.

On 2024-08-19, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On 2024-08-19 06:54, Kaz Kylheku wrote:
>> On 2024-08-18, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>> On 2024-08-18 18:46, Kaz Kylheku wrote:
>>>
>>>> If a mutex is actually used to protect shared data against concurrent
^^^^^^^^^^^^^^^^^^^^^^
>>>> access, and the owner dies while holding the mutex, the next thread
>>>> to try to grab the mutex must be informed so it can try to recover
>>>> the shared data into a sane state.
>>>
>>> There is no recovery if a protected operation crashes, because the state
>>> of the object is unknown.
>>
>> That is false; the object's state can be analyzed and repaired.
>
> The object must be designed in a special way in order to support roll
> backs etc. Such techniques exclude concurrent access, e.g. memory is
^^^^^^^^^^^^^^^^^^^^^^^^^^
> never overwritten etc.

Doh.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 19/08/2024 12:39, Dmitry A. Kazakov wrote:
> On 2024-08-19 10:40, David Brown wrote:
>> On 19/08/2024 09:37, Dmitry A. Kazakov wrote:
>
>>> Both OSes contributed to the Dark Ages of computing. The reasons are
>>> not technical, because both were worst on the market.
>>
>> What sort of time-frame are you thinking of here, what were the
>> alternatives that you think were "better", what markets or uses are
>> you considering, and in what way were other OS's "better" ?
>>
>> There's no doubt that non-technical issues have had a big influence on
>> which OS's or types of OS have succeeded, but you seem to have
>> something specific in mind.
>
> I think the main reason is that we do not pay the actual costs of
> software developing. OS, compiler require huge investments. Vendors
> never passed these to the end users funding developing from other
> sources. That effectively killed the market. Free software only
> aggravated the situation. In effect it is akin to the socialist
> production method which always kills quality.

Experience shows that commercial software vendors rarely passed the real
costs on to the users - they often pass vastly higher charges on to the
user for software than it cost to develop the software. Other times,
they might charge very little or nothing because they have other sources
of income, such as giving away the main software and charging
subscription fees for add-on features. There are all sorts of models -
free and open source software provides different models. At my company,
the software we write is closed source, but we never charge for licenses
for it. Customers either pay for the time used in development, or they
pay for it as part of the cost of the electronics boards we make for them.

If you use, for example, gcc or Linux, you don't pay the costs directly.
But you /do/ pay them indirectly. The solid majority of development
for major free and open source projects is paid work. Intel and ARM pay
developers to work on gcc - every time you buy a device with an Intel or
ARM processor in it, you are paying a little towards gcc. Google pays
for Linux development - every time you buy a new pair of shoes, some of
what you pay goes to the manufacturer's advertising budget, some of
which goes to Google, some of which goes to Linux development, so that
Google's servers can use a steadily better quality OS to serve up those
adverts.

It all goes around - there's always money there, somewhere.

Just like any other kind of competition, free and open source has been
disruptive in many software markets where some companies were used to
spending some money on development, then living off that software for
years as nearly pure profit. It has forced other companies to change
models - making their software better, or providing better support. But
it hasn't killed the good quality, imaginative and flexible software
companies. In the embedded development world, there are large numbers
of compilers available at a range of prices because they offer something
that pure gcc does not - support, certification, additional tools,
training, libraries, specialised extra features, or whatever. Other
companies exist by taking gcc (or clang) and adding more and charging
for it. These markets were not /killed/ by free and open source
compilers - they were /created/ by them.

And customer companies - successful, well-run ones at least - are still
quite happy to pay a lot of money for software if it does a better job
than equivalent free software, saving them money in the end. At my
company we have bought compilers when they were better tools for the job
than free tools. But they have to be /better/ - not just more
expensive, and they have to be better enough to justify the price.
Usually, they are not.

So no, free and open source development does not "kill quality" or "kill
markets". It is often /better/ quality than commercial alternatives, at
least in some ways, and it forces commercial alternatives to improve
their quality and cost-effectiveness. It does not /kill/ markets - it
/changes/ them. It spells the end for some suppliers, and opens up
opportunities for new ones, just like progress always does.

People who complain about how free and open source software has killed
their businesses are like saddle-makers sitting about complaining about
how the car killed their markets, while their competitors have switched
from making saddles to opening car repair shops.

>
>> Windows has locks on files, which are a different thing.  While I can
>> understand the point of them, they can be a real inconvenience (try
>> deleting a directory tree when a file from that tree is in use).
>
> Oh, yes! I understand why I should not remove a locked file, but I still
> enjoy Linux's ability to remove anything an be it all damned!
>
> The usual case is when Windows locks some file on the Linux Samba server
> share for some mysterious reason. It is a sheer fun to log into the
> server do "rm -rf" on the file and then go back to Windows: "eat that!"
>
>>> Under Linux you must log in as the root and remove the stray file
>>> lock manually. It happens in UNIX administration all the time.
>>
>> As someone who has administrated Linux servers for decades, and used
>> it as my desktop OS on many machines, I am not sure I can ever
>> remember removing a stray lock file.  Certainly needing to do so "all
>> the time" is a very wild exaggeration.  Linux, like all systems,
>> undoubtedly has its flaws and weaknesses, but this is not one of them
>> IME.
>
> In main case it is packet manager. I am too lazy to find how to turn off
> automatic update checks. So when I try to run apt or dnf I have to kill
> the lock.

Right... so your big complaint against Linux is actually due to your own
laziness and weird way of updating your system. (Like many Linux users,
I have automatic update checks enabled /and/ I use "apt" or other
package managers when I want to - without problems with lock files.)

>
>> Times change.  Needs and uses change.  Hardware changes.
>>
>> Keeping things separate and modular has advantages in scalability,
>> security and stability.  Keeping things monolithic has advantages in
>> efficiency (speed and memory) and consistency.  There is no "right"
>> answer.
>
> Yes. E.g. in automotive you still need the system booted right after you
> turned the key.
>
> Initially an ability to trim the system and sometimes to patch a driver
> was a huge advantage Linux had over Windows NT.
>

It still is, for those with such niche needs that it is worth the effort.

>>> On the other hand you still cannot have decent gaming under Linux.
>>
>> I do almost all my gaming under Linux.  Some games do work better
>> under Windows, but that is primarily because most games developers
>> target Windows as their main platform.  It may also be because Linux
>> systems are more varied.
>
> "You are in an open field on the west side of a white house with a
> boarded front door." That sort of games? (:-))
>

No, RTS, FPS, that sort of thing. I don't do a lot of fast-action
gaming these days - my reactions are not those of a kid any more! And
my PC is not optimised for very demanding games. But most (80%+) Steam
games run as well on Linux as on Windows, on the same hardware. I see
some games have trouble on Linux, and some run better (especially older
ones that find modern Windows confusing).

Overall, if someone wanted a pure gaming PC, I'd recommend Windows over
Linux - but it's absolutely fine for casual gaming.

>>>> And single drive letters?
>>>
>>> They are dozens characters long actually, if you mean the device names.
>>
>> I thought by "drive letters", he meant "drive letters" - "c:", "d:", etc.
>
> The official file name of "C:" would be some messy string with lots of
> backslashes. C: is a "DOS name." There are API to convert DOS names into
> proper names. It is a mess. All Windows API is a mess.
>

The file path the user sees regularly starts with a driver letter.
Users don't see API's.

It is a /long/ time since I have had to deal much with Windows APIs
directly. I remember such joys as a "CreateFile" call that you needed
to do things like open a comms port or handles to many other types of
devices or interfaces, but which was not useable for creating files.
These days my Windows programming is almost all in Python - so dealing
with the API is an SEP.