On 11/17/2023 2:44 AM, Martin Brown wrote:
> On 15/11/2023 18:52, Don Y wrote:
>> On 11/15/2023 5:22 AM, Martin Brown wrote:
>
>>> I have finally had to install Ubuntu myself to gain access to exotic
>>> software that is only available on Unix (and porting it to Windows would be
>>> incredibly tedious and error prone which is why no-one ever has).
>>
>> Why have you (presumably) avoided it?  Most Eunices install a lot easier
>> (and quicker!) than Windows.  The only tough part is if you want to offer
>> specific network services on a host (name, file transfer, SMB, packet
>> filtering, etc.).  There, the UIs tend to be pretty archaic (read:
>> non-GUI) and often cryptic.  Best not tackled by newbies.
>
> It was the cryptic archaic UI's and having already invested quite some effort
> in OS/2 PM development skills which paid rather well.

Ah, you're looking for it as a platform on which to code; I use commercial
OSs only to support *tools* (I code on bare metal).

I use Windows-based tools for tasks that tend to be graphic/interactive
and UN*X-based for "batch" processing. E.g., I "drew" all of the
models for my gestures (gesture recognizer) in Illustrator (under
Windows). Wrote a filter (under BSD) to parse the PostScript within each
AI file to extract the Beziers defining the gesture from all the .AI overhead.
Another filter to parse those and populate the RDBMS with the individual
segments. Then, code to extract the features from each segment to
augment each DB record. Finally, ship all that back over to Windows
to render them, interactively, for "proofreading" and inclusion into the
formal documentation and user manual.

> They had a segmented
> architecture where it was very hard (but not quite impossible) for a process to
> access or write to memory outside its allocated zones.

Segments are great -- but usually not of sufficient number or
granularity (it would be nice to statically define a segment per
object and just use segment numbers instead of bare addresses).

The other downside is they only protect an app from itself
(and, only if the app intentionally makes use of that capability).

I emulate segments in a PMMU by wasting large swaths of the address
space. I.e., force objects to begin on page boundaries and fit
in N contiguous pages. Barren wasteland between pages gives me a
similar sort of protection (SIGSEGV).

This has relatively low cost (though more than segment hardware).

But, the real need for protection is between processes so you don't
worry about some other activity stomping on YOUR resources. As
the goal should always be to slice-and-dice into small units of
low/modest complexity, that means lots of processes. And, the cost
for crossing a protection domain is a bit high. An order of magnitude
(maybe two?) moreso if you have to leave the physical processor!

OTOH, processors are cheap compared to development costs. The idea
of writing big pieces of code is just foolhardy -- are you REALLY
that concerned over performance of generic applications??

[Having lots of protected processes is exhilirating; so much
easier to get the code right the first time when you're not
dealing with all sorts of barely-related cruft!]

> Unfortunately the flat memory model and pointer to a God alone knows what
> windows object won out in the end and we all now pay the price. Segmented
> memory access isn't pretty but it puts hard bounds on what damage a rogue
> process can actually do to a working machine.

I spend hardware resources on reinforcing abstractions. So, you
deal with *objects* referenced by a handle (akin to a file descriptor...
it's just a number that means nothing outside of the context of YOUR
task).

So, *YOU* don't muck with any objects but, rather, tell the objects
what you want them to do to themselves on your behalf.

Because everything indirects through a handle, the OS mediates all
accesses. If I want you to be able to "close" a door but not open
it, then the capability that you are issued (embedded in the
handle you have been give to that "door") won't allow you to invoke
the open method. And, you won't even know there are OTHER "doors"
unless you have been given handles to them (the idea of a global
namespace/filesystem is *so* 1960's -- why should every process
know about every name/file in the system? And, then have to layer
ACLs on that to block unwanted access? Just hide the object and
the idea of unwanted accesses goes away!)

Of course, if you try to invoke a method that isn't permitted
by your capability, then you are obviously either buggy or trying
to subvert the system. In each case, you should die and be blocked
from running, again (you're clearly unfit)!

Imagine trying to impose these sorts of mechanisms and policies in
*hardware*...

>>> I'm quite impressed with it so far and Maxima is much more stable on the
>>> Unix platform which is an unexpected bonus for me (likewise I suspect for
>>> Latex too). I may yet make the change to becoming a Unix advocate.
>>>
>>> In future there are some things that I will now do under Unix because it
>>> works better there than on Windows rather than because there is no
>>> equivalent on Windows (which is what motivated me to jump ship).
>>
>> My approach has sort of been the opposite:  using UN*X for the
>> important things and Windows for those things that are more
>> "window dressing" (documentation, CAD/EDA, multimedia, etc.).
>> I've not used a Windows-based toolchain for ages (since VC1.0!)
>
> Fundamentally it comes down to a strategy of only using unfamiliar esoteric
> stuff for solving problems that won't yield any other way.

Well, in my case it's not that the problems won't *yield* but,
rather, that the cost of doing it some other way (with some other
tools) is higher than I'd like to pay. E.g., I could have built
all the gesture models by hand just typing coordinates of control
points for the beziers and having a look at the resulting renderings.
But, that's WAY too tedious (read: prone to error).

[Isn't that why we opt for less efficient hardware and software
solutions -- to minimize the chance of screwing up?]

> I'm presently trying to get to grips with ARM's Remez approximation code in
> Julia and Sollya's alternative way of doing things. Maxima and Excel don't even
> agree on which way the function I am modelling diverges from reality! (and they
> are each given the same precision coefficients)
>
> I'm slightly more inclined to trust Maxima...

Have you looked at (still) other tools? Perhaps Octave? Or YACAS,
Yorick?

I rely on Mathematica for most of my number crunching. But, my $WORK
intentionally tries to avoid complex math as runtime costs are usually
not something that the application can afford. So, I look at what the
theory says (on my desktop) and then pick suitable approximations
to embed in the run-time.

[Like pre-characterizing Beziers instead of trying to *fit* them at
run-time. So, my run-time algorithms can be simple linear operations]

> If anyone here has experience wrestling with either of these approximation
> tools I would be interested in comparing notes...

Phil H may have some exposure... You may want to start a new thread with
an appropriate subject line -- or PM him directly?

On Thu, 16 Nov 2023 08:47:56 -0800, John Larkin <jl@997PotHill.com>
wrote:

>On Thu, 16 Nov 2023 11:17:04 +0000, Martin Brown
><'''newspam'''@nonad.co.uk> wrote:
>
>>On 15/11/2023 22:01, john larkin wrote:
>>> On Wed, 15 Nov 2023 18:16:42 +0000, Martin Brown
>>> <'''newspam'''@nonad.co.uk> wrote:
>>>
>>>> On 14/11/2023 16:09, Dimiter_Popoff wrote:
>>
>>>>> I can swallow that as I use it for reading pdf-s and browsing,
>>>>> plus the occasional ltspice.
>>>>
>>>> The only gotcha I can see is that every version requires more ram and
>>>> occupies more disk space but both are cheap and fast today.
>>>>
>>>> Win10 is going officially unsupported sometime soon in 2025. I expect it
>>>> will get a reprieve or there will be a global malware catastrophe.
>>>>
>>>> https://www.zdnet.com/article/microsoft-windows-10-is-a-security-disaster-waiting-to-happen/
>>>>
>>>> Win11 main advantage for me is that it understands performance cores on
>>>> the more recent Intel CPUs. That is a kludge in Win10.
>>>>
>>>> The last truly dreadful edition of windows was Win8.
>>>> Think Picasso on a bad acid trip and you will not be too far off.
>>>
>>> I miss Win7, but most of the machines have died.
>>
>>Win7 will run on modern CPUs although I wouldn't recommend it unless you
>>either have a damn good impenetrable firewall (plenty of ancient big
>>scientific instruments still work that way 20 year design life -
>>although clever virtualisation of antique hardware environments are
>>getting around that).
>>
>>You can extract the original license key from old kit with suitable
>>tools - although the license server may now have disappeared so you
>>cannot register new hardware to run Win7. It means that certain
>>motherboards have premium prices in the second hand market.
>>
>>You can make Win11 look enough like WIn7 to be acceptable.
>>
>>> Win11 got terrible user reviews, but update 23H2 fixed a lot of
>>> stupidities. It's almost tolerable, after a lot of tweaks.
>>>
>>> It runs Firefox, LT Spice, PADS, VLC, Crimson, Agent, Irfanview, and a
>>> bunch of my old compiled PowerBasic programs. And seems reliable so
>>> far.
>>
>>None of those are particularly taxing. The big change was when 32bit
>>code (and before that 16bit) became unsupported.
>>That broke a lot of major players installers like Adobe Photoshop and
>>others.
>>You just like to whinge and whine about Intel and Microsoft.
>
>You just like to insult people.
>
>Design something. You'll feel better.

I suspect that designing (and building) hardware makes people happier
and friendlier than typing code all day. Hardware design exercizes a
lot more parts of your brain and body.

It sure makes me happier. I get depressed if I type code for more than
a week or two.

On Thu, 16 Nov 2023 11:04:38 +0000, Martin Brown
<'''newspam'''@nonad.co.uk> wrote:

>On 15/11/2023 18:54, Don Y wrote:
>> On 11/15/2023 11:16 AM, Martin Brown wrote:
>>> The only gotcha I can see is that every version requires more ram and
>>> occupies more disk space but both are cheap and fast today.
>>
>> Save for a generation of machines with 8GB *hardware* memory limits...
>
>It was ever thus. Time was when each new OS required almost all of the
>hardware currently in use to be replaced.
>>
>> OTOH, I can run a *BSD box with *megabytes* of RAM if I am willing
>> to live witht he thrashing (which, unlike windows machines,
>> won't take the machine to its knees)
>
>I can recall a time back when big iron had a whopping (for the time) 4MB
>of main memory and when you you had to get a special ticket to allow
>your jobs to use more than 1MB at a time. Lisp wouldn't run in less.

I remember a big press release when IBM announced mainframe memory for
a mere $50,000 per megabyte. $50K would buy 10 Cadillacs then.

On Fri, 17 Nov 2023 09:44:02 +0000, Martin Brown
<'''newspam'''@nonad.co.uk> wrote:

>
>It was the cryptic archaic UI's and having already invested quite some
>effort in OS/2 PM development skills which paid rather well. They had a
>segmented architecture where it was very hard (but not quite impossible)
>for a process to access or write to memory outside its allocated zones.

Apparently it had non-overlapping segments. IIRC the segment registers
also had an exe/moexe bit.Thus it would be quite hard to modify the
code segment accidentally.

With 386 Intel made a mistake by first evaluated the segment address,
then truncate it to 32 bits before applying paging. Thus the virtual
address space was limited to 4 GB. A better solution would have been
skipping the truncation to 32 bits and allow 4 GB access for each
segment.

Things get worse by some OSes which loaded 0 to all segment registers,
thus all segments overlapped, so writing into the code segment is
easy. No help setting the execute bit in the code segment register and
denying in other segments.

>
>Unfortunately the flat memory model and pointer to a God alone knows
>what windows object won out in the end and we all now pay the price.
>Segmented memory access isn't pretty but it puts hard bounds on what
>damage a rogue process can actually do to a working machine.

I can understand the segmented system problems with 16 bit 8086 code,
but in 32 bit 386 mode it would have less harmful.

It is sad that the segmented access is nearly gone in 64 bitters. A
few more segment registers and most addresses could be generated with
2 or 4 byte offsets relative to the segment register, instead of full
8 byte address references.

On 11/17/2023 2:59 PM, upsidedown@downunder.com wrote:
> On Fri, 17 Nov 2023 09:44:02 +0000, Martin Brown
> <'''newspam'''@nonad.co.uk> wrote:
>
>>
>> It was the cryptic archaic UI's and having already invested quite some
>> effort in OS/2 PM development skills which paid rather well. They had a
>> segmented architecture where it was very hard (but not quite impossible)
>> for a process to access or write to memory outside its allocated zones.
>
> Apparently it had non-overlapping segments. IIRC the segment registers
> also had an exe/moexe bit.Thus it would be quite hard to modify the
> code segment accidentally.

Also possible in ARM v8.

Limits on segment size have proven to be dreadfully small.
Even 32b segment size register isn't exceptional.

The processor designer in me wants to see segments begin
anywhere (even if that causes unaligned memory hits)
and the length have a maximum size equal to the size
of the physical address space with a granularity of
a single byte (again, accepting the performance hits...
provide mechanism, not policy!)

And, you need a PMMU *under* the segmentation hardware to
piece together chunks of discontiguous memory as its
unreasonable to expect a static mapping to work for all
applications.

But, realistically, you can "settle" for much fewer choices
(e.g., a few page sizes aligned in a similarly coarse page frame)

Sadly, neither approach makes things any easier for the software;
either too much detail to manage, or too much approximation
to manage.

> With 386 Intel made a mistake by first evaluated the segment address,
> then truncate it to 32 bits before applying paging. Thus the virtual
> address space was limited to 4 GB. A better solution would have been
> skipping the truncation to 32 bits and allow 4 GB access for each
> segment.
>
> Things get worse by some OSes which loaded 0 to all segment registers,
> thus all segments overlapped, so writing into the code segment is
> easy. No help setting the execute bit in the code segment register and
> denying in other segments.

The problem with managing the underlying hardware is more
pervasive. Most OSs hide far too much from their users.
E.g., if I make an access beyond the current limits of
a particular segment, shouldn't I -- at least -- have a say in
how that is handled? Instead, the OS will likely throw a
fault and shoot me.

Exposing memory management to the user lets him exploit
the hardware to *his* advantage.

E.g., I routinely pass large objects to the network stack
(and other local processes).

But, they sit, queued for transport for some amount of
time (it would be foolish to require a synchronous call).
Using call-by-reference semantics, it's possible that the
object could be altered by some other thread -- including
the one that "sent" it -- while it's queued.

I fake call-by-value semantics WITHOUT duplicating the
object (which would consume additional memory AND
time to marshall the arguments) by twiddling the TLB
entries for those pages, marking them R/O in the caller.

This lets the caller access the object after passing it to
the stack (as would normally be the case with call-by-reference)
*but* ensures any attempts by the caller to ALTER the
object will be intercepted -- because the object
wants to be transported in the state it was at the
time it was passed to the stack!

Write attempts cause the referenced page to be remapped
(in the caller) to a different page and a R/W copy of the
original page's contents made available for the caller
to modify. Repeat, as required.

[Note that the original object was R/W before it was
passed to the stack, else even this write would fault]

When the original object eventually is consumed by the stack,
the original pages are returned to their original R/W
states with any of the created duplicates replacing the
corresponding originals.

So, the stack's copy of the image was never corrupted.
It benefits from a call-by-value interface without
the cost of maintaining a duplicate copy of the object
(which may or may not ever be needed, as such).
Yet the caller was given freedom to modify it, at will,
without blocking on it being released by the stack.

It also lets the stack (callee) free portions of the
object as they are converted into packets. Otherwise,
a synchronous call would have been required with the
caller handling that aspect of the object management.

Of course, this is a privileged operation so you don't
just let ANY user-level task fiddle with the TLBs.
But, you can let *trusted* tasks outside of the
OS perform these actions without having to add this
functionality to the kernel (increasing its size).

>> Unfortunately the flat memory model and pointer to a God alone knows
>> what windows object won out in the end and we all now pay the price.
>> Segmented memory access isn't pretty but it puts hard bounds on what
>> damage a rogue process can actually do to a working machine.
>
> I can understand the segmented system problems with 16 bit 8086 code,
> but in 32 bit 386 mode it would have less harmful.

History teaches us that all of these "hacks" eventually
come around to bite us in the ass. Limits always look
like obstacles to *someone's* application.

> It is sad that the segmented access is nearly gone in 64 bitters. A
> few more segment registers and most addresses could be generated with
> 2 or 4 byte offsets relative to the segment register, instead of full
> 8 byte address references.

What's the goal, there? To save on code space?