Batch Patcher 2.11

[Glenn9999]

I just found your program but am also unable to download it. I get a blank window and if I add the link to free Download Manager it says file not found on server?

http://www.msfn.org/board/batch-patcher-1-...54-page-21.html

Edited December 20, 2009 by Glenn9999

[Glenn9999]

Version 2.00 is released and can be found on the first post.  The main change is that it supports CAB files via pkgmgr and dism and MSU via wusa.  I tested it against Windows 8.1 and Windows XP.  Given I used the same code base for handling EXE, there shouldn't be any reason why it shouldn't support Windows ME as well.

Edited July 29, 2014 by Glenn9999

[Glenn9999]

Version 2.02 is released and can be found on the first post.

2.01 - changed patch listing routine so they would be listed in order from oldest date to newest date.  This should aid the proper installation of patches if it becomes an issue.

 

2.02 - I fixed it so it would work in patching my Windows 8.1 x64.   It worked, and hopefully it will still work in other things.  Please let me know if it doesn't, if you try it and run into problems.

[pcalvert]

When used on newer versions of Windows, such as Windows 7 and Windows 8, does Batch Patcher use DISM to install the updates?

 

Phil

 

[Glenn9999]

When used on newer versions of Windows, such as Windows 7 and Windows 8, does Batch Patcher use DISM to install the updates?

 

Phil

 

If it finds it, yes.

[Glenn9999]

I'm looking at doing 2.10, which is mainly a back-end change about how the patches are run.  One of the things that I could probably do on the program screen is show the outputs of the command-line programs that are called.  But I haven't determined the best way from a UI standpoint.   I'll have to see what I can make work, but would a "Details" tab or a button from the main screen that reveals this output be preferable?

[jaclaz]

What I find useful (which might or might not be what you want/need) is the making of a "tee" of the commands (and of their output if any) into a .log file, then the press of the button would simply open the .log, which could be a plain text file and as such usable through Notepad or any other text editor for copy/paste.

To further simplify it, the button could simply run Notepad.exe yyyymmddhhmmssBP.log. 

 

jaclaz

[Glenn9999]

What I find useful (which might or might not be what you want/need) is the making of a "tee" of the commands (and of their output if any) into a .log file, then the press of the button would simply open the .log, which could be a plain text file and as such usable through Notepad or any other text editor for copy/paste.

To further simplify it, the button could simply run Notepad.exe yyyymmddhhmmssBP.log. 

 

jaclaz

 

You'll have to elaborate on what you mean.  I think I'll probably scrap the "capture the output idea" I mentioned in #36 anyway, given what I saw with DISM when I did.  I don't think it really added anything that couldn't be figured out by the UI sitting on "Installing" for a particular thing.  That said, if it's what it sounds like, it might be worth redoing the logging system (it already logs to batpatcher.log in <WindowsDir>).  There's parts of it that I'm really not too thrilled about, and not sure that more data couldn't be pieced together, too.  Anyway, let me know what you think.

[jaclaz]

Personally I would have a /v (verbose switch) that logs *everything* (to be used only when needed) but normally the log would contain only the actual commands issued and whether they were successful or not, i.e. lines *like*:

2015/04/15 11:12:10 Command issued: C:\temp\fgrtys.exe -c C:\Windows\System32\whatever.ext

2015/04/15 11:12:12 Command result: Errorlevel 0

 

Some tools have two switches, where /v (verbose) increases the amount of output and only a further switch like /vv (very verbose) logs integrally ...

 

the "tee" program is a Unix originated tool that simply copies something that would go to the console (like it is "normal") to one (or more) files:

http://unixhelp.ed.ac.uk/CGI/man-cgi?tee

there are windows ports of it, a few ones:

http://unxutils.sourceforge.net/

https://code.google.com/p/wintee/

http://david.tribble.com/programs.html

 

 

jaclaz

[Glenn9999]

Definitely something to look at.  The plan was always for Batch Patcher to log things, but like I wrote above, it really bothers me that it was never too structured.  Then, error levels were something that kind of went by the wayside too (1.01 or 2) since the patches of the time were throwing some wonky error levels out even upon success.  Logging to window wouldn't be much harder than logging to file, so I'll have to see what can be done.

 

Tee looks like what you get in DOS when you use > or >>, which again seems defeating given what little real information that gets revealed by a DISM call:

 

C:\Windows\System32\DISM.exe /Online /Add-Package /PackagePath:"D:\BACKUP\BatchPatcher 2.10\windows8.1-kb3038314-x64.cab"

Deployment Image Servicing and Management tool
Version: 6.3.9600.17031

Image Version: 6.3.9600.17031

Processing 1 of 1 - Adding package Package_for_KB3038314~31bf3856ad364e35~amd64~
~6.3.1.3
[===========================99.8%========================= ]
The operation completed successfully.
 

 

 

Personally I would have a /v (verbose switch) that logs *everything* (to be used only when needed) but normally the log would contain only the actual commands issued and whether they were successful or not, i.e. lines *like*:

2015/04/15 11:12:10 Command issued: C:\temp\fgrtys.exe -c C:\Windows\System32\whatever.ext

2015/04/15 11:12:12 Command result: Errorlevel 0

 

Some tools have two switches, where /v (verbose) increases the amount of output and only a further switch like /vv (very verbose) logs integrally ...

 

the "tee" program is a Unix originated tool that simply copies something that would go to the console (like it is "normal") to one (or more) files:

[jaclaz]

BUT, specifically for DISM, and for DISM in servicing mode:

https://technet.microsoft.com/en-us/library/hh825079.aspx

you could use DISM's own LOG mechanisms (as opposed to logging the console output).

 

jaclaz

[Glenn9999]

BUT, specifically for DISM, and for DISM in servicing mode:

https://technet.microsoft.com/en-us/library/hh825079.aspx

you could use DISM's own LOG mechanisms (as opposed to logging the console output).

 

jaclaz

 

You mean the content that defaults to <WinDir>/Logs/DISM/dism.log as opposed to anything the console might produce ?

[jaclaz]

 

You mean the content that defaults to <WinDir>/Logs/DISM/dism.log as opposed to anything the console might produce ?

 

Yep ,  you can specify in your command line to which file (overruling the default setting for <WinDir>/Logs/DISM/dism.log) to direct the log message and also the level of verbosity 1/2/3/4...

 

jaclaz

[Glenn9999]

Yep ,  you can specify in your command line to which file (overruling the default setting for <WinDir>/Logs/DISM/dism.log) to direct the log message and also the level of verbosity 1/2/3/4...

 

 

 

 

I thought this was what you might have meant, but wasn't sure that there was much interesting in that log file, when I looked at it.

Edited April 16, 2015 by Glenn9999

[Glenn9999]

Got the logging rewrite done, it looks and acts a lot more sensibly given all the other changes that have happened since that part got written.

 

 

2015/04/19 02:11:30 ========================
2015/04/19 02:11:30 Batch Patcher Invocation on Windows Version 6.3
2015/04/19 02:11:33 Searching patches for: D:\BACKUP\BatchPatcher 2.10
2015/04/19 02:11:33 QCHAIN.EXE is not a valid patch.
2015/04/19 02:11:33 batpatcher.exe is not a valid patch.
2015/04/19 02:11:34 Command Issued: dism.exe /Online /Add-Package /PackagePath:"D:\BACKUP\BatchPatcher 2.10\windows8.1-kb3038314-x64.cab" /quiet /norestart
2015/04/19 02:11:58 Command Result: Errorlevel 0
2015/04/19 02:12:02 Batch Patcher Termination

 

I'm still not quite sure what jaclaz talks about would look like, but if anyone has any ideas on fixes, changes, improvements or whatever, feel free to suggest.