On Mon, 11 Apr 2022 23:08:47 +0100, J. P. Gilliver (John) wrote:
>
> On Mon, 11 Apr 2022 at 12:52:00, Stan Brown <the_stan_brown@fastmail.fm>
> wrote (my responses usually FOLLOW):
> >The page being discussed is
> ><https://brownmath.com/general/10tip.htm>
> >
> >On Mon, 11 Apr 2022 12:53:24 +0100, J. P. Gilliver (John) wrote:
> >> A coupe of thoughts/observations:
> >> 1. (This may be a Chrome thing rather than anything to do with the page,
> >> but didn't happen with a few of the other links on the page I tried):
> >> When I hover over "10 Ways to Open the Command Prompt in Windows 10", my
> >> where-is-that-going indicator shows
> >> "howtogeek.com/235101/10-ways-to-open-the-command-prompt-in-windows-10/",
> >> then after a second or two changes to
> >> "https://www.howtogeek.com/235101/10-ways-to-open-the-command-prompt-in-w
> >> indows-10/" - i. e. it adds the "https://www." bit. Not important, just
> >> odd!
> >
> >I think it's a Chrome thing, specifically related to some setting. It
> >doesn't happen for me in Chrome.
> >
> >I'm sorry, I don't know which setting controls it. I thought it was
> >related to "Always show full URLs", which you access by right-
> >clicking the URL box. By default it's unchecked, but I have it
> >checked. However, when I tried unchecking it, I got the "simplified"
> >URL in the address bar, but hovering over the link I still got the
> >full URL immediately.
>
> I just tried turning that on, and it didn't seem to make any difference.
> When I referred to my "where-is-that-going indicator", I meant something
> that shows where a link would go, that I have in the bottom-left corner
> (though can be moved to any of the other corners), which I now find is
> an extension called Show Title Tag
> https://chrome.google.com/webstore/detail/show-title-tag/pkbffbhglicfngmp
> pdlpmpblfgnkdgio . No problem though, just a curiosity!

That explains why I couldn't duplicate your experience. I do see the
target URL in the lower left when I hover over a link, just as you
do, but it's produced by Chrome, not by an extension.

....

> >I've added a condensed version of this, at
> ><https://brownmath.com/general/10tip.htm#U20220411a>
> >If you feel moved to, please take a look and let me know if I wrote
> >anything that's false or confusing.
>
> you said "Alt?Gr+e gives é, Alt?Gr+2 e gives ë, and so forth" - the
> first is a _combination_, the second is a _sequence_ (i. e. you press
> AltGr and 2 [or 6 or #] _then_ the character to be modified).

In Googling, I've found numerous pages that indicate the AltGr key
produces different characters from the same keypresses on different
national keyboards. That's way outside the scope of what I want to
handle in my page, so I got less specific about key combinations, and
the text you quote no longer exists. I do still mention the AltGr
key, though the link has changed because it now has its own section
head:

<https://brownmath.com/general/10tip.htm#AltGr>

While experimenting with the OSK (on-screen Keyboard), I docked it
and then couldn't figure out how to undock it again. Googling for
_that_, I ran across a mention of the Windows 10 touch keyboard,
which also works beautifully with a mouse. It can produce many more
characters than you can with the AltGr key.

<https://brownmath.com/general/10tip.htm#TouchKeyboard>

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
Shikata ga nai...

On Tue, 12 Apr 2022 23:26:51 +0100, John <Man@the.keyboard> wrote:

>On Tue, 12 Apr 2022 07:19:23 -0700, Ken Blake <Ken@invalid.news.com>
>wrote:
>
>>On Tue, 12 Apr 2022 13:57:33 +0100, John <Man@the.keyboard> wrote:
>>
>>>On Mon, 11 Apr 2022 21:01:01 -0500, VanguardLH <V@nguard.LH> wrote:
>>>
>>>>Rene Lamontagne wrote:
>>>>
>>>>> Okidata c5150n
>>>>
>>>>The latest driver Okidata provide works under Windows 7. So, after
>>>>Windows 8, 10, 11, and whatever comes next, that 15-year old laser
>>>>printer still running well is going to be a bitch to get working, if at
>>>>all, on later versions of Windows. So, you still have a Win7 host in
>>>>your intranet on which to use that printer, or using a VM with Win7 as
>>>>the guest OS? What are your plans to keep that printer working through
>>>>later versions of Windows?
>>>
>>> My plans with "My Last Computer", a beast of a W7 box, was to die
>>>finally before I needed a new one. That does not seem to be working
>>>too well, to the endless disappointment of various sisters.
>>
>>
>>My current computer, built last October, is a high-powered Windows 11
>>computer. It's nor exactly a plan, but since I'm 84, there's a good
>>chance that it will be the last computer I ever buy.
>
> Just to be argumentative, you do know that you *could* buy another
>one today, yes? :)

Could? Yes, of course. Likely to? No.

> Oh, so could I but I have a great dislike for Win-ten and 'leven so I
>won't.

I think 10 and 11 are both fine.

>My current Win-box is about the most powerful Win-7 thing I
>could find so a "new" one would probably be a poor investment.
>
> Still, no one in my family in the last century or so has lasted to 80
>so the current box has a good chance of out-living me.
>
> That is also my main excuse for not having a dog.

Don't get a dog that run Windows 10 or 11. You don't like them.

On Tue, 12 Apr 2022 13:49:01 -0700, Stan Brown
<the_stan_brown@fastmail.fm> wrote:

>On Mon, 11 Apr 2022 08:25:57 -0700, Ken Blake wrote:
>>
>> On Sun, 10 Apr 2022 16:58:43 -0700, Stan Brown
>> <the_stan_brown@fastmail.fm> wrote:
>>
>> >On Sun, 10 Apr 2022 14:27:28 -0700, Ken Blake wrote:
>> >>
>> >> I'm running a Canon LiDE 60 here. I installed it under Windows 10 and
>> >> it now runs without a problem in 11. I don't remember doing anything
>> >> special to get it to work.
>> >>
>> >> Telling you that doesn't help solve your problem, but it least lets
>> >> you know that a solution is possible.
>> >
>> >Maybe it does help, Ken. I have an LiDE 50, but the only difference
>> >between the two is that the 50 doesn't do some metric size of paper.
>> >Is your Lide 60 driver installer somewhere I can grab it?
>>
>> Sorry, I don't remember where I got it. If you trust me, I'll be glad
>> to e-mail you what I have.. Tell me whether to send it, and whether
>> you run 32-bit or 64-bit Windows.
>
>Thanks, Ken. It's 64-bit Windows 10. And my address in the From
>header is real.

On its way to you.

"J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote:
> On Tue, 12 Apr 2022 at 19:21:43, Frank Slootweg <this@ddress.is.invalid>
> wrote (my responses usually FOLLOW):
> []
> > Bottom line: Getting a working printer driver has been a non-issue for
> >several (3+) decades, thanks to this (de facto) industry standard.
> >
> >'Printer Command Language'
> ><https://en.wikipedia.org/wiki/Printer_Command_Language>
> >
> >[...]
>
> What percentage of models - and of printers (not the same answer as
> there may be more, or fewer, sold of the models that do/do not) support
> PCL?

I have no data on that - never had a need to look for it -, but I
think you would have a hard time finding a printer which does not
support PCL. A non-HP printer will perhaps/probably have another command
language as well, but at least also PCL.

> It's like the same claim for Postscript.

I thought that as well, until I was advised that Postscript is much
more costly to implement and hence is mostly only available in high-end
printers (many hundreds of dollars), so not in inexpensive ones. At the
time, I checked some sites are found that indeeed to be the case.

> Even if a model does support PCL or Postscript, there's still the matter
> of getting it over USB or whatever interface is used: it can be argued
> that that's not really a driver matter, but from the average user's POV,
> it in effect is.

USB should be no problem, because USB has been used for printers for a
long time. But if you have a printer with for example a parallel
interface ('Centronics') that could be a problem if the printer device
driver is not cleanly seperated from the parallel interface driver.
(OTOH, I had such a printer and just bought a USB-to-parallel cable
(with built-in electronics) and that worked flawlessly.)

On Wed, 13 Apr 2022 at 17:50:00, Frank Slootweg <this@ddress.is.invalid>
wrote (my responses usually FOLLOW):
>"J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote:
>> On Tue, 12 Apr 2022 at 19:21:43, Frank Slootweg <this@ddress.is.invalid>
>> wrote (my responses usually FOLLOW):
>> []
>> > Bottom line: Getting a working printer driver has been a non-issue for
>> >several (3+) decades, thanks to this (de facto) industry standard.
>> >
>> >'Printer Command Language'
>> ><https://en.wikipedia.org/wiki/Printer_Command_Language>
>> >
>> >[...]
>>
>> What percentage of models - and of printers (not the same answer as
>> there may be more, or fewer, sold of the models that do/do not) support
>> PCL?
>
> I have no data on that - never had a need to look for it -, but I
>think you would have a hard time finding a printer which does not
>support PCL. A non-HP printer will perhaps/probably have another command
>language as well, but at least also PCL.

If that truly is the case, why do we continue to hear so much discussion
of problems with printer drivers? Why indeed _are_ there still printer
drivers, and it not be part of Windows? In the same way memory stick
drivers are mostly a non-problem now. (I remember under '98SE each
memory stick maker had their own driver; someone did produce a universal
one, but it wasn't part of Windows. Nowadays, people just expect memory
sticks to just plug in and work. [OK, there are the odd problem - FAT
vs. NTFS, page sizes, and so on - but they're the exception these
days.])
>
>> It's like the same claim for Postscript.
>
> I thought that as well, until I was advised that Postscript is much
>more costly to implement and hence is mostly only available in high-end
>printers (many hundreds of dollars), so not in inexpensive ones. At the
>time, I checked some sites are found that indeeed to be the case.

OK.
>
>> Even if a model does support PCL or Postscript, there's still the matter
>> of getting it over USB or whatever interface is used: it can be argued
>> that that's not really a driver matter, but from the average user's POV,
>> it in effect is.
>
> USB should be no problem, because USB has been used for printers for a
>long time. But if you have a printer with for example a parallel
>interface ('Centronics') that could be a problem if the printer device
>driver is not cleanly seperated from the parallel interface driver.
>(OTOH, I had such a printer and just bought a USB-to-parallel cable
>(with built-in electronics) and that worked flawlessly.)

True. Though not all such "cables" are the same. (I wish people wouldn't
call such things cables - to me, a cable just consists of wires and
connectors. But I've even heard a power brick being referred to as a
"cable". There at least it's obvious that it isn't, but in the case of
say a USB to serial or parallel adapter, calling it just a cable might
lead some people not to realise it has electronics in it.) Some such
cables are more bidirectional than others.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Science fiction is escape into reality - Arthur C Clarke

On 4/14/2022 12:15 AM, J. P. Gilliver (John) wrote:
> On Wed, 13 Apr 2022 at 17:50:00, Frank Slootweg <this@ddress.is.invalid> wrote (my responses usually FOLLOW):
>> "J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote:
>>> On Tue, 12 Apr 2022 at 19:21:43, Frank Slootweg <this@ddress.is.invalid>
>>> wrote (my responses usually FOLLOW):
>>> []
>>> >  Bottom line: Getting a working printer driver has been a non-issue for
>>> >several (3+) decades, thanks to this (de facto) industry standard.
>>> >
>>> >'Printer Command Language'
>>> ><https://en.wikipedia.org/wiki/Printer_Command_Language>
>>> >
>>> >[...]
>>>
>>> What percentage of models - and of printers (not the same answer as
>>> there may be more, or fewer, sold of the models that do/do not) support
>>> PCL?
>>
>>  I have no data on that - never had a need to look for it -, but I
>> think you would have a hard time finding a printer which does not
>> support PCL. A non-HP printer will perhaps/probably have another command
>> language as well, but at least also PCL.
>
> Why indeed _are_ there still printer drivers, and it not be part of Windows?
Microsoft has made a couple printer frameworks, and
this can provide an alternative driver. The manufacturer
still has to put their particulars into the driver, at
deployment time ("some.ppd"). But the main part of the
driver is done for them.

One of the downfalls of the "Universal Postscript driver" was
that pages were rendered as pixmaps and not as Postscript
text strings. And this means that if you use that as part
of a Distiller workflow, you cannot search or copy text
(without an OCR step which might not work well). That's why
I had to reject a later version of that. Not spiffy enough.
I was using a regular Postscript driver, as a path to making
PDFs without a PDF save option.

It's possible there is a Universal PCL as well. But if the
manufacturer refuses to support old printers, then
the framework (without the file added to it), isn't
going to work.

Try not to get too excited about this, as it's not really
ready for primetime (not user friendly). But at least it
shows that Microsoft did think about your observation,
that the printer situation could be "tidied a bit".
It's not in the manufacturers best interests, to support
your old printer.

https://support.hp.com/us-en/drivers/selfservice/hp-universal-print-driver-series-for-windows/503548/model/3271558

The manufacturers are like kids eating their porridge
in the morning. You can put down a steaming bowl,
and the kid won't eat it. That's how it is with
printer drivers.

Paul

"J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote:
> On Wed, 13 Apr 2022 at 17:50:00, Frank Slootweg <this@ddress.is.invalid>
> wrote (my responses usually FOLLOW):
> >"J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote:
> >> On Tue, 12 Apr 2022 at 19:21:43, Frank Slootweg <this@ddress.is.invalid>
> >> wrote (my responses usually FOLLOW):
> >> []
> >> > Bottom line: Getting a working printer driver has been a non-issue for
> >> >several (3+) decades, thanks to this (de facto) industry standard.
> >> >
> >> >'Printer Command Language'
> >> ><https://en.wikipedia.org/wiki/Printer_Command_Language>
> >> >
> >> >[...]
> >>
> >> What percentage of models - and of printers (not the same answer as
> >> there may be more, or fewer, sold of the models that do/do not) support
> >> PCL?
> >
> > I have no data on that - never had a need to look for it -, but I
> >think you would have a hard time finding a printer which does not
> >support PCL. A non-HP printer will perhaps/probably have another command
> >language as well, but at least also PCL.
>
> If that truly is the case, why do we continue to hear so much discussion
> of problems with printer drivers?

Because - apparently - most people do not know that most printers
support PCL and - apparently - most printer manufacturers - probably
including HP - do not 'advertize' that their printers support PCL.

> Why indeed _are_ there still printer
> drivers, and it not be part of Windows?

Because most printers have *similar* functionality/functions, but not
the *exact same* functionality. So if the printer driver issues a (set
of) PCL command(s), which this particular printer can not handle, things
will not work as expected. For example selecting the second paper tray
of a printer which doesn't have one.

So *if* a custom driver is available, that one should be used, but if
there isn't one, use a generic PCL driver.

> In the same way memory stick
> drivers are mostly a non-problem now. (I remember under '98SE each
> memory stick maker had their own driver; someone did produce a universal
> one, but it wasn't part of Windows. Nowadays, people just expect memory
> sticks to just plug in and work. [OK, there are the odd problem - FAT
> vs. NTFS, page sizes, and so on - but they're the exception these
> days.])

Printers vary much, much more in functionality than memory sticks do,
hence the printer situation is more complex.

> >> It's like the same claim for Postscript.
> >
> > I thought that as well, until I was advised that Postscript is much
> >more costly to implement and hence is mostly only available in high-end
> >printers (many hundreds of dollars), so not in inexpensive ones. At the
> >time, I checked some sites are found that indeeed to be the case.
>
> OK.
> >
> >> Even if a model does support PCL or Postscript, there's still the matter
> >> of getting it over USB or whatever interface is used: it can be argued
> >> that that's not really a driver matter, but from the average user's POV,
> >> it in effect is.
> >
> > USB should be no problem, because USB has been used for printers for a
> >long time. But if you have a printer with for example a parallel
> >interface ('Centronics') that could be a problem if the printer device
> >driver is not cleanly seperated from the parallel interface driver.
> >(OTOH, I had such a printer and just bought a USB-to-parallel cable
> >(with built-in electronics) and that worked flawlessly.)
>
> True. Though not all such "cables" are the same. (I wish people wouldn't
> call such things cables - to me, a cable just consists of wires and
> connectors. But I've even heard a power brick being referred to as a
> "cable". There at least it's obvious that it isn't, but in the case of
> say a USB to serial or parallel adapter, calling it just a cable might
> lead some people not to realise it has electronics in it.) Some such
> cables are more bidirectional than others.

Valid point(s), but *I* did say "(with built-in electronics)", didn't
I!? :-)

(In my case, the electronics is built in the (transparent plastic)
casing of the parallel connector.)

On Sat, 9 Apr 2022 21:49:48 -0700, Stan Brown wrote:
>
> Canon never created digitally signed drivers for the LiDE 50 or 60
> scanner. I was nonetheless able to install the driver through the
> procedure documented at
> <https://BrownMath.com/general/10tip.htm#LegacyDrivers>
>
> But after a reboot, Windows won't let driver. Windows doesn't pop up
> an error message; Irfanview just can't connect to the driver. So I
> have to do this:
> 1. In an admin command prompt, "bcdedit -set testsigning on".
> 2. Reboot. (Windows shows the "Test Mode" warning when I log in.)
> 3. Scan my documents.
> 4. In an admin command prompt, "bcdedit -set testsigning off".
> 5. Reboot. (And Windows is no longer in Test Mode.)

I haven't yet installed the driver Ken sent me (which came from the
Canon European website), largely because I haven't figured out how to
make the other driver go away. But I was in a rush to scan something
a few minutes ago, so I opened an admin command prompt and typed
bcdedit -set testsigning yes
Before rebooting, out of curiosity I fired up Irfanview, and it was
able to connect with the scanner! I can't account for this; I'm sure
there were past occasions where I needed to reboot.

Then I typed
bcdedit -set testsigning no
in the admin command prompt, started Irfanview again, and it was
still connected to the scanner.

My PC was not displaying the "Test Mode" flag before I started doing
bcdedit, mot after the "yes" setting. not after I returned it to
"no".

I'm baffled. I'd like to understand this, if someone has an idea
what's going on. Could this possibly be related to this week's
Windows updates?

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
Shikata ga nai...

Stan Brown wrote:

> On Sat, 9 Apr 2022 21:49:48 -0700, Stan Brown wrote:
>>
>> Canon never created digitally signed drivers for the LiDE 50 or 60
>> scanner. I was nonetheless able to install the driver through the
>> procedure documented at
>> <https://BrownMath.com/general/10tip.htm#LegacyDrivers>
>>
>> But after a reboot, Windows won't let driver. Windows doesn't pop up
>> an error message; Irfanview just can't connect to the driver. So I
>> have to do this:
>> 1. In an admin command prompt, "bcdedit -set testsigning on".
>> 2. Reboot. (Windows shows the "Test Mode" warning when I log in.)
>> 3. Scan my documents.
>> 4. In an admin command prompt, "bcdedit -set testsigning off".
>> 5. Reboot. (And Windows is no longer in Test Mode.)
>
> I haven't yet installed the driver Ken sent me (which came from the
> Canon European website), largely because I haven't figured out how to
> make the other driver go away. But I was in a rush to scan something
> a few minutes ago, so I opened an admin command prompt and typed
> bcdedit -set testsigning yes

Wrong value of "yes". Valid string values are:
on
off

See:
https://docs.microsoft.com/en-us/windows-hardware/drivers/install/the-testsigning-boot-configuration-option

When you run the "bcdedit" command (no args), it may show:

testsigning Yes

but "yes" is not a valid argument value when changing state. That is
just showing active state. There wasn't an error message after issuing
the command with a value of "yes"? From the MS and other articles,
valid arg values are "on" or "off", not "yes" or "no".

Note: While "/" or "-" can sometimes be used interchangeably for a
switch, sometimes only one is valid. When I run "bcdedit /?", its
stdout shows "/" is the switch delimiter. The article shows "-". I'd
go with what the program says to use for the switch delimiter which is
a slash.

> Before rebooting, out of curiosity I fired up Irfanview, and it was
> able to connect with the scanner! I can't account for this; I'm sure
> there were past occasions where I needed to reboot.

After issuing "testsigning yes" (which should've been "testsigning on"),
but before rebooting, was "Test mode" still shown in one, or more,
corners of the desktop (since presumably you were in "off" test mode
enabled before issuing the "yes" command)?

> Then I typed
> bcdedit -set testsigning no
> in the admin command prompt, started Irfanview again, and it was
> still connected to the scanner.

It's a boot-time state. Until you reboot, whatever was the test mode
state remains as it is.

> My PC was not displaying the "Test Mode" flag before I started doing
> bcdedit, mot after the "yes" setting. not after I returned it to
> "no".
>
> I'm baffled. I'd like to understand this, if someone has an idea
> what's going on. Could this possibly be related to this week's
> Windows updates?

Presumably you did "testsigning on" and rebooted, so no "Test mode"
flags, but maybe you forgot the reboot, so the previous "testsigning
off" mode was still in effect during the current Windows session. That
is:

testsigning off
reboot

and later you did:

testsigning on

but forgot the reboot. That would have "testsigning off" still active
in the current Windows session.

I don't know if the "Test mode" flags are affected until state changes
after a reboot. Maybe they don't stay in sync with the mode. However,
since you're using the wrong argument values, I'm not sure in which
state you were.

On Sun, 17 Apr 2022 15:42:21 -0500, VanguardLH wrote:
>
> Stan Brown wrote:
> > I haven't yet installed the driver Ken sent me (which came from the
> > Canon European website), largely because I haven't figured out how to
> > make the other driver go away. But I was in a rush to scan something
> > a few minutes ago, so I opened an admin command prompt and typed
> > bcdedit -set testsigning yes
>
> Wrong value of "yes". Valid string values are:
> on
> off
> See:
> https://docs.microsoft.com/en-us/windows-hardware/drivers/install/the-testsigning-boot-configuration-option
>
> When you run the "bcdedit" command (no args), it may show:
>
> testsigning Yes
>
> but "yes" is not a valid argument value when changing state. That is
> just showing active state. There wasn't an error message after issuing
> the command with a value of "yes"? From the MS and other articles,
> valid arg values are "on" or "off", not "yes" or "no".
>
> Note: While "/" or "-" can sometimes be used interchangeably for a
> switch, sometimes only one is valid. When I run "bcdedit /?", its
> stdout shows "/" is the switch delimiter. The article shows "-". I'd
> go with what the program says to use for the switch delimiter which is
> a slash.
>
> > Before rebooting, out of curiosity I fired up Irfanview, and it was
> > able to connect with the scanner! I can't account for this; I'm sure
> > there were past occasions where I needed to reboot.

And I should have said explicitly: since the scanner worked without a
reboot, I did not reboot.
> After issuing "testsigning yes" (which should've been "testsigning on"),
> but before rebooting, was "Test mode" still shown in one, or more,
> corners of the desktop (since presumably you were in "off" test mode
> enabled before issuing the "yes" command)?

"Test Mode" was not shown on the desktop at any time during today's
process, and in fact not since the last reboot. As I understand
things, I should not have been able to use the unsigned scanner
driver, but I could, so obviously my understanding is flawed.
> Presumably you did "testsigning on" and rebooted,

No. That's what was weird: it worked without a reboot. And, in
agreement with your next paragraph below, I think that the state
after I typed that command was the same as the state before I typed
it, so that I could have run the scanner without getting into bcdedit
at all. But I don't understand why that works without being in
Windows "Test Mode".

> I don't know if the "Test mode" flags are affected until state changes
> after a reboot. Maybe they don't stay in sync with the mode. However,
> since you're using the wrong argument values, I'm not sure in which
> state you were.

That's something I wondered about also. It would probably be better
to describe the states of the "Windows Boot Loader" flags as "what
will be in effect after the next reboot." In the past, when I set
testsigning to no, the "Test Mode" display didn't disappear until I
rebooted. But this time, since the scanner driver worked in non-"Test
Mode", I didn't reboot.

***** The mystery is, why did the scanner previously require a reboot
to get Windows into Test Mode before it would work, but now it works
happily without Windows being in Test Mode? *****

As for the argument values, they may be "wrong" according to some
reference, but my experimentation shows that the documentation you're
referring to is wrong, or at least incomplete.(*) Both "-set" and
"/set" work fine. Also, "on" and "off" appear to be synonyms for
"yes" and "no" in this context.

(*) Not that that's necessarily a flaw. Someone reading the
documentation is usually looking for _a_ way to accomplish something,
not all _possible_ ways. In my view, since the status display from a
plain "bcdedit" shows "yes" or "no", that's what good design would
say the program should accept. I wonder if originally those were the
only choices, and then later "on" and "off" were added as synonyms.

Here are the four commands I typed, and the results:

> C:\Windows\system32>bcdedit -set testsigning yes
> The operation completed successfully.
>
> C:\Windows\system32>bcdedit -set testsigning no
> The operation completed successfully.
>
> C:\Windows\system32>bcdedit /set testsigning yes
> The operation completed successfully.
>
> C:\Windows\system32>bcdedit /set testsigning no
> The operation completed successfully.

Afterward, I typed went back and retyped each command, followed by a
plain "bcdedit", to make sure that the value of testsigning changed
as I expected. It did. But what they were set to wasn't actually
relevant, since I never rebooted.

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
Shikata ga nai...

Stan Brown wrote:

> Afterward, I typed went back and retyped each command, followed by a
> plain "bcdedit", to make sure that the value of testsigning changed
> as I expected. It did. But what they were set to wasn't actually
> relevant, since I never rebooted.

bcdedit it modifying the command-line arguments used to load the boot
image, and why those arguments are not effective until the OS next gets
loaded (i.e., after a reboot).

I haven't tested, but I'm wondering if what "bcdedit" (no args) reflects
the current state of the loaded OS, or what will be the state when the
OS is next loaded. It's an editor showing you what are the arguments to
the command (well, fields in the records since BCD is a database) used
to load the OS. It's like editing the registry: while you can can
values, and you can see they changed in regedit.exe, they aren't
effected until the next load of the OS, and why some registry edits
require a reboot to effect the changes.

I thought msconfig.exe used to show the command-line used to load the
OS(es), but it doesn't after Microsoft switched from using boot.ini to
using a database (BCD = Boot Configuration Data). Looks like Vista was
when boot.ini got dropped to use BCD, and why bootcfg.exe errors with
"no boot.ini file found". Instead of looking inside a text file to see
the parameters on the command to load the OS, you need a database
inspector, like bcdedit.exe, EasyBCD, or Visual BCD Editor. I remember
using EasyBCD in the past, but it's not on my current Win10 setup.

I figure, like regedit.exe, bcdedit.exe is an editor, but what it shows
you is the configuration, not the current OS state. With changes in the
registry, and since the files for it get loaded into memory and the
registry API accesses the memory copy, changes to the memory copy might
be accessed by software, or a reboot (or sometimes just a logou and
login) are needed to load a fresh and changed copy of the registry into
memory. regedit.exe, or reg.exe, are editors that understand the
structure of the binary database called the registry. You see text for
hive, key, and value names, but the registry is not a text file, plus
regedit.exe won't show you all parts of the registry, even if you are
logged in as an administrator. Likewise, bcdedit could be just showing
what is configured in the BCD database, not what is currently in effect.

On Sun, 17 Apr 2022 17:25:20 -0500, VanguardLH wrote:
> Likewise, bcdedit could be just showing
> what is configured in the BCD database, not what is currently in effect.
>

For "could be" I would probably substitute "is". Why? Because my
edits to testsigning showed up immediately in bcdedit's display (from
"bcdedit" with no arguments) but "Test Mode" did not appear on my
desktop. From that I infer that taking Windows in and out of Test
Mode happens at boot time, as you imply.

But the big unanswered question on my mind is, the same scanner that
drivers that now work in non-"Test Mode" previously would function
only in "Test Mode". What can have changes?

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
Shikata ga nai...

Stan Brown wrote:

> VanguardLH wrote:
>
>> Likewise, bcdedit could be just showing what is configured in the BCD
>> database, not what is currently in effect.
>
> For "could be" I would probably substitute "is". Why? Because my
> edits to testsigning showed up immediately in bcdedit's display (from
> "bcdedit" with no arguments) but "Test Mode" did not appear on my
> desktop. From that I infer that taking Windows in and out of Test
> Mode happens at boot time, as you imply.
>
> But the big unanswered question on my mind is, the same scanner that
> drivers that now work in non-"Test Mode" previously would function
> only in "Test Mode". What can have changes?

Look at which driver(s) are specified in Device Manager for the scanner
device (imaging device). Maybe you switched from the Canon-supplied
driver to the Windows-embedded generic driver. See if you're now using
the WIA (Windows Imaging Acquisition) driver instead of the TWAIN
driver, or a TWAIN driver but from who? TWAIN is better for scanners
and WIA for acquiring images from cameras and video devices. Perhaps
you're now using a different driver than before. There is a TWAIN
compatibility layer allowing TWAIN-aware apps to access WIA devices.
Canon is clear as mud on whether their old LiDE 50/60 scanner were TWAIN
or WIA devices. As noted below, the last driver I found for the LiDE 50
said it was a TWAIN driver.

From what I see in the online manual for this LiDE 50, you don't have
apps directly access the scanner. Instead, in the apps' Acquire dialog,
you select ScanGear CS which is the driver (with UI). That is, as I
mentioned before, the program (ScanGear CS) is an application that
doesn't use a driver, and instead the program knows the command
interface to the device. You don't need a driver if you have the
program that knows the command set to interface with the device. That's
how VueScan works: they have a built-in "driver" (command set) that can
interface with the LiDE 50. Did Canon's "driver" installer offer to
install ScanGear?

I didn't see ScanGear listed at the Canon site for download for the LiDE
50. The 50 is considered a lesser variant or partner of the LiDE 80:
the LiDE 50 doesn't scan film, and color photo scanning is better with
the 80 (but quality still isn't great with grainy output and horizontal
banding).

At the Canon site, there is a v7.1.3.3.a TWAIN driver download for the
LiDE 50, but you have to select Windows XP. It's a TWAIN driver. Have
you tried it? For the larger LiDE 80 sibling, Canon has a download for
their v7.2.5.0a TWAIN driver which supports Windows 7, and might work
under Windows 10. No idea if either driver is signed to Window 10's
satisfaction. Windows 7 (actually back to Vista) had code signing, so
I'd try Canon's Win7 TWAIN driver.

By the way, "bcdedit.exe -set testsigning no" puts you into test mode on
the next load of the OS, and that typically nags you with the "Test
Mode" banner. I've read where you can disable the integrity checks
which also eliminates the "Test Mode" banner.

bcdedit /set nointegritychecks on

Warning: Cannot be turned on when Secure Boot is enabled in UEFI. From
a prior reply, you said "appear I don't have Secure Boot". That won't
be present unless you are using UEFI in your motherboard. Don't know
which mobo you have to check if it uses BIOS or UEFI, and, if UEFI, if
there is a Secure Boot option (for UEFI there should be the option).
There is a hazard if you enable Secure Boot, and then later disable it
(you may end up having to get a replacement mobo).

Ever putz around with nointegritychecks with bcdedit?

VanguardLH wrote:

> bcdedit.exe /set nointegritychecks off

Oops, that should've been on instead of off. I hate negative options
where you have to disable to enable.

On Sun, 17 Apr 2022 21:41:42 -0500, VanguardLH wrote:
>
> By the way, "bcdedit.exe -set testsigning no" puts you into test mode on
> the next load of the OS, and that typically nags you with the "Test
> Mode" banner. I've read where you can disable the integrity checks
> which also eliminates the "Test Mode" banner.
>
> bcdedit /set nointegritychecks on
>
> Ever putz around with nointegritychecks with bcdedit?

Yes, I had to do that to install the driver ion the first place. But
the driver _runs_ with nointegritychecks set to no (off).

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
Shikata ga nai...

> Stan Brown wrote:
> > But the big unanswered question on my mind is, the same scanner that
> > drivers that now work in non-"Test Mode" previously would function
> > only in "Test Mode". What can have changes?

On Sun, 17 Apr 2022 21:26:37 -0500, VanguardLH wrote:
> Look at which driver(s) are specified in Device Manager for the scanner
> device (imaging device). Maybe you switched from the Canon-supplied
> driver to the Windows-embedded generic driver. See if you're now using
> the WIA (Windows Imaging Acquisition) driver instead of the TWAIN
> driver, or a TWAIN driver but from who?

That was a good thought. (And thanks for trying to solve the
mystery.) As far as I can tell, I'm using a TWAIN driver from Canon.
The GUI has "ScanGear" (Canon's software name) in the title bar, and
as you'll see below, most of the driver files come from Canon. I
scanned a couple of documents, and this driver still works just fine
in regular non-"Test Mode".

I found that, where all (or most) of my other devices show up in
Devices and Printers and in Device Manager whether they're connected
or not, the scanner shows up in both places only after I connect it.

In Devices and Printers, it shows as "CanoScan". If I double-click
it, a popup says
"Scanner
"You need a WIA driver to use this device. Please install it from
the installation CD or manufacturer's website and try again."

If I right-click it and select Properties, the Hardware tab gives the
device name as "CanoScan LiDE 50". If I click the Properties button
on the Hardware tab of that dialog, I get almost the same four-tab
popup that I get if I right-click CanoScan LiDE 50 in Device Manager
and select Properties. I'll call the one from Devices and Printers
DAP and the one from Device Manager DM.

General tab:
Device type: Imaging devices
Manufacturer: Do Not Argue [!]
Location: Port_#0002.Hub_#0003
Device Status The device s working properly.
DAP Only: A "Change Properties" button with the Admin shield. When
click it I get the same dialog without the button.

Driver tab:
Driver Provider: Do Not Argue
Driver Date: 2009-04-20
Driver Version: 11.1.1.1
Driver Signer: not digitally signed
DM has buttons for Driver Details, Update Driver, Roll Back Driver
[greyed out], Disable Device, Uninstall Device.
DAP has the same, but all except Driver Detals are greyed out.

Driver Details (on either dialog's Driver tab) shows
C:\Windows\media\CSSAMP1.MID - Provider: unknown
C:\Windows\system32\CNQL1212.dll and CNQU111.DLL from CANON INC
C:\Windows\system32\drivers\ksthunk.sys and usbscan.sys from
Microsoft
C:\Windows\system3\spool\drivers\Color\CNS12Z.ICC and CNZ005.ICC from
Unknown
C:\Windows\twain_32\CNQL60 has numerous files, mostly from Canon but
a few with unknown provider (though signed by Microsoft Windows
Hardware Compatibility)

Details tab shows a drop-down list of properties and values. (And why
can't we get a two-column list instead of having to click every one,
one at a time?) None of them seemed particularly helpful to me,
though I might have missed something.

Events tab:
2022-03-20 3:47:51 PM Device install requested
2022-03-20 3:47:51 PM Driver service added (usbscan)
DM: The Information box says "Driver Management has concluded the
process to add Service usbscan for Device Instance ID USB\VID_04A9
&PID_2213\5&10DC9A0C&0&2 with the following status: 0"
(Clicking the View All Events button yields the same info in
different format.)
DAP: the Information box says "Device USB\VID_04A9&PID_2213\5&
10dc9a0c&0&2 requires further installation."

> At the Canon site, there is a v7.1.3.3.a TWAIN driver download for the
> LiDE 50, but you have to select Windows XP. It's a TWAIN driver. Have
> you tried it?

To be honest, I'm reluctant to unsinstall something that works so
that I can install something that ought to work. :-) Even if it does
work, I'm no better off than I am now; and if it doesn't, I'm worse
off.

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
Shikata ga nai...

Stan Brown wrote:

> To be honest, I'm reluctant to unsinstall something that works so
> that I can install something that ought to work. :-) Even if it does
> work, I'm no better off than I am now; and if it doesn't, I'm worse
> off.

That's why I save image backups. No matter what I do, install new or
different drivers, or install MS updates, I can escape back to the prior
image to undo all the changes.

On Mon, 11 Apr 2022 11:19:27 -0700, Stan Brown
<the_stan_brown@fastmail.fm> wrote:

>On Mon, 11 Apr 2022 12:53:24 +0100, J. P. Gilliver (John) wrote:
>> Ditto; I am still a 7 user, but support the odd 10-user (and some who
>> are not odd!).
>
>There's still a Windows 7 tips page, John:
>
><https://brownmath.com/general/7tip.htm>
>
>And a specialized one on curbing unneeded services in Windows 7:
>
><https://brownmath.com/general/7service.htm>

Anything similar for Win 10?