Microsoft Ceases AutoPatcher Project: future of RyanVM pack?

Questions about Update Pack making? Ask here.
PsiMoon314
Posts: 63
Joined: Wed Jan 19, 2005 12:55 pm
Location: Haverfordwest, Wales, UK

Post by PsiMoon314 » Sat Sep 01, 2007 10:15 am

Hi,

@GreenMachine
Geeez, I guess the Original XP CD Creation Utility has really gone under the radar lately. I did not continue with the automatic downloading of hotfixes as I had no desire to regularly update the download list, let alone provide all the localized version links. I felt like THe Little Green Hen.
My apologies, I was not aware that your tool would perform both the update of a CD image and also used for offline updating of an existing XP installation.

I will of course take a look at XPCREATE to see if it might be what I am looking for! :)

Kind Regards

Simon

GreenMachine
Posts: 4
Joined: Sat Jun 17, 2006 5:25 am

Post by GreenMachine » Sat Sep 01, 2007 12:46 pm

Actually, I misled you ... I was looking at the AND/OR part. XPCREATE updates a distribution CD only, and the downloading of hotfixes would depend on having a list of the hotfixes to download. I have not touched it for a while, and if I recall right, the automatic download part may have been removed due to too many takers, and not enough givers. But in it's heyday, XPCREATE did take an original XP install CD, and spit out an up-to-date CD, downloading all the updates itself. I still use it for my own installations, and I only have problems incorporating the IE7 updates, and .NET 3.

The main difference of the final product of XPCREATE, and Ryans Update Pack is that XPCREATE simply uses Microsoft's method of integrating hotfixes (before they introduced the /integrate switch), where as Ryan updated the source in a more "service pack" type of way. An XPCREATE CD DOES have all the binaries updated, but also runs the hotfixes for the registry and configuration changes. This results in a bigger installation source, and the dreaded loooooong pause with 13 minutes remaining during the installation phase.

However, by not including any hotfixes in the distribution, a two year old product still can do the job today, and has escaped the wrath of any copyright holders ...

So, perhaps my point was simply ... Been There Done That, as well as I Told You So regarding my design decisions to NOT include the hotfixes in the XPCREATE Distribution Package. Or perhaps I simply felt the need for some public whinning!

Greetz go out to the Master and Missus Ryan. Now if we could only make Patriots Fans out of them ...

User avatar
RogueSpear
Posts: 1155
Joined: Tue Nov 23, 2004 9:50 pm
Location: Buffalo, NY

Post by RogueSpear » Sat Sep 01, 2007 1:10 pm

I think that as a quick proof of concept a down and dirty VBscript could easily be whipped up to create an Update Pack. My initial concept is to have a master .ini file that would have a list of hotfixes with the download URL and some instructions. Then an .ini file for each hotfix itself that would essentially be the entries.ini components for just that one hotfix.

I'm not really fluent enough in hotfix methodology, but I can do VBscript and already have the .ini read/write routines written along with the downloading part. Obviously VBscript isn't exactly ideal but it's pretty quick to spit something out. Done properly the core script wouldn't need much updating, rather the .ini files would need updating as hotfixes are released.

If someone wants to lend their hotfix expertise, hit me up. Once the proof of concept is completed it should be trivial to get the functionality into VS.

User avatar
n7Epsilon
Moderator
Posts: 624
Joined: Thu Feb 17, 2005 1:37 am
Location: Cairo, Egypt

Post by n7Epsilon » Sat Sep 01, 2007 1:43 pm

Well building an update pack from scratch from just hotfixes will prove to be difficult...

Some hotfixes need special registry entries, generating the standard mundane INF data can be extracted from the update.INFs and generated in a similar fashion to code65536's perl script..., but some parts need human intervention, and this means hardcoding the extra needed entries...etc. in the program itself (similar to nLite)...

I was thinking of just someone releasing the entries.ini (retrofitted with urls to download) and the INF and the program just downloading the hotfixes, yanking the files out and putting them in one folder and building...

User avatar
RogueSpear
Posts: 1155
Joined: Tue Nov 23, 2004 9:50 pm
Location: Buffalo, NY

Post by RogueSpear » Sat Sep 01, 2007 2:04 pm

That was my intention... to human build the .inf sections for each hotfix. Surely it wouldn't be too offensive to Microsoft to distribute a text file with custom information in it.

The program/script would simply put everything together. It seems like this would be similar to how the Integrator currently works, only down one level deeper. Needing to take into account if someone tries to include two hotfixes where one supercedes another and other such conflicts.

User avatar
ricktendo64
Posts: 3213
Joined: Mon May 22, 2006 12:27 am
Location: Honduras

Post by ricktendo64 » Sat Sep 01, 2007 3:09 pm

How about doing what Siginet does with Office 2003 Integrator, using a online database with reg-entries and other stuff that can be updated regularly.

Make a INF file for each KB Hotfix out there and when the "Update Slipstreamer" detects the hotfix it looks online for the INF and its reg-entries for that specific KBxxxxxx file.

EDIT: Maybe also a list of files that is contained in the hotfix & location they needs to be extracted to and what files to edit (like sysoc, dosnet & txtsetup) can also be included in each KB database.

PsiMoon314
Posts: 63
Joined: Wed Jan 19, 2005 12:55 pm
Location: Haverfordwest, Wales, UK

Post by PsiMoon314 » Sat Sep 01, 2007 4:09 pm

Hi,

If it helps any then there is a project here:

http://www.heise-security.co.uk/articles/80682/3

called "Offline Updates" which downloads and parses WSUSSCAN.CAB and uses this to download hotfixes for offline installation. This covers Windows 2000, Windows XP and Windows 2003 in many languages.

It's close to what I would want but needs extending to all of the other items which AutoPatcher includes.

However using a Microsoft supplied file to locate all of the updated for direct download is rather clever! :)

The most interesting part is that this project is coded in AutoIT and .CMD files so it could be modified to do what is being discussed here.

The sources are there for anyone interested.

Once you have all of the hotfixes then they could be processed into a RVM type pack or into an Offline Updates solution similar to AP.

Kind Regards

Simon

User avatar
code65536
Posts: 735
Joined: Wed Mar 14, 2007 2:58 pm
Location: .us
Contact:

Post by code65536 » Sat Sep 01, 2007 8:58 pm

Well, before we all jump the gun here, I want to point out that we don't really know if all this would be necessary. First, we don't know if AP is really going to be down, because we don't know if Microsoft really intended to take down AP (or if that was just its hired gun being overzealous; see my post above, in which case, they may reverse this "decision"), and even if they did intend to take it down, we don't know if the current backlash and press coverage will force them to reverse that decision. If AP is saved, then there's a good chance that the whole thing's blown over. And even if AP isn't saved, we don't know if Microsoft will ever target this project. So there's a lot of unknowns out there.

I think that this question of necessity is important and makes a difference. I had been thinking about expanding on my current Perl script to make it automate more of the pack-building process (whether or not I will actually do this would depend on how much longer Ryan will remain away and thus how much longer I'll be maintaining my addon). But even then, there's still a big gap between "tool to help me" and "something to distribute to the masses". The latter has to be more error-tolerant, more user-friendly, etc. Most importantly, you must make sure that it works under all cases and scenarios instead of just the vast majority of cases, because the end-user can't go in and manually error-check and adjust things as necessary. It's a lot of effort and work to add in all that extra stuff to make it suitable for the end-user, but for us (i.e., not the end-users), all this effort brings in very little benefit (because of rapidly diminishing marginal returns the further we travel down the path of automation), and if that extra work isn't needed, then it might as well be avoided.

Another problem is that Ryan's pack includes a lot of non-public hotfixes (and it's these hotfixes and the use of QFE that really make the pack more like a quasi-SP3 than just SP2 with security patches)... and there isn't really a good way around that problem...

PS: Doesn't nLite already do hotfix integration? (Do they do it via the "stupid" svcpack method or the "smart" true integration method? I've never tried, and I'm busy this weekend, so I won't get around to trying for a few days...)
My addons: CmdOpen - HashCheck - Notepad2 - MS Runtimes - DirectX

Into the breach, meatbags!

yumeyao
Moderator
Posts: 1718
Joined: Sun Aug 27, 2006 9:24 pm
Location: Taiyuan, Shanxi, PR China

Post by yumeyao » Sat Sep 01, 2007 9:50 pm

RogueSpear wrote:That was my intention... to human build the .inf sections for each hotfix. Surely it wouldn't be too offensive to Microsoft to distribute a text file with custom information in it.

The program/script would simply put everything together. It seems like this would be similar to how the Integrator currently works, only down one level deeper. Needing to take into account if someone tries to include two hotfixes where one supercedes another and other such conflicts.
Hi. consider that entries for different languages will not look the same.

that means, all files' buildchecksums timestamps versions locactions and filenames CAN be readed by the original KBxxxxxx.exe.
for timestamp, we can use code2^16's way. and... we just use the original timestamp(the GMT one..), then at T-13 let codec2^16's utility do its work.
we can build this part of registry entries and other common entries in this way.

for other entries, we should use let updatepack builders submit the entries for their own languages.

and well, we should also allow for any exception.
for instance, M$'s mmc 3.0 hotfix uses zh-chs for simplified chinese resources, however the correct code for china should be zh-cn(and later releases use this one...). so i've hacked it to zh-cn. No problem.

then, notice this
[txtsetup_dirs]
241 = system32\PreInstall\WinSE\wxp_x86_0804_v1
242 = SoftwareDistribution\DataStore
244 = "Network Diagnostic"
245 = system32\Macromed\Flash
246 = system32\zh-cn
247 = l2schemas
we should indicate folder serials for fixed ones, otherwise if two packs set a same serial for different folders, things will happen. (that is why booooooggy change his wmp11 pack to intergrator... i think....)

by last, i hope that this project will come ture.
this also can offer a benifit that allows users to choose hotfixes they want(well... for example some unoffical hotfixes only avaliable in sepific languages)
Image
My work list(Hosted by dumpydooby)

yumeyao
Moderator
Posts: 1718
Joined: Sun Aug 27, 2006 9:24 pm
Location: Taiyuan, Shanxi, PR China

Post by yumeyao » Sat Sep 01, 2007 9:53 pm

code65536 wrote:PS: Doesn't nLite already do hotfix integration? (Do they do it via the "stupid" svcpack method or the "smart" true integration method? I've never tried, and I'm busy this weekend, so I won't get around to trying for a few days...)
smart true integration with a little stupid registry entries....
nlite didn't have set specific entries for all hotfixes(however, for some..)
Image
My work list(Hosted by dumpydooby)

Xable
Posts: 981
Joined: Tue May 03, 2005 6:38 pm
Contact:

Post by Xable » Sat Sep 01, 2007 11:06 pm

I don`t think people acting on behalf of microsoft could ever be done mistakenly, so whatever action has been taken is final as long as microsoft don`t change their minds on the matter, which won`t happen because they`ve long made their minds up and changing now would make them look look even more stupid than they already do.

I also think a guide to educate the masses on how to build update packs would be a good way to go (more so than tools which do it for you, as good as they may be for the noob in this area) what`s stopped me doing this up to now, is the fact that it`s not a simple or straight forward task and it`s not even needed (untill now, or whenever the point comes when update packs are banned by microsoft! wtf.) seen as their are other pack makers out there including ryan and myself not to mention anyone who has a bit of drive and/or guidence.

My point is, instead of writing tools which will blindly get the job done, enevitably causing inconsistencies or errors, it would be better to focus energys into educating people as to how the process is done.

This will allow everyone, regardless of preference and language to slipstream exactly what they choose accross language, error free.. HEAVEN!!

User avatar
Siginet
Site Admin
Posts: 2894
Joined: Fri May 27, 2005 1:07 pm
Location: Planet Earth
Contact:

Post by Siginet » Sun Sep 02, 2007 12:58 am

ricktendo64 wrote:How about doing what Siginet does with Office 2003 Integrator, using a online database with reg-entries and other stuff that can be updated regularly.

Make a INF file for each KB Hotfix out there and when the "Update Slipstreamer" detects the hotfix it looks online for the INF and its reg-entries for that specific KBxxxxxx file.

EDIT: Maybe also a list of files that is contained in the hotfix & location they needs to be extracted to and what files to edit (like sysoc, dosnet & txtsetup) can also be included in each KB database.
Actually the RVM Integrator is what I had in mind when I decided to learn how to use an online database. Instead of testing my ideas on the RVM Integrator I decided to test it on a new project, and The Office Integrator was the perfect candidate. The Office Integrator has proven to work very well... actually much better than I had originally imagined. It is still very much in it's beta stages and it has a lot of changes that I need to add to it but it does work for the most part. It was kind of fun to code because I was learning something new.

I think n7epsilon is on the right track as to what we should do. We should have an entries file and an inf file or a new type of file that builds the ini and inf file. It should also have urls in it to auto download the needed hotfixes and extract them into a full updatepack. rickentendo's idea of having an online database for each hotfix is a great idea as well.

I can create all of this. But my time is sometimes limited since I have piled so many applications under my belt and am trying to run 2 businesses as well. So... I really would like to put together a team to help me code the 2.0 version of the integrator. I have so many ideas for 2.0. I'd like to have a built in bittorrent system for help in sharing addons with eachother. So it would read an online database to let users know of updates to addons and so on. I allready have permission from dreamhost for this. johnathantneal has mentioned he can try to make a custom torrent tracking system for the project as well.

For a team of coders they would mainly have to be very skilled in autoit. Also I have jerjen for php and mysql. HJW would be great as a graphics designer. muiz and a few others have shown me some work they have allready done for vista integrations and it is superb! But for everything to happen as it is in my head... I need help. n7epsilon would be great at creating tools that can be used in the integrator as well.
Image
--Siginet--

Techware
Your Virtual Technician
Computer Management Software

User avatar
code65536
Posts: 735
Joined: Wed Mar 14, 2007 2:58 pm
Location: .us
Contact:

Post by code65536 » Sun Sep 02, 2007 7:14 am

My point is, instead of writing tools which will blindly get the job done, enevitably causing inconsistencies or errors
Yes, that's the problem with writing tools. Because in order for them to be able to blindly get the job done, it takes a lot of work. They make sense in assisting in pack creation by automating some of the mundane repetitive things, but beyond that, their marginal usefulness declines while the effort needed to implement them increases dramatically... which is why I think it may be best to hold off on writing such a tool unless it becomes necessary.
it would be better to focus energys into educating people as to how the process is done. This will allow everyone, regardless of preference and language to slipstream exactly what they choose accross language, error free.. HEAVEN!!
*chuckles* You're so naive. ;) I think that the educational resources already exist: the existing update packs (or better, a diff of two consecutive versions of an update pack) and a brief look at what happens during a SP slipstream (I mean, it's not magic; anyone could build a pack!). I had never made an addon or even twiddled with an entries.ini until my update addon, and it really didn't take long to just learn from example. The problem isn't teaching people how it's done (include files, include any necessary INF entries, write into the INI any changes for dosnet.inf or txtsetup.sif), because that's a quick lesson that can be taught by just pointing them to an example. The difficulty is in the need to adapt to the various scenarios that they are going to run across (should I register this DLL? what INF entries do I need for this? which parts of Microsoft's update INF can be safely ignored? etc.). If there wasn't a need to adapt to different scenarios, then writing a tool to blindly do all this would be easy, and so would educating people with a step-by-step how-to guide. Adaptation, unfortunately, is not something that can be easily taught with a guide. And people who have the initiative and wherewithal to adapt are also people who probably don't need a guide to walk them through what could be taught be example. Unfortunately (and this is where my comment about naivety comes it), have you noticed the number of people who post questions without even bothering to read the posts above them, the stickies, or the FAQ? Perhaps I'm just too cynical, but that gives me doubt about how an "educate everyone" effort would work. It won't hurt to try, of course, and I'd be happy to pitch in with any guide-writing effort; I'm just not sure how it'll be received.
My addons: CmdOpen - HashCheck - Notepad2 - MS Runtimes - DirectX

Into the breach, meatbags!

Xable
Posts: 981
Joined: Tue May 03, 2005 6:38 pm
Contact:

Post by Xable » Sun Sep 02, 2007 9:26 am

naive? no no, but your cynasism does have some grounds. There are always people who won`t read. ;)

A guide (when I say guide I mean just that, not a step by step tutorial) would definatly be helpful, more so for some depending on the type of person.

The trickey part is firstly knowing where to start and secondly, knowing all the details that you can`t learn by learning how to make packs. If you see what I mean :) That`s where a juicy guide comes in.

User avatar
RyanVM
Site Admin
Posts: 5189
Joined: Tue Nov 23, 2004 6:03 pm
Location: Pennsylvania
Contact:

Post by RyanVM » Sun Sep 02, 2007 11:31 am

GreenMachine wrote:Now if we could only make Patriots Fans out of them ...
Hey, Tom Brady's a good Michigan man ;)
Get up to $200 off on hosting from the same people who host this website!
http://www.ryanvm.net/forum/viewtopic.php?t=2357

PsiMoon314
Posts: 63
Joined: Wed Jan 19, 2005 12:55 pm
Location: Haverfordwest, Wales, UK

Post by PsiMoon314 » Sun Sep 02, 2007 12:32 pm

Hi,

This is interesting, here is a new release from MS called Microsoft Office Hotfix Installer which is described thusly:
... a software program designed to help administrators deploy update files within their organizations. OHotFix works by reading a series of deployment instructions contained in an INI file, and then using those instructions to apply an update to the computer. OHotFix can also check applications on the computer to determine which updates need to be applied, and it can order a group of update files so that an installation is optimized.
Umm ... this sounds like another program I have seen but I can't quite remember what it's called ... ;-)

Kind Regards

Simon

User avatar
code65536
Posts: 735
Joined: Wed Mar 14, 2007 2:58 pm
Location: .us
Contact:

Post by code65536 » Sun Sep 02, 2007 12:40 pm

Ah yes, I remember seeing that a few days ago. I guess it's the office division's attempt at the platform division's WSUS.
My addons: CmdOpen - HashCheck - Notepad2 - MS Runtimes - DirectX

Into the breach, meatbags!

GreenMachine
Posts: 4
Joined: Sat Jun 17, 2006 5:25 am

Post by GreenMachine » Sun Sep 02, 2007 1:50 pm

RyanVM wrote:Hey, Tom Brady's a good Michigan man ;)
Did someone say Michigan? ... OK OK, I won't rub it in ...

OHotFix has been the engine inside of Office Hotfixes for a number of years. Unpack an Office Hotfix, and you will see it.

User avatar
Siginet
Site Admin
Posts: 2894
Joined: Fri May 27, 2005 1:07 pm
Location: Planet Earth
Contact:

Post by Siginet » Sun Sep 02, 2007 3:16 pm

It is nothing like my OIntegrator if that's what you meant. Allthough their interpretation of what it does sounds simular.
PsiMoon314 wrote:Hi,

This is interesting, here is a new release from MS called Microsoft Office Hotfix Installer which is described thusly:
... a software program designed to help administrators deploy update files within their organizations. OHotFix works by reading a series of deployment instructions contained in an INI file, and then using those instructions to apply an update to the computer. OHotFix can also check applications on the computer to determine which updates need to be applied, and it can order a group of update files so that an installation is optimized.
Umm ... this sounds like another program I have seen but I can't quite remember what it's called ... ;-)

Kind Regards

Simon
Image
--Siginet--

Techware
Your Virtual Technician
Computer Management Software

User avatar
mr_smartepants
Posts: 824
Joined: Thu May 18, 2006 5:56 am
Location: Cambridgeshire, UK

Post by mr_smartepants » Sun Sep 02, 2007 3:43 pm

code65536 wrote:I think that the educational resources already exist: ... The problem isn't teaching people how it's done, because that's a quick lesson that can be taught by just pointing them to an example.
Damn, I'm learning just by being a fly-on-the-wall around here! :)

Eiffel
Posts: 73
Joined: Fri Nov 03, 2006 3:36 am

Post by Eiffel » Wed Sep 05, 2007 9:10 am

Seems that the last informations seems that AutoPatcher will come back: http://www.tcmagazine.com/comments.php?id=15919&catid=6

OffTopic: Ryan what about new packs ? Still busy with the Master ?

blackhawk_996
Posts: 2
Joined: Sat Sep 08, 2007 12:06 am

Post by blackhawk_996 » Sun Sep 09, 2007 6:34 pm

Funny part about this whole ordeal is the autopatcher project was brought back into light to M$ by one of their own forum members. They were trying to find the legality of hosting the update pack on another ISP's local server oversea's so the download bandwidth didn't count against them for their monthly limit.

I guess they found the answer they were after :(

ChiefZeke
Posts: 767
Joined: Fri Mar 23, 2007 5:33 pm
Location: Victorville, California

Post by ChiefZeke » Thu Sep 13, 2007 11:44 pm

Go here: http://www.autopatcher.com/137 and read what the folks at AutoPatcher are saying.

Seems they are still trying to do their thing and updates of some kind could be oout in October.

finallyfree
Posts: 1
Joined: Wed Oct 24, 2007 11:55 am

What about pulling files from a WSUS server

Post by finallyfree » Fri Nov 02, 2007 1:47 pm

If M$ leaves WSUS (windows server update service) intact, what about pulling files from a WSUS server? One of the options in WSUS is to save the files locally. The files are saved in .cab and .exe files of which the .exe are just self extracting .cab files. I'm new enough at this that I'm not sure what it would take to pull files from a WSUS server and integrate them into an update pack, but it seems like it could be done.

The files look like this: 40084EB64738E8704208A23ECF802F8C8BB8F12B.Cab, B38BBC98DE887A64D0695F410B035130D43DDE2B.exe

Once the .cab files are extracted you can see the KBXXXXXX files.

ChiefZeke
Posts: 767
Joined: Fri Mar 23, 2007 5:33 pm
Location: Victorville, California

Post by ChiefZeke » Sun Nov 11, 2007 12:41 am

The AutoPatcher folks have returned: http://www.autopatcher.com/forums/

Post Reply