Kerr Mudd-John wrote:

VanguardLH wrote:

I enable the BITS and WU services only after I have prepared to do
Windows updating: gotten some time reserved, made a full backup image,
poll for the available update and wait ... and wait ... and wait, review
*EACH* update before allowing it (hiding the unwanted or nonapplicable
ones), reboot even if not told to do so, and disable the BITS and WU
services. When those services are disabled, there is no Windows
updating going on, not even to poll for new ones.

[This is for XP]

Here's my wupdate.bat (I have the services off most of the time)

@echo off
sc config msiserver start= demand
...
visit WU site
...
net stop msiserver
sc config msiserver start= disabled
...

MSI (Microsoft Installer) is used by most programs that install into
Windows. I only addressed disabling the *Windows updates* services
until I was prepared (time, backup, research, select, install). I would
NOT suggest disabling the Windows Installer service because that means
you cannot install most programs.

Windows Installer service:
"Adds, modifies, and removes applications provided as a Windows
Installer (*.msi) package. If this service is disabled, any services
that explicitly depend on it will fail to start."

Windows Installer
https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx

Just because I want to install new software or an update to it does NOT
mean that I want to enable Windows Updates (BITS and WU) to do that
software install. Just because I am blocking Windows updates does NOT
mean that I want to block software installs.

In message , Micky
writes:
[]
And the last planned stage is to improve how FFox saves tabs. Right
now, if theres' a crash or even if I close Windows normally, when I
restart, the Restore Session tab will likely be hours old (older than
the time Windows closed) not including tabs created later and
including ones already deleted. Even though the interval time
between saving sessionstore is set at 5 minutes or less.

The suggestions seem to be add-ons, either Session Manager or Tab Mix
Plus. Do you know if either can make the problem worse? They both
have millions of downloads, and the first has a 4.6 star rating over
456 reviews, and the second 4+ stars over 2600 reviews.

I have TMP, and can't say I've noticed Firefox's tab set being out as
you describe - though (a) I don't change the set of tabs I have open
_much_, and (b) I use FF 26, so the problem may not be relevant.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

I am the person for whom 'one size fits all' never fits. - Chris McMillan in
UMRA, 2011-11-12

[Default] On Sun, 10 Apr 2016 22:49:39 +0100, in
microsoft.public.windowsxp.general "J. P. Gilliver (John)"
wrote:

In message , Micky
writes:
[]
And the last planned stage is to improve how FFox saves tabs. Right
now, if theres' a crash or even if I close Windows normally, when I
restart, the Restore Session tab will likely be hours old (older than
the time Windows closed) not including tabs created later and
including ones already deleted. Even though the interval time
between saving sessionstore is set at 5 minutes or less.

The suggestions seem to be add-ons, either Session Manager or Tab Mix
Plus. Do you know if either can make the problem worse? They both
have millions of downloads, and the first has a 4.6 star rating over
456 reviews, and the second 4+ stars over 2600 reviews.

I have TMP, and can't say I've noticed Firefox's tab set being out as
you describe - though (a) I don't change the set of tabs I have open

I change mine all the time.

_much_, and (b) I use FF 26, so the problem may not be relevant.

I think it still would be. Except you have TMP.

I thought this was a problem that needed solving eventually, but
yesterday I enlarged a HDD partition, and it required rebooting to
take effect. I used Search Everywhere to find sessionstore.* (I
think that's part of the name of where the tabs are stored.) There
was more than one but the newest one was 28 hours hold. Huh ????, it's
supposed to be no more than 5 minutes old or since the most recent tab
change, whichever is older.

And I'm tired of losing my tabs, so I decided I had to install
something right then. It seems both Session Manager and TMP do some
of the same things, but SM emphasized saving tabs and windows, and for
TMP it was 3rd or 4th, after creating duplicate tabs (with both Backs
and Forwards) and one or two other things.

So I installed Session Manager and restarted windows, and it seems to
have saved everything, and nothing extra. To the best of my memory.

Also both SM and TMP said they were compatible, and SM said the
session saving part of TMP had to be disabled if used together, and
one of them said this happened automatically if SM was there when TMP
was installed. So I can add TMP later if I want.

One thing very good about SM is that it allows me to delete items from
the Recently Closed Window list. FF puts a limit on that, and the
default is 3!!!, but it can be raised to at least 25, but 6 years ago
it only counted "real" windows as windows, but I guess that left out
some windows people wanted to restore, so now it counts *everything*,
evan an enlarged item for sale in amazon or Ebay. And that eats up
the quota of 25 pretty quickly, especially if I'm not paying
attention. And no one on the FF list answered when I asked how to
delete items.

SM made it very easy, with right-click/delete.

It also makes the max limit a lot more obvious. IIRC it's in the
Options window, but FF requires one to know about about:config and to
know there is a setting, and more or less the setting name. (They all
have sessionstore in them, so if you know that you can find it.)

[Default] On Sun, 10 Apr 2016 16:11:26 +0100, in
microsoft.public.windowsxp.general "J. P. Gilliver (John)"
wrote:

In message . me.uk,
Rodney Pont writes:
On Sat, 09 Apr 2016 22:14:34 -0400, Micky wrote:

And I made them bat files and I tried them and.....

wu-disable went by so fast I couldn't read all of it.

Instead of ending in exit, I thought there was a command that would
end a bat file without closing the cmd box. I thought it was Return,
but that didn't work.

You can use pause to make it wait until you press return and you can
even add a comment ie;

pause Press Return to continue

Good idea, and I did that, but of course after I pressed a key to get
past the Pause, the window, which I started separately, unrelated to
entering the wu-enable or wu-disable, closed. I wanted it to sya

Or, you can run them from a command window you've opened, rather than
running them directly.

I did that. I always do that. But the next day the window didn't
close. Oh well.

[Default] On Sun, 10 Apr 2016 00:22:45 -0500, in
microsoft.public.windowsxp.general VanguardLH wrote:

Micky wrote:

And I made them bat files and I tried them and.....

wu-disable went by so fast I couldn't read all of it.

They are batch files. They run in a console windows (aka command
shell). Unless you first open a console windows (cmd.exe) to run them
there, the console window will close as soon as the batch file
completes. You don't know how to run console (DOS mode) commands?

Besides, there is really not much to show. It may show whether the
command succeeded or failed but you can see that by looking in
services.msc (or make sure to refresh its display if you have it open at
the time you change service state).

Instead of ending in exit, I thought there was a command that would
end a bat file without closing the cmd box. I thought it was Return,
but that didn't work.

I dug out some old bat files and looked at them and
Return /b
is what I had in mind. I know it kept the CMD window open with bat
files I used last summer. I wanted the window to stay open because I
wasn't done yet.

However yesterday, when I opened a window and ran WU-disable, the
window closed, but today it stayed open, even without return /b. I
don't know what changed.

It's working now and I don't want to spend more time on this problem.
Thanks.

More below.

That would require opening the console window (cmd.exe), telling it to
run the batch file but not close the console window afterward.
Basically you are independently opening the console window so what you
run inside doesn't close that window. DOS-mode commands may open a
console window but may not. If you rely on the console command to show
a window, it will get unloaded as soon as it is no longer needed, like
when the console command finishes.

You could:
- Run cmd.exe to load a console window. That console window is owned by
the cmd.exe process, not by any programs started within that console.
- Run wu-enable.bat or wu-disable.bat.
- Since the console window remains open - until you exit cmd.exe - you
can see any stdout produced by any non-GUI (DOS-mode) programs you run
inside that console.
- To exit the console (close the window) means you have to enter the
'exit' command (tells cmd.exe to unload) or you use the titlebar icons
or control menu to close the window (which will kill the cmd.exe
process).

Or you could just double-click on the shortcut to the wu-enable.bat or
wu-disable.bat files, let the console window flicker by (opened for the
shell to run the batch file and then immediately closed when the batch

I might be ready to do that after I'm used to running the bat file,
but I wanted to watch line by line at least the first couple times.
For example there were messages that BITS could not be stopped because
it wasn't running. I had to think abou that a bit and I learned
something.

file ends) and run services.msc to see what happened to the state of the
BITS and WU services. I prefer this method to verify what happened
rather than relying on the stdout from the console commands (sc.exe)
which will only report a failure not what is the resultant state of the
services.

On Sun, 10 Apr 2016 21:23:59 +0100, VanguardLH wrote:

Kerr Mudd-John wrote:

VanguardLH wrote:

I enable the BITS and WU services only after I have prepared to do
Windows updating: gotten some time reserved, made a full backup image,
poll for the available update and wait ... and wait ... and wait,
review
*EACH* update before allowing it (hiding the unwanted or nonapplicable
ones), reboot even if not told to do so, and disable the BITS and WU
services. When those services are disabled, there is no Windows
updating going on, not even to poll for new ones.

[This is for XP]

Here's my wupdate.bat (I have the services off most of the time)

@echo off
sc config msiserver start= demand
...
visit WU site
...
net stop msiserver
sc config msiserver start= disabled
...

MSI (Microsoft Installer) is used by most programs that install into
Windows. I only addressed disabling the *Windows updates* services
until I was prepared (time, backup, research, select, install). I would
NOT suggest disabling the Windows Installer service because that means
you cannot install most programs.

Windows Installer service:
"Adds, modifies, and removes applications provided as a Windows
Installer (*.msi) package. If this service is disabled, any services
that explicitly depend on it will fail to start."

Windows Installer
https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx

Just because I want to install new software or an update to it does NOT
mean that I want to enable Windows Updates (BITS and WU) to do that
software install. Just because I am blocking Windows updates does NOT
mean that I want to block software installs.

MSIexec also checks for updates when run. If I want to install something I
disable the internet then enable MSIserver , do the install then disable
afterwards. As I said I have services off if I don't need/want them.

--
Bah, and indeed, Humbug

Micky wrote:

I dug out some old bat files and looked at them and
Return /b
is what I had in mind. I know it kept the CMD window open with bat
files I used last summer. I wanted the window to stay open because I
wasn't done yet.

I have never heard of "return" and that's going back to Win3.1x days.
It is probably some software you installed. It is not an internal
command within cmd.exe nor is it a program supplied with Windows.

Just put pause at the end of the .bat file as Rodney already suggested.
pause just outputs "Press any key to continue ..." If you want
something more descriptive, use echo following by pause (with the output
of pause hidden), as in:

echo whateverPromptYouWantToSee
pause nul

I added the exit command at the end because I suggested to reference the
..bat files via shortcut, and leaving the console window open could be a
nuisance. If you open a console (cmd.exe) which opens a console window
and want that window to stay open after running the .bat files inside of
it, remove the exit command.

Because the .bat files call the sc.exe (service controller) program to
alter the state of NT services, you need to either configure the
shortcuts (that run the .bat files) to run under admin mode (or allow
the .bat file to commit its actions when the UAC prompt appears) or load
a console (cmd.exe) that runs in admin mode. If you run the .bat files
inside a console without admin privileges, you see a bunch of errors.
By using shortcuts to the .bat files, I get the UAC prompt and allow the
batch file to run.

What did you expect to see from the output of the batch files? That
output will not verify that services have actually stopped and were
disabled. All you get is succeed and fail statuses. For example, if
you run wu-disable.bat twice, the 2nd is guaranteed to show errors but
that's because you're trying to disable services that have already been
disabled. That the command succeeded doesn't mean the service actually
changed state as planned. The sc.exe command issues requests. Those
requests succeed or fail. There is no waiting around to find out if the
services actually did change states. The command is asynchronous. You
would have to wait for awhile to wait for the services to actually stop
before you later test for success.

Unless I add "sc.exe query BITS" and "sc.exe query wuausrv" to the end
of the batch file, you won't find the stdout from the .bat file to be
very useful. Besides, that would only show the services are stopped,
not that they are disabled. I would have to add:

after stopping and disabling BITS, or after enabling BITS:
sleep
sc.exe query BITS
sc.exe qc BITS
after stopping and disabling wuausrv, or after enabling wuausrv:
sleep
sc.exe query wuausrv
sc.exe qc wuausrv

where sleep uses the timeout command (internal to cmd.exe) or the
old "ping -w timeout localhost" trick.

Then you could see both the current state of the services and that they
were disabled - but they may have not changed yet even after the sleep
period. Services can change state very fast or very slow. So you can
either sleep a very long time and then check service state or use a
for-loop to keep polling for change (and parse the output to detect
state) with a shorter sleep where the for-loop exits immediately when
the state changes to the specified state (or eventually errors after a
max loop count figuring the service is not responding). I wasn't going
to that extravagance of scripting for simple stop and disable/enable
directives. That would also make the user sit around watching the
stdout in the console to determine (if they understood the output)
whether the sc.exe command worked or not.

That is a lot of output to look at just to verify that the .bat files
did indeed disable/enable the services. I have yet for these simple
batch files to fail doing what they're told to do -- unless you make the
mistake of not running them under admin privileges. With shortcuts to
the .bat files, I get a UAC prompt that ensures they run with admin
privileges. If I run them inside a console (cmd.exe) with its window
left open, it becomes apparent from the errors that I did not load
cmd.exe with admin privileges; however, the output is no value to me so
I never run them that way.

Yes, during testing, you could run cmd.exe -- with admin privileges --
to see the output of the sc.exe command. However, since your batch
script skills are weak (didn't know to remove 'exit' to watch without
closing the shell, didn't know why the console window disappeared when
using Start - Run, didn't know about adding a pause, didn't know sc.exe
issues asynchronous requests), I doubt you would understand the output
of sc.exe, anyway, or want to get into scripting that employs a fixed
sleep or a for-loop and variable parsing to wait until the service
states actually changed. By the time you click on the shortcut to
wu-disable.bat and then click on the shortcut to run Windows Update, the
services should've already been enabled and ready. If not, the WU
client will tell you it can't run. After WU is done, you don't care how
long it takes for the services to stop and get disabled.

I could add more logic into the script to ensure a service was actually
stopped before I disabled it, or to ensure a service got enabled before
starting it or changing its startup state but, so far, haven't need that
extra logic to accomodate that sc.exe issue asynchronous requests (sc
asks for a change, sc exits, change happens later whether fast or slow).

Kerr Mudd-John wrote:

MSIexec also checks for updates when run. If I want to install something I
disable the internet then enable MSIserver , do the install then disable
afterwards. As I said I have services off if I don't need/want them.

I know about the /p switch to *apply* an update package (for example,
"msiexec.exe /p pkg.msi"), not to retrieve an update package (the .msi
file). I have never heard that MSIexec can connect to and use WSUS
(Windows Server Update Services). Applying an update is not the same as
retrieving it. Do you have supportive evidence that it can retrieve
(download) an update package?

https://technet.microsoft.com/en-us/...=ws.10%29.aspx
http://www.advancedinstaller.com/use...e/msiexec.html

Yes, an installer can go check for updates. That is not MSIexec
connecting to a server to figure out where to find a file and determine
versioning. That is code the programmer added to the installer program.
It would check for updates to the software you CHOSE to install.
Nothing to do with Windows updating.

http://www.advancedinstaller.com/upd...reen-shot.html
http://www.advancedinstaller.com/use...date-page.html

On Mon, 11 Apr 2016 22:42:11 +0100, VanguardLH wrote:

Kerr Mudd-John wrote:

MSIexec also checks for updates when run. If I want to install
something I
disable the internet then enable MSIserver , do the install then disable
afterwards. As I said I have services off if I don't need/want them.

I know about the /p switch to *apply* an update package (for example,
"msiexec.exe /p pkg.msi"), not to retrieve an update package (the .msi
file). I have never heard that MSIexec can connect to and use WSUS
(Windows Server Update Services). Applying an update is not the same as
retrieving it. Do you have supportive evidence that it can retrieve
(download) an update package?

I recall a message to the effect that a newer version was available; back
when 3.0 superceded 2.0.
I'm posting from the XP NG.


https://technet.microsoft.com/en-us/...=ws.10%29.aspx
http://www.advancedinstaller.com/use...e/msiexec.html

Yes, an installer can go check for updates. That is not MSIexec
connecting to a server to figure out where to find a file and determine
versioning. That is code the programmer added to the installer program.
It would check for updates to the software you CHOSE to install.
Nothing to do with Windows updating.

http://www.advancedinstaller.com/upd...reen-shot.html
http://www.advancedinstaller.com/use...date-page.html


--
Bah, and indeed, Humbug

Kerr Mudd-John wrote:

VanguardLH wrote:

Kerr Mudd-John wrote:

MSIexec also checks for updates when run. If I want to install
something I disable the internet then enable MSIserver , do the
install then disable afterwards. As I said I have services off if I
don't need/want them.

I know about the /p switch to *apply* an update package (for example,
"msiexec.exe /p pkg.msi"), not to retrieve an update package (the
.msi file). I have never heard that MSIexec can connect to and use
WSUS (Windows Server Update Services). Applying an update is not
the same as retrieving it. Do you have supportive evidence that it
can retrieve (download) an update package?

I recall a message to the effect that a newer version was available;
back when 3.0 superceded 2.0. I'm posting from the XP NG.

I remember that, too. When you performed a Windows Update check, it
found there was a newer version of msiexec.exe and offered as an update,
just like it would offer you updates on other Windows components. You
chose to download and install it but it was still part of the WU check.

Even the WU client will check if there is a later version of itself. At
one point in the past, your choice was to update the WU client or you
could not proceed with further updating. To get the other updates meant
downloading and installing the offered WU client update. You could
still say No but then you couldn't get past the WU client notifying you
there was a later version of itself in subsequent update checks.