On Sunday, October 15, 2023 at 5:03:18 AM UTC+11, a a wrote:
> The idiot Martin Brown <'''newspam'''@nonad.co.uk> persisting in being an Off-topic troll...

A a is clearly very silly. Whatever Martin Brown's faults might be, he clearly isn't an idiot or an off-topic troll. and a a - who fits into both categories very neatly - should have enough sense to realise this and construct his abusive text more carefully.

--
Bil Sloman, Sydney

søndag den 15. oktober 2023 kl. 13.00.54 UTC+2 skrev Martin Brown:
> On 14/10/2023 23:09, legg wrote:
>
> > After twelve months of neglect, there seems to be an inordinant
> > neglect of the OS in monitoring simple keystrokes or mouse
> > clicks - with an annoying circular 'wait' icon marking the
> > delays, that wasn't there previously.
> It is a side effect of every damn programmer thinking that their task is
> *the* most important one on the system. Upwards priority creep leaves
> little room to handle mere user keyboard and mouse input.
>
> I agree that at times Win11 is less responsive than if should be.
>
> FWIW I almost never see the wait icon apart from when it is updating OS.
> > Not being able to react to user keystrokes immediately is
> > a major fault in any GUI - it takes so little machine code
> > discipline to enforce.
> The problem is that it does require discipline. :(
>
> My pet hate is the damned "progress bar" for updates. Yesterday it did a
> small one - a mere 0.5GB and it took ages. The progress bar went from 0
> to 95% in just 3s and then it spent 2 minutes between each successive 1%
> step. That is a ridiculous waste of my time. If had known it was going
> to take ten minutes at the outset I could go off for a coffee.
>
> Heaven knows how long it would have taken on a slower machine with
> spinning rust.
>
> WTF can't they get something so basic right? They must know
> approximately how long each component install will take +/-10% from the
> moment that the installer code begins to run on the system.

https://youtu.be/9gTLDuxmQek?si=52QZMOJN7N-jwbw9

On 10/14/2023 7:41 AM, Martin Brown wrote:
>> I have had to replace many things like printers and scanners because the
>> next operating system or software did not support them.
>
> For scanners and the like there were third party fixes by users who wanted to
> use their old printers on newer OS's. It has become progressively harder to do
> this with more recent somewhat more secure ones. This requires a certain amount
> of reverse engineering and hacking of the new official drivers to get them to
> work with OS's. Sometimes it was as simple as disabling the test to see if OS
> version is >N.nn !

VueScan has been "adequate" for supporting (a wide variety) of scanners.
Sadly, it fails to support all of the (scanner mounted) controls so
you have to explicitly open the app and initiate a scan (instead of
relying on buttons on the scanner to do that).

But, I think the scanner has to be hardwired to the host on which
VueScan is invoked (several of my scanners are accessed as
network peripherals).

Old (HP) LaserJets were still supported under W7 -- though you had to
work to find the correct driver.

Some of my "specialty" printers I've had to support in VMs. <frown>

On 10/15/2023 4:00 AM, Martin Brown wrote:
> On 14/10/2023 23:09, legg wrote:
>
>> After twelve months of neglect, there seems to be an inordinant
>> neglect of the OS in monitoring simple keystrokes or mouse
>> clicks - with an annoying circular 'wait' icon marking the
>> delays, that wasn't there previously.
>
> It is a side effect of every damn programmer thinking that their task is *the*
> most important one on the system. Upwards priority creep leaves little room to
> handle mere user keyboard and mouse input.

Do Windows processes even HAVE direct control over their current priority?
All scheduling decisions in my RTOS are driven by deadline specifications
and value functions. So, to boost your priority, you have to declare a
*hard* deadline -- and "soon".

This imposes a self-regulating mechanism: if the OS decides it CAN'T
meet your (hard!) deadline, it simply kills off your process (invokes
your deadline handler) -- why bother working on something that can't
be met?

So, a wise developer specifies realistic (and soft) deadlines to
ensure his code gets a chance to run!

> I agree that at times Win11 is less responsive than if should be.
>
> FWIW I almost never see the wait icon apart from when it is updating OS.
>
>> Not being able to react to user keystrokes immediately is
>> a major fault in any GUI - it takes so little machine code
>> discipline to enforce.
>
> The problem is that it does require discipline. :(

There are actions that inherently can't provide a (valid) "updated context" to
the user for some time after the most recent user action. Without such a
valid context, the user's "future" actions are ambiguous. E.g., trying to open
a file that APPEARS to be in one place yet is actually in the process of
being moved or deleted -- which file will APPEAR in that spot in the
directory listing when the enqueued action is eventually processed?

> My pet hate is the damned "progress bar" for updates. Yesterday it did a small
> one - a mere 0.5GB and it took ages. The progress bar went from 0 to 95% in
> just 3s and then it spent 2 minutes between each successive 1% step. That is a
> ridiculous waste of my time. If had known it was going to take ten minutes at
> the outset I could go off for a coffee.

I researched this some time ago, for exactly that reason. There's no closed
form solution to the problem -- unless you can control the other activities
in the machine at the same time (because you don't know what the process may
end up waiting on).

E.g., I have an app that I use, heavily, to compare portions of local
and remote file systems. It, naively, assumes that the bandwidth of
each is approximately equivalent. But, there may be inherent differences
(in some cases, accessing a remote share at wire speed can be quicker
than a local store on a slow disk -- or, one behind a slow i/f).

And, if something else is competing for bandwidth to one of those
stores (local or remote), the estimated time remaining (H:MM:SS!)
can change wildly -- whereas normally it is incredibly linear.

Worst are progress indications that are just "activity indicators".
E.g., Sun starts a separate process to reassure you that things are still
running -- but, there is no interconnect between the indicator
process and the worker process other than an explicit signal from the
worker to th4e indicator WHEN IT IS COMPLETE. (so, you can kill off
the worker process and the indicator will gleefully continue "please
wait")

> Heaven knows how long it would have taken on a slower machine with spinning rust.
>
> WTF can't they get something so basic right? They must know approximately how
> long each component install will take +/-10% from the moment that the installer
> code begins to run on the system.

Only if you know (or can control) what else is happening in the machine.

It is particularly difficult when you have to predict performance
of interelated processes that can execute on different hosts from
one invocation to the next. (how heavily loaded is the update
server, NOW? How fat is the pipe you are using to access it?
are there other processes competing for resources on YOUR host?
on your network segment? etc.)

And, even if you know "how far we've come", that just gives
you a means of saying "from THIS point, we are X% done" -- but,
no way of predicting when you will GET to that point.

The solution is to come up with processes/policies that don't
interfere with the user's other activities. MS is notorious
for thinking they "own" the machine instead of acting as
a friendlier playmate.

In article <ughaf9$l32p$2@dont-email.me>,
Don Y <blockedofcourse@foo.invalid> wrote:
>On 10/15/2023 4:00 AM, Martin Brown wrote:
>> On 14/10/2023 23:09, legg wrote:
>>
>>> After twelve months of neglect, there seems to be an inordinant
>>> neglect of the OS in monitoring simple keystrokes or mouse
>>> clicks - with an annoying circular 'wait' icon marking the
>>> delays, that wasn't there previously.
>>
>> It is a side effect of every damn programmer thinking that their task
>is *the*
>> most important one on the system. Upwards priority creep leaves little
>room to
>> handle mere user keyboard and mouse input.
>
>Do Windows processes even HAVE direct control over their current priority?
>All scheduling decisions in my RTOS are driven by deadline specifications
>and value functions. So, to boost your priority, you have to declare a
>*hard* deadline -- and "soon".
>
>This imposes a self-regulating mechanism: if the OS decides it CAN'T
>meet your (hard!) deadline, it simply kills off your process (invokes
>your deadline handler) -- why bother working on something that can't
>be met?
>
>So, a wise developer specifies realistic (and soft) deadlines to
>ensure his code gets a chance to run!
>
>> I agree that at times Win11 is less responsive than if should be.
>>
>> FWIW I almost never see the wait icon apart from when it is updating OS.
>>
>>> Not being able to react to user keystrokes immediately is
>>> a major fault in any GUI - it takes so little machine code
>>> discipline to enforce.
>>
>> The problem is that it does require discipline. :(
>
>There are actions that inherently can't provide a (valid) "updated context" to
>the user for some time after the most recent user action. Without such a
>valid context, the user's "future" actions are ambiguous. E.g., trying to open
>a file that APPEARS to be in one place yet is actually in the process of
>being moved or deleted -- which file will APPEAR in that spot in the
>directory listing when the enqueued action is eventually processed?
>
>> My pet hate is the damned "progress bar" for updates. Yesterday it did
>a small
>> one - a mere 0.5GB and it took ages. The progress bar went from 0 to 95% in
>> just 3s and then it spent 2 minutes between each successive 1% step.
>That is a
>> ridiculous waste of my time. If had known it was going to take ten minutes at
>> the outset I could go off for a coffee.
>
>I researched this some time ago, for exactly that reason. There's no closed
>form solution to the problem -- unless you can control the other activities
>in the machine at the same time (because you don't know what the process may
>end up waiting on).
>
>E.g., I have an app that I use, heavily, to compare portions of local
>and remote file systems. It, naively, assumes that the bandwidth of
>each is approximately equivalent. But, there may be inherent differences
>(in some cases, accessing a remote share at wire speed can be quicker
>than a local store on a slow disk -- or, one behind a slow i/f).
>
>And, if something else is competing for bandwidth to one of those
>stores (local or remote), the estimated time remaining (H:MM:SS!)
>can change wildly -- whereas normally it is incredibly linear.
>
>Worst are progress indications that are just "activity indicators".
>E.g., Sun starts a separate process to reassure you that things are still
>running -- but, there is no interconnect between the indicator
>process and the worker process other than an explicit signal from the
>worker to th4e indicator WHEN IT IS COMPLETE. (so, you can kill off
>the worker process and the indicator will gleefully continue "please
>wait")
>
>> Heaven knows how long it would have taken on a slower machine with
>spinning rust.
>>
>> WTF can't they get something so basic right? They must know approximately how
>> long each component install will take +/-10% from the moment that the
>installer
>> code begins to run on the system.
>
>Only if you know (or can control) what else is happening in the machine.
>
>It is particularly difficult when you have to predict performance
>of interelated processes that can execute on different hosts from
>one invocation to the next. (how heavily loaded is the update
>server, NOW? How fat is the pipe you are using to access it?
>are there other processes competing for resources on YOUR host?
>on your network segment? etc.)
>
>And, even if you know "how far we've come", that just gives
>you a means of saying "from THIS point, we are X% done" -- but,
>no way of predicting when you will GET to that point.
>
>The solution is to come up with processes/policies that don't
>interfere with the user's other activities. MS is notorious
>for thinking they "own" the machine instead of acting as
>a friendlier playmate.
>

It boils to the truth that user interface is a real time system.
Programmers that are actually capable of making real time systems
work, are never assigned to such a low level job.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On 10/15/2023 11:23 AM, albert wrote:
>> The solution is to come up with processes/policies that don't
>> interfere with the user's other activities. MS is notorious
>> for thinking they "own" the machine instead of acting as
>> a friendlier playmate.
>
> It boils to the truth that user interface is a real time system.
> Programmers that are actually capable of making real time systems
> work, are never assigned to such a low level job.

There are timeliness constraints in damn near *all*
applications -- so, all are inherently RT systems.
(Even "Deep Thought" had to produce a result before
the mice faded from existence!)

But, most schedulers (and OSs) aren't RT schedulers. Instead,
they are round-robin or naive "priority" schedulers. Toys
that you'd write as a high school homework assignment.

ANY task has several parameters governing how it
should be scheduled/access resources:
- when do you need the "result(s)" (this can be
an absolute time or a relative time)
- what value do "late" results have (relative)
- how *important* are these results (also relative)
- what do you DO *when* this deadline can't be met

[Q: how do YOU specify these in your designs??
Implementations?? :> Oops! ]

Note, in none of this is "nearness" of deadline an issue
except in its relationship to other deadlines. (how quick)

Nor frequency of events. (too often, folks think of
RT as "real fast" or "real soon" -- silly way of thinking
about things -- and, likely BOASTING that you handled
events at 10KHz, etc. "You mean, like a lowly UART?")

With a UI, you need to capture the user's actions when
they happen (as things like button presses, mouse clicks,
etc. are transient events that have to be "seen" when
they occur. So, whatever hardware/software is required
to interface to the user has relatively tight timeliness
constraints. If you can't see an event that exists for
time T, then any actions by the user that cause such events
will be missed. Completely.

Ideally, you provide an indication that you have seen
the event (click, beep, flash, etc.). Sadly, because
most OS's aren't responsive enough, this gets hardwired
into an ISR (or equivalent) thereafter forcing that
response for ALL UI events (which should be a policy
decision at a higher level of abstraction). Instead,
a task WAITING on that event should "immediately"
get control of the processor and delegate activities
to other, LOWER priority tasks to complete the activity.

Because the system, itself, isn't responsive enough to
promote the event to a higher abstraction level in a timely
fashion.

At ~300ms, users get anxious; "Did it SEE my action?"
And, then you risk them repeating an action, just in case,
which may result in unintended consequences ("Oh, you
DO want me to erase the entire disk? Gee, I barely had
time to display the dialog asking for confirmation when
I saw your reply...")

But, it may not be possible to actually process the
event if resources on which it relies aren't available.
In many systems, there are other activities competing
for those resources -- some of which may not even be known
at the time the system is created!

Does ONE user-initiated task HAVE TO complete before another
can be started? Was the developer of such a serially-constrained
mind to bake that assumption into his implementation?
Or, was he smart enough to START a task to process that request
and go back to the well looking for ANOTHER command from
the user -- that will cause yet another task to be created...

[Is he smart enough to make sense of the fact that task 2
might complete BEFORE task 1? E.g., unmounting a volume before
all file operations on it are completed? Will he recognize any
possible interactions between those two tasks and take
that into account in his implementation? Or, will that
manifest as a race... eventually?]

This is obviously the case for desktop machines where
there is no control over the "admissions policy" for
applications.

[Little "closed boxes" aren't very interesting and are
usually handled by folks treating them as HRT systems and
needlessly overprovisioning -- hardware AND software -- based
on that artificial assessment. If HRT is "hard", then SRT is
considerably HARDER and beyond the capabilities of most mortals!
Yet, most tasks are actually SRT (using the populist definition).
"'Tis a puzzlement!" Esp when the practitioners don't realize
these things!]

On Sun, 15 Oct 2023 11:19:20 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 10/15/2023 4:00 AM, Martin Brown wrote:
>> On 14/10/2023 23:09, legg wrote:
>>
>>> After twelve months of neglect, there seems to be an inordinant
>>> neglect of the OS in monitoring simple keystrokes or mouse
>>> clicks - with an annoying circular 'wait' icon marking the
>>> delays, that wasn't there previously.
>>
>> It is a side effect of every damn programmer thinking that their task is *the*
>> most important one on the system. Upwards priority creep leaves little room to
>> handle mere user keyboard and mouse input.
>
>Do Windows processes even HAVE direct control over their current priority?
>All scheduling decisions in my RTOS are driven by deadline specifications
>and value functions. So, to boost your priority, you have to declare a
>*hard* deadline -- and "soon".
>
>This imposes a self-regulating mechanism: if the OS decides it CAN'T
>meet your (hard!) deadline, it simply kills off your process (invokes
>your deadline handler) -- why bother working on something that can't
>be met?
>
>So, a wise developer specifies realistic (and soft) deadlines to
>ensure his code gets a chance to run!
>
>> I agree that at times Win11 is less responsive than if should be.
>>
>> FWIW I almost never see the wait icon apart from when it is updating OS.
>>
>>> Not being able to react to user keystrokes immediately is
>>> a major fault in any GUI - it takes so little machine code
>>> discipline to enforce.
>>
>> The problem is that it does require discipline. :(
>
>There are actions that inherently can't provide a (valid) "updated context" to
>the user for some time after the most recent user action. Without such a
>valid context, the user's "future" actions are ambiguous. E.g., trying to open
>a file that APPEARS to be in one place yet is actually in the process of
>being moved or deleted -- which file will APPEAR in that spot in the
>directory listing when the enqueued action is eventually processed?
>
>> My pet hate is the damned "progress bar" for updates. Yesterday it did a small
>> one - a mere 0.5GB and it took ages. The progress bar went from 0 to 95% in
>> just 3s and then it spent 2 minutes between each successive 1% step. That is a
>> ridiculous waste of my time. If had known it was going to take ten minutes at
>> the outset I could go off for a coffee.
>
>I researched this some time ago, for exactly that reason. There's no closed
>form solution to the problem -- unless you can control the other activities
>in the machine at the same time (because you don't know what the process may
>end up waiting on).
>
>E.g., I have an app that I use, heavily, to compare portions of local
>and remote file systems. It, naively, assumes that the bandwidth of
>each is approximately equivalent. But, there may be inherent differences
>(in some cases, accessing a remote share at wire speed can be quicker
>than a local store on a slow disk -- or, one behind a slow i/f).
>
>And, if something else is competing for bandwidth to one of those
>stores (local or remote), the estimated time remaining (H:MM:SS!)
>can change wildly -- whereas normally it is incredibly linear.
>
>Worst are progress indications that are just "activity indicators".
>E.g., Sun starts a separate process to reassure you that things are still
>running -- but, there is no interconnect between the indicator
>process and the worker process other than an explicit signal from the
>worker to th4e indicator WHEN IT IS COMPLETE. (so, you can kill off
>the worker process and the indicator will gleefully continue "please
>wait")
>
>> Heaven knows how long it would have taken on a slower machine with spinning rust.
>>
>> WTF can't they get something so basic right? They must know approximately how
>> long each component install will take +/-10% from the moment that the installer
>> code begins to run on the system.
>
>Only if you know (or can control) what else is happening in the machine.
>
>It is particularly difficult when you have to predict performance
>of interelated processes that can execute on different hosts from
>one invocation to the next. (how heavily loaded is the update
>server, NOW? How fat is the pipe you are using to access it?
>are there other processes competing for resources on YOUR host?
>on your network segment? etc.)
>
>And, even if you know "how far we've come", that just gives
>you a means of saying "from THIS point, we are X% done" -- but,
>no way of predicting when you will GET to that point.
>
>The solution is to come up with processes/policies that don't
>interfere with the user's other activities. MS is notorious
>for thinking they "own" the machine instead of acting as
>a friendlier playmate.

Wasn't having multiplr processors supposed to provide some
kind of order in process queue issues?

TaskInfo - my goto process monitor - is confused by W11 reporting
on CPU activity. Running four separate crunching tasks for World
Community Grid (BOINC)at 20-25% CPU occupancy each nets a 6$
CPU summarey occupancy on a quad processor. This doesn't add
up no matter what justifications are put forward.

Same program and quad processor on W7 could at least add.

No trouble recognizing keystrokes until an MS Office or
other MS programmes are attempted - then they and anything
else running is at the mercy of some nincompoop in wherever.

RL

On 10/15/2023 1:45 PM, legg wrote:
>> The solution is to come up with processes/policies that don't
>> interfere with the user's other activities. MS is notorious
>> for thinking they "own" the machine instead of acting as
>> a friendlier playmate.
>
> Wasn't having multiplr processors supposed to provide some
> kind of order in process queue issues?

If you have truly independant tasks, then multiple processors
(or cores on the same processor) gives you a 1-for-1 speedup.

But, most tasks are interelated -- either directly or indirectly
(through resources utilized)

I have a simpler way of dealing with additional cores: I
partition the design so that each core can address some specific
set of requirements and don't sweat trying to get 100%
utilization of all cores.

[E.g., I rely on the network, HEAVILY, for RPCs. So, I have a
core that JUST handles the routing of messages, tracking
where the destination processes may have migrated, encrypting
traffic, key exchange, etc. So, IPC/RPC falls out of the
calculus for the "real" processes running in other cores.]

> TaskInfo - my goto process monitor - is confused by W11 reporting
> on CPU activity. Running four separate crunching tasks for World
> Community Grid (BOINC)at 20-25% CPU occupancy each nets a 6$
> CPU summarey occupancy on a quad processor. This doesn't add
> up no matter what justifications are put forward.
>
> Same program and quad processor on W7 could at least add.

What vintage the monitoring task?

> No trouble recognizing keystrokes until an MS Office or
> other MS programmes are attempted - then they and anything
> else running is at the mercy of some nincompoop in wherever.

I often find apps "not responding" because they are
busy with <whatever>. But, the UI provides an indication
so I don't sit there hammering away and wondering why
nothing is happening.

Netsarang's X server seems to have a problem handling keystrokes;
it's as if it misses keyup events so you see lots of repeating
keystrokes that you never intended -- even when your hands
are OFF the keyboard!

[They seem to have a quality problem with their software as I
have seen other apps of theirs with annoying bugs. Their
FTP client is smart enough to reconnect after a connection is
closed, server side. But, NOT smart enough to remember how
the session was configured BEFORE it was closed! So, if you've
requested BINARY transfers in a session and leave the session
idle for "too long" (which is defined by the server), the
NEXT transfer may end up being in ASCII mode. "Why is the file
the wrong size?" No doubt, they didn't think of testing for
the "dropped session" case before release...]

Gotta wonder if their development process KNOWS to track
these problems and fold them into the test suite so they don't
manifest, AGAIN, at a later date?!

On 15/10/2023 19:19, Don Y wrote:
> On 10/15/2023 4:00 AM, Martin Brown wrote:

>> My pet hate is the damned "progress bar" for updates. Yesterday it did
>> a small one - a mere 0.5GB and it took ages. The progress bar went
>> from 0 to 95% in just 3s and then it spent 2 minutes between each
>> successive 1% step. That is a ridiculous waste of my time. If had
>> known it was going to take ten minutes at the outset I could go off
>> for a coffee.
>
> I researched this some time ago, for exactly that reason.  There's no
> closed
> form solution to the problem -- unless you can control the other activities
> in the machine at the same time (because you don't know what the process
> may
> end up waiting on).

But the big annoying Win11 OS updates are applied after a cold boot so
there is nothing but their &*@$&%£~* updater running and it still gives
utterly meaningless answers for % complete.

> E.g., I have an app that I use, heavily, to compare portions of local
> and remote file systems.  It, naively, assumes that the bandwidth of
> each is approximately equivalent.  But, there may be inherent differences
> (in some cases, accessing a remote share at wire speed can be quicker
> than a local store on a slow disk -- or, one behind a slow i/f).
>
> And, if something else is competing for bandwidth to one of those
> stores (local or remote), the estimated time remaining (H:MM:SS!)
> can change wildly -- whereas normally it is incredibly linear.

If there is resource competition then time to execute code can be very
tricky particularly if it messes up assumptions about cache. It is
particularly bad for code with big data that only just fits in main memory.

>> Heaven knows how long it would have taken on a slower machine with
>> spinning rust.
>>
>> WTF can't they get something so basic right? They must know
>> approximately how long each component install will take +/-10% from
>> the moment that the installer code begins to run on the system.
>
> Only if you know (or can control) what else is happening in the machine.

But at boot time that is a given for the OS updater.

> The solution is to come up with processes/policies that don't
> interfere with the user's other activities.  MS is notorious
> for thinking they "own" the machine instead of acting as
> a friendlier playmate.

I think it is a throwback to the sysmodal priority of OS/2.

The other pet hate I have is when there is an email server glitch on
some email clients the OAuth2 password challenge popup window appears
*behind* all other open windows where you can't even see it!

No more emails will flow until you find the damn window and respond to
it. This can be when you next reboot.

--
Martin Brown

In article <ugjckn$1e0a2$1@dont-email.me>, '''newspam'''@nonad.co.uk
says...
> can change wildly -- whereas normally it is incredibly linear.
>
> If there is resource competition then time to execute code can be very
> tricky particularly if it messes up assumptions about cache. It is
> particularly bad for code with big data that only just fits in main memory.
>
>

I bought a cheep wireless keyboard and mouse for a win 11 computer I
just bought. Is it win 11 that the mouse is jerkey moving around on the
screen and the keyboard sometime takes a few seconds to respond ? Or is
it the cheep keyboard and mouse ?

On Monday, October 16, 2023 at 9:53:58 AM UTC-5, Ralph Mowery wrote:
> In article <ugjckn$1e0a2$1...@dont-email.me>, '''newspam'''@nonad.co.uk
> says...
> > can change wildly -- whereas normally it is incredibly linear.
> >
> > If there is resource competition then time to execute code can be very
> > tricky particularly if it messes up assumptions about cache. It is
> > particularly bad for code with big data that only just fits in main memory.
> >
> >
> I bought a cheep wireless keyboard and mouse for a win 11 computer I
> just bought. Is it win 11 that the mouse is jerkey moving around on the
> screen and the keyboard sometime takes a few seconds to respond ? Or is
> it the cheep keyboard and mouse ?

I can't answer your question directly, Ralph. But, I can tell you that I have a new computer that came with wireless
mouse and keyboard and it works beautifully.

On 10/16/2023 6:08 AM, Martin Brown wrote:
> On 15/10/2023 19:19, Don Y wrote:
>> On 10/15/2023 4:00 AM, Martin Brown wrote:
>
>>> My pet hate is the damned "progress bar" for updates. Yesterday it did a
>>> small one - a mere 0.5GB and it took ages. The progress bar went from 0 to
>>> 95% in just 3s and then it spent 2 minutes between each successive 1% step.
>>> That is a ridiculous waste of my time. If had known it was going to take ten
>>> minutes at the outset I could go off for a coffee.
>>
>> I researched this some time ago, for exactly that reason.  There's no closed
>> form solution to the problem -- unless you can control the other activities
>> in the machine at the same time (because you don't know what the process may
>> end up waiting on).
>
> But the big annoying Win11 OS updates are applied after a cold boot so there is
> nothing but their &*@$&%£~* updater running and it still gives utterly
> meaningless answers for % complete.

But we (humans) think of % most usually as a measure of *time*.
There's no telling how the update measures progress... number of
diffs applied? bytes written? features updated/bugs patched?

I wanted a linear wrt time display (which seems like it would be
the most intuitive TO A USER. But, how do you even benchmark that
in order to tag the process after-the-fact? How can you know how long
the process will take on some other machine?

E.g., when I go to eject USB drives, Windows must flush the disk cache
as the drive indicator comes on for a REALLY long time before the
USB device is "safe". On machines with far less RAM, the operation
takes just a couple of seconds.

>> E.g., I have an app that I use, heavily, to compare portions of local
>> and remote file systems.  It, naively, assumes that the bandwidth of
>> each is approximately equivalent.  But, there may be inherent differences
>> (in some cases, accessing a remote share at wire speed can be quicker
>> than a local store on a slow disk -- or, one behind a slow i/f).
>>
>> And, if something else is competing for bandwidth to one of those
>> stores (local or remote), the estimated time remaining (H:MM:SS!)
>> can change wildly -- whereas normally it is incredibly linear.
>
> If there is resource competition then time to execute code can be very tricky
> particularly if it messes up assumptions about cache. It is particularly bad
> for code with big data that only just fits in main memory.

But cache can also be *disk* cache. Particularly when you are
making changes to the store (i.e., installing updates).

>>> Heaven knows how long it would have taken on a slower machine with spinning
>>> rust.
>>>
>>> WTF can't they get something so basic right? They must know approximately
>>> how long each component install will take +/-10% from the moment that the
>>> installer code begins to run on the system.
>>
>> Only if you know (or can control) what else is happening in the machine.
>
> But at boot time that is a given for the OS updater.

Still dependent on the hardware being updated. Look at how long
it takes to boot into "safe mode"; I *think* one difference is
that modules are discretely loaded.

All progress indicators are "broken" so there has to be some
fundamental issue we aren't thinking about. I designed my current
project so that updates happen while the applications are running;
the binaries are loaded and then the mapping into them is switched
over to the new ALONGSIDE the old. When all LIVE references to
the old are gone, then the old is unloaded.

>> The solution is to come up with processes/policies that don't
>> interfere with the user's other activities.  MS is notorious
>> for thinking they "own" the machine instead of acting as
>> a friendlier playmate.
>
> I think it is a throwback to the sysmodal priority of OS/2.
>
> The other pet hate I have is when there is an email server glitch on some email
> clients the OAuth2 password challenge popup window appears *behind* all other
> open windows where you can't even see it!
>
> No more emails will flow until you find the damn window and respond to it. This
> can be when you next reboot.

That seems to be a system bug that affects lots of apps. One *thinks*
that your actions control the Z layering of windows. But, often,
a "new" window opens UNDER an existing window -- so you never see it.

And, some windows aren't managed the same as "application windows" so
you might not have an indication on the taskbar that there *is*
some other window (e.g., dialog) hiding on (under?) your display
unless you deliberately move things around.

The whole Windows desktop is a kludge. Icons move around of their
own accord. Save something to "Desktop" and it may not be visible
(even with a manual REFRESH of the desktop). Windows underlaying
others.

Don't you just love when screensavers go into hyper mode (timers
that lose track of time??). Or, change display resolution?

[No doubt someone forgetting to check malloc or a constructor
because they haven't a clue as to how to HANDLE a fault even
if they knew of it!]

At least the (asynchronous) modal "Printer (paper) Error" dialogs are gone
(what idiot thought a printer error would be of such great importance
that it should override all other activities??)

On 10/16/2023 1:50 PM, Don Y wrote:
>>>> WTF can't they get something so basic right? They must know approximately
>>>> how long each component install will take +/-10% from the moment that the
>>>> installer code begins to run on the system.
>>>
>>> Only if you know (or can control) what else is happening in the machine.
>>
>> But at boot time that is a given for the OS updater.
>
> Still dependent on the hardware being updated.  Look at how long
> it takes to boot into "safe mode"; I *think* one difference is
> that modules are discretely loaded.

I wonder if that may also be part of the variability;
we think of updates as "just rewrite a part of the disk"
but, the process may rely on running services to make certain
changes to the machine state as a precondition (or post-condition)
of the update process.

Rather than making the updater do all of the work (e.g., to
UN-install certain components), the update may call on existing
code to perform those actions. How long does it take version X
of the existing code to perform them vs. version Y? And, what if
NO version of such a service is present?

E.g., my gesture recognizer uses templates built of bezier segments.
These have to be converted into linear approximations -- based on
the technology of the transducer that the user is employing.
So, the amount of "work" varies from one seat to another.

And, I expect the existing code to perform those conversions
(because IT knows the form that they are in presently; why would
I want an updater to have to know how to handle EVERY possible
prior representation when the existing module already knows that?)

On 10/16/2023 7:53 AM, Ralph Mowery wrote:
> I bought a cheep wireless keyboard and mouse for a win 11 computer I
> just bought. Is it win 11 that the mouse is jerkey moving around on the
> screen and the keyboard sometime takes a few seconds to respond ? Or is
> it the cheep keyboard and mouse ?

The devices likely just "look" like typical USB devices
(assuming you have a radio that plugs into the USB port).
So, something on the out-side of the USB interface
is likely introducing the problem.

Does it exist with a *wired* keyboard/mouse?

I have a variety of wireless (logitech and other) pointing
devices, motion controllers and keyboards that all are
well-behaved (assuming their batteries are charged and there
is nothing else competing for RF)

mandag den 16. oktober 2023 kl. 16.53.58 UTC+2 skrev Ralph Mowery:
> In article <ugjckn$1e0a2$1...@dont-email.me>, '''newspam'''@nonad.co.uk
> says...
> > can change wildly -- whereas normally it is incredibly linear.
> >
> > If there is resource competition then time to execute code can be very
> > tricky particularly if it messes up assumptions about cache. It is
> > particularly bad for code with big data that only just fits in main memory.
> >
> >
> I bought a cheep wireless keyboard and mouse for a win 11 computer I
> just bought. Is it win 11 that the mouse is jerkey moving around on the
> screen and the keyboard sometime takes a few seconds to respond ? Or is
> it the cheep keyboard and mouse ?

it is the cheap keyboard and mouse

On Wed, 11 Oct 2023 14:13:56 -0700, john larkin <jl@650pot.com> wrote:

>On Wed, 11 Oct 2023 02:24:40 -0000 (UTC), "Don" <g@crcomp.net> wrote:
>
>>john larkin wrote:
>>>
>>> I just "upgraded" from Windows 7 to 11. The new PC is a lot faster
>>> running Spice.
>>>
>>> But the File Explorer is a horror. When I drag/drop a file, the cursor
>>> becomes a giant ugly icon. When I copy a file where a copy already
>>> exists, I have to go through a secondary dialog to compare file
>>> attributes.
>>>
>>> If I right-click on a file, simple things like delete and rename are a
>>> secondary operation!
>>
>>reg.exe add "HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32" /f /ve
>>
>>restores the familiar <right click> popup menu, for the current user.
>>The popup menu adjustment and additional alterations are available at:
>>
>><https://www.tomshardware.com/how-to/worst-windows-11-features-fix-them>
>>
>>Danke,
>
>The registry patch worked!
>
>1e6 thanks.

Except I came in this morning and it doesn't work any more. Maybe
Microsoft did an update and broke the regtistry patch.

In article <ugka14$2f6rv$2@dont-email.me>, blockedofcourse@foo.invalid
says...
>
> Does it exist with a *wired* keyboard/mouse?
>
> I have a variety of wireless (logitech and other) pointing
> devices, motion controllers and keyboards that all are
> well-behaved (assuming their batteries are charged and there
> is nothing else competing for RF)
>
>
>

Have not tried it with a wired mouse. My win 10 cmputers work fine with
other mice. I thought I was getting a Logitech but looking at it see
it is a similar looking off brand.

Going to try a real Logitech when I get to the store.

On 10/16/2023 4:55 PM, Ralph Mowery wrote:
> In article <ugka14$2f6rv$2@dont-email.me>, blockedofcourse@foo.invalid
> says...
>>
>> Does it exist with a *wired* keyboard/mouse?
>>
>> I have a variety of wireless (logitech and other) pointing
>> devices, motion controllers and keyboards that all are
>> well-behaved (assuming their batteries are charged and there
>> is nothing else competing for RF)
>
> Have not tried it with a wired mouse. My win 10 cmputers work fine with
> other mice. I thought I was getting a Logitech but looking at it see
> it is a similar looking off brand.
>
> Going to try a real Logitech when I get to the store.

Their "universal" USB transceiver allows multiple devices to
share a single USB connection -- unlike the old interfaces
that were "ward-wired" to specific products. I "collect"
them when I come across them as it lets me pair a single
keyboard (or mouse) to multiple machines -- if I have a
transceiver available for each!

[This seems to be the new norm -- I note that my gyromouse
and keyboard (gyrokeyboard?) also share a single receiver
(though it isn't as miniaturized as the Logitech ones).]

OTOH, I've not tried two mice or two keyboards on the same
transceiver operating concurrently. I wonder if things like
CAPS LOCK would function independently or if both would
share a setting? Could you click on one mouse, do the same click
on another, then release the first and have the click
persist because of the second? (i.e., where is the state
maintained)

On Sat, 14 Oct 2023 18:09:47 -0400, legg <legg@nospam.magma.ca> wrote:

>On Thu, 12 Oct 2023 09:12:15 -0700, John Larkin <jl@997PotHill.com>
>wrote:
>
>>On Thu, 12 Oct 2023 11:43:39 -0400, legg <legg@nospam.magma.ca> wrote:
>>
>>>On Tue, 10 Oct 2023 15:04:57 -0700, john larkin <jl@650pot.com> wrote:
>>>
>>>>
>>>>I just "upgraded" from Windows 7 to 11. The new PC is a lot faster
>>>>running Spice.
>>>>
>>>>But the File Explorer is a horror. When I drag/drop a file, the cursor
>>>>becomes a giant ugly icon. When I copy a file where a copy already
>>>>exists, I have to go through a secondary dialog to compare file
>>>>attributes.
>>>>
>>>>If I right-click on a file, simple things like delete and rename are a
>>>>secondary operation!
>>>>
>>>>So, does anyone use a Classic Shell type add-on to get things back to
>>>>simple? Our IT consultant doesn't want me to do that, but the W11
>>>>stuff is a horror.
>>>>
>>>>A new PC is a traumatic life event.
>>>>
>>>
>>>Got my mother's W7 to W11 'upgrade' to fairly resemble
>>>previous GUI prefs using the shell and other powershell
>>>manipulations, last October.
>>
>>I'd be interested in what all you did. My new W11 machine is getting
>>to be mostly usable, after a lot of work.
>
>No list, just had to chip away at it, one 'feature' at a time.
>
>Powershell was first used, I think, to get rid of Cortana.
>Was required later for Edge and other bumph.
>
>Then start menu and desktop could be rebuilt, without the
>built-in flash.
<snip>

Edge reinstalled itself after six days with a later version.

Trying to terminate active processes is just an exercise
in wack-a-mole.

Attempts to remove Edge 'Appx' features using powershell
(three were listed by getAppx ) just return reports of
incorrect command syntax.

RL

On 10/18/2023 10:26 PM, legg wrote:
> On Sat, 14 Oct 2023 18:09:47 -0400, legg <legg@nospam.magma.ca> wrote:
>
>> On Thu, 12 Oct 2023 09:12:15 -0700, John Larkin <jl@997PotHill.com>
>> wrote:
>>
>>> On Thu, 12 Oct 2023 11:43:39 -0400, legg <legg@nospam.magma.ca> wrote:
>>>
>>>> On Tue, 10 Oct 2023 15:04:57 -0700, john larkin <jl@650pot.com> wrote:
>>>>
>>>>>
>>>>> I just "upgraded" from Windows 7 to 11. The new PC is a lot faster
>>>>> running Spice.
>>>>>
>>>>> But the File Explorer is a horror. When I drag/drop a file, the cursor
>>>>> becomes a giant ugly icon. When I copy a file where a copy already
>>>>> exists, I have to go through a secondary dialog to compare file
>>>>> attributes.
>>>>>
>>>>> If I right-click on a file, simple things like delete and rename are a
>>>>> secondary operation!
>>>>>
>>>>> So, does anyone use a Classic Shell type add-on to get things back to
>>>>> simple? Our IT consultant doesn't want me to do that, but the W11
>>>>> stuff is a horror.
>>>>>
>>>>> A new PC is a traumatic life event.
>>>>>
>>>>
>>>> Got my mother's W7 to W11 'upgrade' to fairly resemble
>>>> previous GUI prefs using the shell and other powershell
>>>> manipulations, last October.
>>>
>>> I'd be interested in what all you did. My new W11 machine is getting
>>> to be mostly usable, after a lot of work.
>>
>> No list, just had to chip away at it, one 'feature' at a time.
>>
>> Powershell was first used, I think, to get rid of Cortana.
>> Was required later for Edge and other bumph.
>>
>> Then start menu and desktop could be rebuilt, without the
>> built-in flash.
> <snip>
>
> Edge reinstalled itself after six days with a later version.
>
> Trying to terminate active processes is just an exercise
> in wack-a-mole.
>
> Attempts to remove Edge 'Appx' features using powershell
> (three were listed by getAppx ) just return reports of
> incorrect command syntax.

Are you sure edge is not associated with ANYTHING on the machine?
NOT the default browser?
NOT associated with any file extensions?

Searching the registry for any keys/values that reference "edge" is
probably also a good idea ("UpdateEdge", etc.)

On Thursday, October 19, 2023 at 6:26:29 AM UTC+1, legg wrote:
> On Sat, 14 Oct 2023 18:09:47 -0400, legg <le...@nospam.magma.ca> wrote:
>
> >On Thu, 12 Oct 2023 09:12:15 -0700, John Larkin <j...@997PotHill.com>
> >wrote:
> >
> >>On Thu, 12 Oct 2023 11:43:39 -0400, legg <le...@nospam.magma.ca> wrote:
> >>
> >>>On Tue, 10 Oct 2023 15:04:57 -0700, john larkin <j...@650pot.com> wrote:
> >>>
> >>>>
> >>>>I just "upgraded" from Windows 7 to 11. The new PC is a lot faster
> >>>>running Spice.
> >>>>
> >>>>But the File Explorer is a horror. When I drag/drop a file, the cursor
> >>>>becomes a giant ugly icon. When I copy a file where a copy already
> >>>>exists, I have to go through a secondary dialog to compare file
> >>>>attributes.
> >>>>
> >>>>If I right-click on a file, simple things like delete and rename are a
> >>>>secondary operation!
> >>>>
> >>>>So, does anyone use a Classic Shell type add-on to get things back to
> >>>>simple? Our IT consultant doesn't want me to do that, but the W11
> >>>>stuff is a horror.
> >>>>
> >>>>A new PC is a traumatic life event.
> >>>>
> >>>
> >>>Got my mother's W7 to W11 'upgrade' to fairly resemble
> >>>previous GUI prefs using the shell and other powershell
> >>>manipulations, last October.
> >>
> >>I'd be interested in what all you did. My new W11 machine is getting
> >>to be mostly usable, after a lot of work.
> >
> >No list, just had to chip away at it, one 'feature' at a time.
> >
> >Powershell was first used, I think, to get rid of Cortana.
> >Was required later for Edge and other bumph.
> >
> >Then start menu and desktop could be rebuilt, without the
> >built-in flash.
> <snip>
>
> Edge reinstalled itself after six days with a later version.
>
> Trying to terminate active processes is just an exercise
> in wack-a-mole.
>
> Attempts to remove Edge 'Appx' features using powershell
> (three were listed by getAppx ) just return reports of
> incorrect command syntax.
>
> RL

There are plenty of utils to "debloat" windows. Try this:- https://github..com/ChrisTitusTech/winutil

On 10/19/2023 10:06 AM, John May wrote:
> There are plenty of utils to "debloat" windows. Try this:- https://github.com/ChrisTitusTech/winutil

The fact that someone would NEED to develop such a tool
speaks volumes about the OS!

[It's also amusing how "OS" has morphed into referring to
EVERYTHING on the machine (before "user-installed apps").
I guess "games" are considered "services"? <rolls eyes>]

In article <ugs0qp$havb$1@dont-email.me>, blockedofcourse@foo.invalid
says...
>
> The fact that someone would NEED to develop such a tool
> speaks volumes about the OS!
>
> [It's also amusing how "OS" has morphed into referring to
> EVERYTHING on the machine (before "user-installed apps").
> I guess "games" are considered "services"? <rolls eyes>]
>
>
>

There has been a 'need' for utility tools by others as far back as the
old Radio Shack computers ( TRS 80 ) and the first computers using
Microsoft. Seems that in over 45 years that has not changed.

On 10/19/2023 12:49 PM, Ralph Mowery wrote:
> In article <ugs0qp$havb$1@dont-email.me>, blockedofcourse@foo.invalid
> says...
>>
>> The fact that someone would NEED to develop such a tool
>> speaks volumes about the OS!
>>
>> [It's also amusing how "OS" has morphed into referring to
>> EVERYTHING on the machine (before "user-installed apps").
>> I guess "games" are considered "services"? <rolls eyes>]
>
> There has been a 'need' for utility tools by others as far back as the
> old Radio Shack computers ( TRS 80 ) and the first computers using
> Microsoft. Seems that in over 45 years that has not changed.

CP/M machines (before MS was more than an *app* developer FOR
those machines) had very little fluff -- yet managed to be
the personal computers of their day. The commands built-into
the CCP were few and simple: DIRectory, ERAse, SAVE, TYPE
and USER. Transient commands were mainly concerned with
maintaining the OS itself (ASM, DDT, SYSGEN, MOVCPM, PIP, DUMP,
LOAD, MOVCPM).

"Utilities" aren't part of the OS. How is Solitaire a tool in any
sense of the word? How essential is Sound Recorder to the
use and operation of the system? Or Paint? Why isn't MSOffice
part of the OS?

MS tried to play the "IE-is-an-integrated-part-of-the-OS" card
years ago. And, *could* have made it an ESSENTIAL component.
But, they made the mistake of also having Windows Explorer
to undercut that claim (and, even THAT isn't an essential
component; you can navigate and modify the filesystem from
the command line).

The Linux camp (should) understand that the kernel is
not the same thing as the userland -- else why so many
distributions (with the same kernels)? The *BSD camps
bundle lots of "essential apps" with the kernel -- but,
not with a focus on end users as much as sysadmins
(again, to maintain the system, not facilitate web
browsing, playing games, GUIs, etc.)

Do you consider the radio in your vehicle an essential part
of the vehicle? Or, the wheel covers (gee, most cars don't
have them!)

The risk of letting the distinction be eroded is that
folks mistakenly EXPECT to have all of this cruft so
future works are always burdened, unnecessarily.

In article <ugs7c3$iu76$1@dont-email.me>, blockedofcourse@foo.invalid
says...
>
> "Utilities" aren't part of the OS. How is Solitaire a tool in any
> sense of the word? How essential is Sound Recorder to the
> use and operation of the system? Or Paint? Why isn't MSOffice
> part of the OS?
>
>

Paint or solitary is not, but a copy command should be and some other
things that are used only to work with the disk.