On 12/29/24 08:07, Kalevi Kolttonen wrote:
....
> Without my hack, the build process took four hours to complete
> and it produced a working TB. However, with my tiny JavaScript
> modification, the build failed.
>
> Because these builds take four hours, I have to admit defeat.
> I simply do not have the time to make more modification
> attempts.
>
> What is more, James Kuyper said that he does not want to
> build his own TB so it was all in vain anyway.

Your efforts were not entirely wasted - your (lack of) results make me
even less willing to build my own. :-}

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> Muttley@dastardlyhq.com wrote:
>> gazelle@shell.xmission.com (Kenny McCormack) gabbled:
>>> Rust seems to be, like Python, trying to ingratiate itself into the
>>> basic running of the system, not just be a peripheral "scripting
>>> language".
>>
>> Requiring 2 seperate compilers to build anything is an absurdity.
>
> (Disclaimer: I skipped most of the sub-thread, so if that generalizing
> sentence was addressing some peculiar (maybe even TB-related) software
> specialities you may ignore the rest of my post.)
>
> From my experience it's no "absurdity" but actual (sensible) normality
> to use multiple compilers and other software generators in SW-projects.

Agreed.

Thunderbird is not a surprising place to find some Rust; Mozilla
sponsored Rust in the hope of escaping the memory safety issues of
C/C++.

> It seems that depends on the software architecture. It's (IMO) fine to
> create libraries that are combined in an "anything" to be compiled
> with the (at the time of their creation) most appropriate
> compiler. It's also fine if you use a second language as a
> higher-level intermediate language. Also if you create the "anything"
> based on several components (or subsystems) that are combined. Using
> separate protocol compilers is also not uncommon to get the transfer
> objects and functions. Also using own compilers for the accompanying
> parts like documentation is typical. (All these examples just off the
> top of my head from some professional projects that I observed or was
> engaged with.)

Off the top of my head there are at least twelve languages in my current
employer’s codebase. More if you count things like documentation markup.

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

On Sun, 12/29/2024 9:32 AM, Kenny McCormack wrote:
> In article <vkrfue$vl1b$1@dont-email.me>, Paul <nospam@needed.invalid> wrote:
> ...
>> Is the whole thing obscene ? Yes. You won't find too many
>> software creations, this distorted. Still, people are using it.
>> Most people are not aware what is under the hood. It's
>> a herd of elephants :-)
>
> Just out curiosity, does all of this apply to the Windows version as well?
>
> I know this thread is mostly about the Linux version, and although I
> actually don't use TB at all, I know someone who uses the Windows version.
>

It's a FOSS software that compiles on multiple platforms.

Just as Firefox (which is most of the code inside after all),
is FOSS software that compiles on multiple platforms.
There's even a Firefox.dmg for example, for a Mac computer.
I don't keep track of how many platforms it supports.

One way to do this, is to, say, use OpenGL for graphics, as
OpenGL was available in lots of places. But, they don't do
that, not exactly. On Windows, the Google ANGLE driver is
used, which converts something like Direct3D, into an emulation
of OpenGL. And later, Google may have added WebGL or something.
The Firefox graphics runs at 20% speed on Windows, compared to
Linux, and it has something to do with the different means
of getting a working WebGL. There could have been support provided
by graphics card drivers, a more direct path, but they didn't use that.

In fact, the Mozilla graphics designer, is more than a bit annoyed
about just how many graphics standards and APIs that ended up supported.
Any notion of Keeping It Simple, went out the window long ago.
I'm impressed it works as well as it does.

Like the design of the iceburg, the news and email code is
the 10% that floats above the water line. While the huge mass
of cross-platform-ready code underneath for Firefox, does the
rendering.

If you have ever examined the tarball for a copy of Firefox
or Thunderbird, you will develop new respect for it. In the
sense that, somehow, a team of people corralled 400,000 files
of various types and made something that sorta works out of it.
How many projects do you know of, that have 400,000 files in the
tree ? Many of the files are test benches, for detecting
regressions when minor code changes are made.

One day, I was sick of line ending problems, so I made a little
project out of converting (400K files) to something common I could use.
Before doing this, I did a scan with the Linux "file" command first,
to get a declaration of the couple text file formats I was expecting.
When I sorted all the declarations found, there were *100 text file formats*
in the tree. For one particular file, if you change the line endings
in any way, it triggers a bug in the compiler, and you don't get
your build. And that's what I mean by the herd of elephants thing,
there are extensive amounts of excrement down there, and don't
step in it. It's real easy to think you can kick the tree around, when
it doesn't actually accept abuse as a tree.

One day, I used Visual Studio, and a debug build, to single-step
Firefox through a Print routine. As IDE windows opened and closed,
I noticed I had traversed three source files, source files which
modified some common print settings, but not the exact same set of
common settings. It seemed there were three routines running
sequentially, and presumably the last one executing, was the "latest version".
The two moribund versions of code, having never been removed.

And that's how you manage 400,000 files in a tree. Careful
where you step!

Paul

kalevi@kolttonen.fi (Kalevi Kolttonen) writes:

> Eric Pozharski <apple.universe@posteo.net> wrote:
>> Yay! The joy of building redhat. Expect your
>> build dependencies being inadequate, missing,
>> or plainly wrong. Just saying.
>
> After some minor spec file tweaking, I managed to do
> *one* successful TB build, but because Rust compiler can
> hog almost 16GB of memory, most of the time I just
> cannot build TB using my modest Lenovo laptop. OOM
> killer kicks in and destroys the build.
>
> I never could have believed that having 16GB of
> RAM and 8GB of swap is not enough for building TB!

You did it. Thanks for sharing the experience.

On Sun, 29 Dec 2024 21:45:06 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> gabbled:
>On 29.12.2024 11:38, Muttley@dastardlyhq.com wrote:
>> On Sun, 29 Dec 2024 10:33:43 -0000 (UTC)
>> gazelle@shell.xmission.com (Kenny McCormack) gabbled:
>>> [...]
>>
>>> Rust seems to be, like Python, trying to ingratiate itself into the basic
>>> running of the system, not just be a peripheral "scripting language".
>>
>> Requiring 2 seperate compilers to build anything is an absurdity.
>
>(Disclaimer: I skipped most of the sub-thread, so if that generalizing
>sentence was addressing some peculiar (maybe even TB-related) software
>specialities you may ignore the rest of my post.)
>
>From my experience it's no "absurdity" but actual (sensible) normality
>to use multiple compilers and other software generators in SW-projects.

Umm no, it really isn't. At least not for the actual compilers. Boilerplate
code generators sure.

Salvador Mirzo <smirzo@example.com> wrote:
> kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
>
>> Eric Pozharski <apple.universe@posteo.net> wrote:
>>> Yay! The joy of building redhat. Expect your
>>> build dependencies being inadequate, missing,
>>> or plainly wrong. Just saying.
>>
>> After some minor spec file tweaking, I managed to do
>> *one* successful TB build, but because Rust compiler can
>> hog almost 16GB of memory, most of the time I just
>> cannot build TB using my modest Lenovo laptop. OOM
>> killer kicks in and destroys the build.
>>
>> I never could have believed that having 16GB of
>> RAM and 8GB of swap is not enough for building TB!
>
> You did it. Thanks for sharing the experience.

With some incredible luck, it worked out *once*. :-)

br,
KK

kalevi@kolttonen.fi (Kalevi Kolttonen) writes:

> Salvador Mirzo <smirzo@example.com> wrote:
>> kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
>>
>>> Eric Pozharski <apple.universe@posteo.net> wrote:
>>>> Yay! The joy of building redhat. Expect your
>>>> build dependencies being inadequate, missing,
>>>> or plainly wrong. Just saying.
>>>
>>> After some minor spec file tweaking, I managed to do
>>> *one* successful TB build, but because Rust compiler can
>>> hog almost 16GB of memory, most of the time I just
>>> cannot build TB using my modest Lenovo laptop. OOM
>>> killer kicks in and destroys the build.
>>>
>>> I never could have believed that having 16GB of
>>> RAM and 8GB of swap is not enough for building TB!
>>
>> You did it. Thanks for sharing the experience.
>
> With some incredible luck, it worked out *once*. :-)

That also explains why some people were skeptical here. Even with a
sophisticated system to make the compilation succeed, it's still not
without a thrill.

Salvador Mirzo <smirzo@example.com> wrote:
> That also explains why some people were skeptical here. Even with a
> sophisticated system to make the compilation succeed, it's still not
> without a thrill.

The modifications I made to the spec file were in fact
quite trivial. The compilation would have succeeded with
32GB of RAM. Skepticism was not really warranted because
anyone with little Fedora/Red Hat experience could have
done what I did.

Others here have access to more powerful machines than
I do, so they can finish this task if they want to.

I am a bit curious whether my JavaScript hack works
or not.

br,
KK

On Sun, 12/29/2024 1:59 PM, Kalevi Kolttonen wrote:
> Eric Pozharski <apple.universe@posteo.net> wrote:
>> Yay! The joy of building redhat. Expect your
>> build dependencies being inadequate, missing,
>> or plainly wrong. Just saying.
>
> After some minor spec file tweaking, I managed to do
> *one* successful TB build, but because Rust compiler can
> hog almost 16GB of memory, most of the time I just
> cannot build TB using my modest Lenovo laptop. OOM
> killer kicks in and destroys the build.
>
> I never could have believed that having 16GB of
> RAM and 8GB of swap is not enough for building TB!
>
> br,
> KK
>

Try a chain saw next time :-)

It's one of the first practical tests the machine got.
The RPMBuild phase was awfully slow (it spoiled the fun).
But the compiles and linking behaved well. RPM compression
seems to run on one core.

[Picture] During compile phase...

https://i.postimg.cc/44qRrgxb/Thunderbird-Fedora41-Build-From-Source-via-Mock.gif

I think it's possible the build slows down, the longer it runs.
Like "something" is fragmenting.

Even on this machine, the process does not encourage
interactive operation. It takes too long. Adjusting the
command a bit so it just compiles and links, would be
better, if that's possible.

mock --resultdir=/tmp/results --rootdir=/tmp/mock --rebuild thunderbird-128.5.2-1.fc41.src.rpm | tee /tmp/build_out.txt

I picked Fedora for the job, because it only takes two commands
in a terminal, to do it. In simplified terms...

dnf download --source packagename # Downloading source doesn't need root.
mock --rebuild packagename # User account belongs to "mock" group, doesn't build as root

But I need to do something else to that Mock command,
to get what I want (a "portable" copy of Thunderbird,
there should be a dir created with that sitting in it).

Summary: No question, a bit of RAM helps. Some of the RAM
accounting in Linux is just weird (process resident
seen rising, graph in system monitor remains flat).
I was expecting to see a "hump" while linking, but
the graph was relatively flat and featureless.

Paul

Paul <nospam@needed.invalid> writes:
>On Sun, 12/29/2024 1:59 PM, Kalevi Kolttonen wrote:
>> Eric Pozharski <apple.universe@posteo.net> wrote:
>>> Yay! The joy of building redhat. Expect your
>>> build dependencies being inadequate, missing,
>>> or plainly wrong. Just saying.
>>
>> After some minor spec file tweaking, I managed to do
>> *one* successful TB build, but because Rust compiler can
>> hog almost 16GB of memory, most of the time I just
>> cannot build TB using my modest Lenovo laptop. OOM
>> killer kicks in and destroys the build.
>>
>> I never could have believed that having 16GB of
>> RAM and 8GB of swap is not enough for building TB!
>>
>> br,
>> KK
>>
>
>Try a chain saw next time :-)
>
>It's one of the first practical tests the machine got.
>The RPMBuild phase was awfully slow (it spoiled the fun).
>But the compiles and linking behaved well. RPM compression
>seems to run on one core.
>
> [Picture] During compile phase...
>
> https://i.postimg.cc/44qRrgxb/Thunderbird-Fedora41-Build-From-Source-via-Mock.gif
>
>I think it's possible the build slows down, the longer it runs.
>Like "something" is fragmenting.
>
>Even on this machine, the process does not encourage
>interactive operation. It takes too long. Adjusting the
>command a bit so it just compiles and links, would be
>better, if that's possible.
>
>mock --resultdir=/tmp/results --rootdir=/tmp/mock --rebuild thunderbird-128.5.2-1.fc41.src.rpm | tee /tmp/build_out.txt
>
>I picked Fedora for the job, because it only takes two commands
>in a terminal, to do it. In simplified terms...
>
>dnf download --source packagename # Downloading source doesn't need root.
>mock --rebuild packagename # User account belongs to "mock" group, doesn't build as root
>
>But I need to do something else to that Mock command,
>to get what I want (a "portable" copy of Thunderbird,
>there should be a dir created with that sitting in it).
>
>Summary: No question, a bit of RAM helps. Some of the RAM
> accounting in Linux is just weird (process resident
> seen rising, graph in system monitor remains flat).
> I was expecting to see a "hump" while linking, but
> the graph was relatively flat and featureless.
>
> Paul

Why would you expect the link step to require a lot of
memory? The linker builds an elf executable from the contents
of ELF object files, one ELF section at a time. It doesn't
construct the entire ELF executable in memory before writing it out.

On Thu, 1/2/2025 11:29 AM, Scott Lurndal wrote:

> Why would you expect the link step to require a lot of
> memory? The linker builds an elf executable from the contents
> of ELF object files, one ELF section at a time. It doesn't
> construct the entire ELF executable in memory before writing it out.
>

It's based on experience, not imagination.

I've built Thunderbird on both Windows and Linux.
It was the Windows build that left a bad taste.
Once you repeatedly have build failures during linking,
you are always looking for it.

I've built Thunderbird multiple times over the years.
At one time, there was a nasty "ramp" in memory consumption
visible while I was building in Windows XP, and using
the Visual Studio compiler and linker, as instructed
by the Mozilla build page for Thunderbird. I just follow
the recipe when doing these.

The builds today take a lot more RAM than back then.

[Picture]

https://i.postimg.cc/85bRBYpX/buckets-of-ram.gif

Paul

On Thu, 2 Jan 2025 19:36:50 -0500, Paul wrote:

> I've built Thunderbird on both Windows and Linux.
> It was the Windows build that left a bad taste.
> Once you repeatedly have build failures during linking, you are always
> looking for it.

Yours is not the only experience. I recall a blog post from the
LibreOffice folks, soon after they forked off from OpenOffice, that they
tended to suffer intermittent unexplainable build failures on Windows,
too.

Paul <nospam@needed.invalid> writes:
>On Thu, 1/2/2025 11:29 AM, Scott Lurndal wrote:
>
>> Why would you expect the link step to require a lot of
>> memory? The linker builds an elf executable from the contents
>> of ELF object files, one ELF section at a time. It doesn't
>> construct the entire ELF executable in memory before writing it out.
>>
>
>It's based on experience, not imagination.
>
>I've built Thunderbird on both Windows and Linux.
>It was the Windows build that left a bad taste.
>Once you repeatedly have build failures during linking,
>you are always looking for it.
>

Ah, well windows. You need not elaborate.

I've been fortunate to have never built software in a
microsoft environment (aside an optical jukebox driver
for NT3.51 once on a contract job - even then I did
all the editing on unix and just compiled and tested
on the windows box).

On Fri, 03 Jan 2025 18:15:25 GMT
scott@slp53.sl.home (Scott Lurndal) gabbled:
>Paul <nospam@needed.invalid> writes:
>>On Thu, 1/2/2025 11:29 AM, Scott Lurndal wrote:
>>
>>> Why would you expect the link step to require a lot of
>>> memory? The linker builds an elf executable from the contents
>>> of ELF object files, one ELF section at a time. It doesn't
>>> construct the entire ELF executable in memory before writing it out.
>>>
>>
>>It's based on experience, not imagination.
>>
>>I've built Thunderbird on both Windows and Linux.
>>It was the Windows build that left a bad taste.
>>Once you repeatedly have build failures during linking,
>>you are always looking for it.
>>
>
>Ah, well windows. You need not elaborate.
>
>I've been fortunate to have never built software in a
>microsoft environment (aside an optical jukebox driver
>for NT3.51 once on a contract job - even then I did
>all the editing on unix and just compiled and tested
>on the windows box).

I did a Windows C++ job for a year. I still can't believe how complicated
Visual Studio (2017 IIRC) made the most basic things such as setting library
and include paths which were buried 2 or 3 levels down in some sub menu not
to mention all the "project" BS which forced a certain structure on to your
code filesystem layout which I didn't particularly want. Also the fact that
console and GUI apps require a totally different project setup and boiler plate
code from the start is just mind boggling.

Muttley@dastardlyhq.com writes:

> On Fri, 03 Jan 2025 18:15:25 GMT
> scott@slp53.sl.home (Scott Lurndal) gabbled:
>>Paul <nospam@needed.invalid> writes:
>>>On Thu, 1/2/2025 11:29 AM, Scott Lurndal wrote:
>>>
>>>> Why would you expect the link step to require a lot of
>>>> memory? The linker builds an elf executable from the contents
>>>> of ELF object files, one ELF section at a time. It doesn't
>>>> construct the entire ELF executable in memory before writing it out.
>>>>
>>>
>>>It's based on experience, not imagination.
>>>
>>>I've built Thunderbird on both Windows and Linux.
>>>It was the Windows build that left a bad taste.
>>>Once you repeatedly have build failures during linking,
>>>you are always looking for it.
>>>
>>
>>Ah, well windows. You need not elaborate.
>>
>>I've been fortunate to have never built software in a
>>microsoft environment (aside an optical jukebox driver
>>for NT3.51 once on a contract job - even then I did
>>all the editing on unix and just compiled and tested
>>on the windows box).
>
> I did a Windows C++ job for a year. I still can't believe how complicated
> Visual Studio (2017 IIRC) made the most basic things such as setting library
> and include paths which were buried 2 or 3 levels down in some sub menu not
> to mention all the "project" BS which forced a certain structure on to your
> code filesystem layout which I didn't particularly want. Also the fact that
> console and GUI apps require a totally different project setup and boiler plate
> code from the start is just mind boggling.

They always try to make things pretty and easy to use, but you end up
with that. I think the only way to tolerate that is to be born and
raised in such thing. Modularization is likely the most important thing
in programming and it's hard to minimally praise Microsoft on
modularization. For instance, is there any Windows software that
handles a TCP connection in an accept-fork-exec fashion?

On Sat, 04 Jan 2025 08:31:05 -0300
Salvador Mirzo <smirzo@example.com> gabbled:
>Muttley@dastardlyhq.com writes:
>> and include paths which were buried 2 or 3 levels down in some sub menu not
>> to mention all the "project" BS which forced a certain structure on to your
>> code filesystem layout which I didn't particularly want. Also the fact that
>> console and GUI apps require a totally different project setup and boiler
>plate
>> code from the start is just mind boggling.
>
>They always try to make things pretty and easy to use, but you end up
>with that. I think the only way to tolerate that is to be born and
>raised in such thing. Modularization is likely the most important thing
>in programming and it's hard to minimally praise Microsoft on
>modularization. For instance, is there any Windows software that
>handles a TCP connection in an accept-fork-exec fashion?

Win32 can't do fork so thats a no. Also IIRC sockets in windows arn't a
simple file descriptor and can't be multiplexed, at least not with normal
file descriptors so select() and poll() are essentially useless so IIRC you
have to spawn a thread or use windows message or some such overcomplicated
nonsense to wait on them. Hopeless.

On Sat, 04 Jan 2025 08:31:05 -0300, Salvador Mirzo wrote:

> For instance, is there any Windows software that
> handles a TCP connection in an accept-fork-exec fashion?

Almost certainly not. Because process creation is an expensive operation
on Windows.

Windows NT was masterminded by Dave Cutler, who was previously responsible
for the VMS OS at his previous employer, DEC. He was a Unix-hater, part of
a bunch of them at DEC. They would instinctively turn away from Unix ways
of doing things, like forking multiple processes. So the systems they
created did not encourage such techniques.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Sat, 04 Jan 2025 08:31:05 -0300, Salvador Mirzo wrote:
>
>> For instance, is there any Windows software that
>> handles a TCP connection in an accept-fork-exec fashion?
>
> Almost certainly not. Because process creation is an expensive operation
> on Windows.
>
> Windows NT was masterminded by Dave Cutler, who was previously responsible
> for the VMS OS at his previous employer, DEC. He was a Unix-hater, part of
> a bunch of them at DEC. They would instinctively turn away from Unix ways
> of doing things, like forking multiple processes. So the systems they
> created did not encourage such techniques.

Is that Dave with a YouTube channel?

On Sat, 04 Jan 2025 19:17:15 -0300, Salvador Mirzo wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> Windows NT was masterminded by Dave Cutler ...
>
> Is that Dave with a YouTube channel?

No, that’s a different former Microsoftie, but he has had Cutler on his
channel for an extended interview.

I found it ironic that there was a PiDP-11, I think it was, placed within
arm’s reach behind the guy during the entire interview. You know, the
PDP-11 emulator that runs on a Linux-based Raspberry Pi. I wonder if the
Unix-hater ever noticed that ...

On Sat, 4 Jan 2025 22:13:05 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
>On Sat, 04 Jan 2025 08:31:05 -0300, Salvador Mirzo wrote:
>
>> For instance, is there any Windows software that
>> handles a TCP connection in an accept-fork-exec fashion?
>
>Almost certainly not. Because process creation is an expensive operation
>on Windows.
>
>Windows NT was masterminded by Dave Cutler, who was previously responsible
>for the VMS OS at his previous employer, DEC. He was a Unix-hater, part of
>a bunch of them at DEC. They would instinctively turn away from Unix ways
>of doing things, like forking multiple processes. So the systems they
>created did not encourage such techniques.

Presumably VMS relied heavily on multithreading then like Windows or was a
process expected to everything itself sequentially?

Muttley@dastardlyhq.com writes:
>On Sat, 4 Jan 2025 22:13:05 -0000 (UTC)
>Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
>>On Sat, 04 Jan 2025 08:31:05 -0300, Salvador Mirzo wrote:
>>
>>> For instance, is there any Windows software that
>>> handles a TCP connection in an accept-fork-exec fashion?
>>
>>Almost certainly not. Because process creation is an expensive operation
>>on Windows.
>>
>>Windows NT was masterminded by Dave Cutler, who was previously responsible
>>for the VMS OS at his previous employer, DEC. He was a Unix-hater, part of
>>a bunch of them at DEC. They would instinctively turn away from Unix ways
>>of doing things, like forking multiple processes. So the systems they
>>created did not encourage such techniques.
>
>Presumably VMS relied heavily on multithreading then like Windows or was a
>process expected to everything itself sequentially?

The first shared memory multiprocessor VAX was the 11/782. It was
not considered SMP. I worked with four 11/780's sharing a 4MB MA-780
for three years in the early 80s - the shared memory could be used
primarily for inter-process communications (e.g. mailboxes) or one
could install commonly used program read-only 'text' regions in the shared
memory to reduce the memory presure on each of the 780s. I developed
a DECnet ACP to support transport within the cluster via MA-780.

VMS itself did not leverage threads in the modern sense at that point.

In article <vlecm0$1465i$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
>On Sat, 4 Jan 2025 22:13:05 -0000 (UTC)
>Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
>>On Sat, 04 Jan 2025 08:31:05 -0300, Salvador Mirzo wrote:
>>
>>> For instance, is there any Windows software that
>>> handles a TCP connection in an accept-fork-exec fashion?
>>
>>Almost certainly not. Because process creation is an expensive operation
>>on Windows.
>>
>>Windows NT was masterminded by Dave Cutler, who was previously responsible
>>for the VMS OS at his previous employer, DEC. He was a Unix-hater, part of
>>a bunch of them at DEC. They would instinctively turn away from Unix ways
>>of doing things, like forking multiple processes. So the systems they
>>created did not encourage such techniques.
>
>Presumably VMS relied heavily on multithreading then like Windows or was a
>process expected to everything itself sequentially?

Many system services on VMS are asynchronous, and the system
architecture provides a mechanisms to signal completion; ASTs,
mailboxes, etc. Thus, many programs (not all) on VMS are
written in a callback/closure style.

- Dan C.

On Sun, 5 Jan 2025 21:09:55 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
>In article <vlecm0$1465i$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
>>On Sat, 4 Jan 2025 22:13:05 -0000 (UTC)
>>Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
>>>On Sat, 04 Jan 2025 08:31:05 -0300, Salvador Mirzo wrote:
>>>
>>>> For instance, is there any Windows software that
>>>> handles a TCP connection in an accept-fork-exec fashion?
>>>
>>>Almost certainly not. Because process creation is an expensive operation
>>>on Windows.
>>>
>>>Windows NT was masterminded by Dave Cutler, who was previously responsible
>>>for the VMS OS at his previous employer, DEC. He was a Unix-hater, part of
>>>a bunch of them at DEC. They would instinctively turn away from Unix ways
>>>of doing things, like forking multiple processes. So the systems they
>>>created did not encourage such techniques.
>>
>>Presumably VMS relied heavily on multithreading then like Windows or was a
>>process expected to everything itself sequentially?
>
>Many system services on VMS are asynchronous, and the system
>architecture provides a mechanisms to signal completion; ASTs,
>mailboxes, etc. Thus, many programs (not all) on VMS are
>written in a callback/closure style.

I imagine that could become complicated very quickly and presumably relies
on the OS providing the signalling mechanisms for everything you might
want to do - eg waiting for a socket connection (or whatever the decnet
equivalent was).

In article <vlg4mb$1hi6d$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
>On Sun, 5 Jan 2025 21:09:55 -0000 (UTC)
>cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
>>In article <vlecm0$1465i$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
>>>On Sat, 4 Jan 2025 22:13:05 -0000 (UTC)
>>>Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
>>>>On Sat, 04 Jan 2025 08:31:05 -0300, Salvador Mirzo wrote:
>>>>
>>>>> For instance, is there any Windows software that
>>>>> handles a TCP connection in an accept-fork-exec fashion?
>>>>
>>>>Almost certainly not. Because process creation is an expensive operation
>>>>on Windows.
>>>>
>>>>Windows NT was masterminded by Dave Cutler, who was previously responsible
>>>>for the VMS OS at his previous employer, DEC. He was a Unix-hater, part of
>>>>a bunch of them at DEC. They would instinctively turn away from Unix ways
>>>>of doing things, like forking multiple processes. So the systems they
>>>>created did not encourage such techniques.
>>>
>>>Presumably VMS relied heavily on multithreading then like Windows or was a
>>>process expected to everything itself sequentially?
>>
>>Many system services on VMS are asynchronous, and the system
>>architecture provides a mechanisms to signal completion; ASTs,
>>mailboxes, etc. Thus, many programs (not all) on VMS are
>>written in a callback/closure style.
>
>I imagine that could become complicated very quickly and presumably relies
>on the OS providing the signalling mechanisms for everything you might
>want to do - eg waiting for a socket connection (or whatever the decnet
>equivalent was).

It's a fairly common way to structure software even today. As I
said, the OS provides asychronous notification mechanisms (ASTs)
and IPC (mailboxes etc) for signaling operation completion.

- Dan C.

On Mon, 6 Jan 2025 14:08:44 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
>In article <vlg4mb$1hi6d$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
>>On Sun, 5 Jan 2025 21:09:55 -0000 (UTC)
>>cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
>>>In article <vlecm0$1465i$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
>>>>On Sat, 4 Jan 2025 22:13:05 -0000 (UTC)
>>>>Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
>>>>>On Sat, 04 Jan 2025 08:31:05 -0300, Salvador Mirzo wrote:
>>>>>
>>>>>> For instance, is there any Windows software that
>>>>>> handles a TCP connection in an accept-fork-exec fashion?
>>>>>
>>>>>Almost certainly not. Because process creation is an expensive operation
>>>>>on Windows.
>>>>>
>>>>>Windows NT was masterminded by Dave Cutler, who was previously responsible
>
>>>>>for the VMS OS at his previous employer, DEC. He was a Unix-hater, part of
>
>>>>>a bunch of them at DEC. They would instinctively turn away from Unix ways
>>>>>of doing things, like forking multiple processes. So the systems they
>>>>>created did not encourage such techniques.
>>>>
>>>>Presumably VMS relied heavily on multithreading then like Windows or was a
>>>>process expected to everything itself sequentially?
>>>
>>>Many system services on VMS are asynchronous, and the system
>>>architecture provides a mechanisms to signal completion; ASTs,
>>>mailboxes, etc. Thus, many programs (not all) on VMS are
>>>written in a callback/closure style.
>>
>>I imagine that could become complicated very quickly and presumably relies
>>on the OS providing the signalling mechanisms for everything you might
>>want to do - eg waiting for a socket connection (or whatever the decnet
>>equivalent was).
>
>It's a fairly common way to structure software even today. As I

In Windows yes, which frankly is probably not a coincidence. Not so much
in unix unless you're writing a GUI program.