submix8c

@-X- ricktendo64 already installed the latest and it's checking for what it already has (apparently). Also, the "softwaredistribution" folder you see (above post, whichever one) was to get the 3 "missing" CABS, which ARE in the v226 package, but NEWER (with a different "generated" name)... Compare contents of v226 with v243 - same files, different contents(newer)... Maybe I'M confused... A clean install? I'll have to test that...?? Two folders - Windows\SoftwareDistribution (the "normal" one) and this one - Directory of C:\WINDOWS\system32\SoftwareDistribution 08/22/2009 01:55 PM <DIR> . 08/22/2009 01:55 PM <DIR> .. 08/22/2009 01:55 PM <DIR> Setup Directory of C:\WINDOWS\system32\SoftwareDistribution\Setup 08/22/2009 01:55 PM <DIR> . 08/22/2009 01:55 PM <DIR> .. 06/14/2012 12:13 PM <DIR> ServiceStartup Directory of C:\WINDOWS\system32\SoftwareDistribution\Setup\ServiceStartup 06/14/2012 12:13 PM <DIR> . 06/14/2012 12:13 PM <DIR> .. 06/14/2012 12:13 PM <DIR> wuapi.dll 06/14/2012 12:13 PM <DIR> wups.dll 06/14/2012 12:13 PM <DIR> wups2.dll Directory of C:\WINDOWS\system32\SoftwareDistribution\Setup\ServiceStartup\wuapi.dll 06/14/2012 12:13 PM <DIR> . 06/14/2012 12:13 PM <DIR> .. 06/15/2012 06:01 PM <DIR> 7.6.7600.256 Directory of C:\WINDOWS\system32\SoftwareDistribution\Setup\ServiceStartup\wuapi.dll\7.6.7600.256 06/15/2012 06:01 PM <DIR> . 06/15/2012 06:01 PM <DIR> .. 06/02/2012 03:19 PM 577,048 wuapi.dll Directory of C:\WINDOWS\system32\SoftwareDistribution\Setup\ServiceStartup\wups.dll 06/14/2012 12:13 PM <DIR> . 06/14/2012 12:13 PM <DIR> .. 08/22/2009 01:55 PM <DIR> 7.2.6001.788 06/12/2012 03:22 PM <DIR> 7.6.7600.243 06/14/2012 12:13 PM <DIR> 7.6.7600.256 Directory of C:\WINDOWS\system32\SoftwareDistribution\Setup\ServiceStartup\wups.dll\7.2.6001.788 08/22/2009 01:55 PM <DIR> . 08/22/2009 01:55 PM <DIR> .. 10/16/2008 02:08 PM 34,328 wups.dll Directory of C:\WINDOWS\system32\SoftwareDistribution\Setup\ServiceStartup\wups.dll\7.6.7600.243 06/12/2012 03:22 PM <DIR> . 06/12/2012 03:22 PM <DIR> .. 08/11/2011 02:36 PM 35,320 wups.dll Directory of C:\WINDOWS\system32\SoftwareDistribution\Setup\ServiceStartup\wups.dll\7.6.7600.256 06/14/2012 12:13 PM <DIR> . 06/14/2012 12:13 PM <DIR> .. 06/02/2012 03:19 PM 35,864 wups.dll Directory of C:\WINDOWS\system32\SoftwareDistribution\Setup\ServiceStartup\wups2.dll 06/14/2012 12:13 PM <DIR> . 06/14/2012 12:13 PM <DIR> .. 06/12/2012 03:22 PM <DIR> 7.6.7600.243 06/14/2012 12:13 PM <DIR> 7.6.7600.256 Directory of C:\WINDOWS\system32\SoftwareDistribution\Setup\ServiceStartup\wups2.dll\7.6.7600.243 06/12/2012 03:22 PM <DIR> . 06/12/2012 03:22 PM <DIR> .. 08/11/2011 02:37 PM 44,536 wups2.dll Directory of C:\WINDOWS\system32\SoftwareDistribution\Setup\ServiceStartup\wups2.dll\7.6.7600.256 06/14/2012 12:13 PM <DIR> . 06/14/2012 12:13 PM <DIR> .. 06/02/2012 03:19 PM 45,080 wups2.dllNote the dates... These were here WAY before (at least WUPS was already there...)

@-X- KB2607070 contains a direct link to x86/x64 v7.6.7600.243 (the link makes it LOOK like 7.4.7600.243). Rest assured, this is the LATEST Redistributable one (aside from v256)... Working on a CMD script (functionally the same as .BAT script) to "construct" the v256.

DUHHH! Guess you have to wait 'till next month OR maybe -X- will change it soon OR you can change it yourself before you run it.

You don't mean "mscvp60.dll"... you mean "msvcp60.dll"... Get it here.

http://windows.microsoft.com/en-us/windows-vista/Windows-Remote-Assistance-frequently-asked-questions http://www.sevenforums.com/network-sharing/48190-remote-assistance-linksys-router.html HTH

-X- has apparently not changed the BAT script yet. Patch Tuesday is tomorrow. Really doesn't matter for v226 vs v243, so no biggie...Read these KB articles to better understand. v226 v226 v243 The 'latest" v256 one (which is what this topic is about) is not yet available except via WSUS (AFAIK). And yes, they all work on XP/2K3 as well as Vista/Win7/2K8 (look at the "Applies To" in KB#). The KB943144 only refers to XP, the KB946928 refers to All, however KB2607070 only refers to Win7SP1... MS' "scatter sense"... Clear? edit - @dencorso - thx for the tips... working on it. Now only need links to 3 Cabs for x64... Do NOT want to bother with loading/restoring the VistaSP1 x64 onto my "new" Dell E521's just yet (has MCE2005 on one and other is still in pieces)... too busy with other things - this and 5 more PC's to "dump".

Lost younger daughter and later my father-in-law just a few months ago. Hurts, but you have to carry on. They will be waiting for you...

@erpdude8 - You should reread this thread... I quoted that exact same phrase from that exact same "Answer" thread. @-X- I have everything except the 3 CABS (BUT that are irrelevant to XP) built into a script. The last problem is how to get XVI32 to "chop" the CAB portion off of the original/older (v243) MS WU-file programmatically. BTW, changing your script to point to "7.4.7600.243" will yield "7.6.7600.243" (see KB2607070). The KB949104 in question actually claims the last one is "7.4.7600.226" and KB946928 point to the "v226" as well. MS is really confusing the issue on this matter. Maybe this all has to do with the Win8 Rollout (noting the "v256" WU files appears in the "v9" download set)? (some info/links courtesy of "chasers" 5eraph and ricktendo64) Just to add more confusion (post#44) and last page (post#53) in particular. Also note that this and this strangely both point back to KB949104 (LinkID's from those that actually got the v256). Also here (references to WSUS rollout of v256 and the KB2720211). Still, probably just an "exercise" in "how to download from MS and construct it". "They sorta pulled the update" may make it irrelevant.

...and everything before that is the SFX (regardless). Hmm... maybe just look for LAST one and "collect" everything preceding? And, no, it apparently doesn't matter which version, as stated above - as long as it's an unsigned non-IE package (apparently but unsure). Just correcting the "can't get to work" thread (can't remember which one) that WildBill originally posted "how-to" that everyone apparently didn't understand...edit - (No, I have no clue what the other 2 MSCF sections are - maybe single-file compressed something.XX_?) Nope... apparently just a Character String used by the SFX (any.XX_ has a single real-expanded-name inside). Still have to find out (just got back onto this) which free hex editor will "rip" the SFX from the "official WU". The solution to the x2000->x6000 is obviously to CAB the Setup program FIRST to a known location (also will need hex-edited). Got "Extract" from the downloadable Win2k RK (an MSI inside - ugh!). Nearly complete... @-X-, this is for you if you really want it. @all, I appreciate it all. (too broke to donate $ to anyone, so contribute via effort) side note - the "package" isn't too shabby time-wise to "construct" but it's a looong CMD script. Will probably "replace" the one in prior post. edit - Responding to next post - Wait for it! As soon as you see the "finished" CMD you'll go "OHHHHH! I see!" edit2 - DUH!!! Wildbill suggested... xvi32 (has script interface)

I've got everything done (for x86) except Missing - WUClient-SelfUpdate-ActiveX.cab WUClient-SelfUpdate-Aux-TopLevel.cab WUClient-SelfUpdate-Core-TopLevel.cab Apparently from some DISM files? (unsure) Download link to MS SFX is gone... BUT snagging the x0->x89FF seems to get what's needed. The same Hex-length seems like MAYBE valid for the MU-v7.6.7600.24 (it uses SFX-v6.2.29.0). note - in Hex-editor, the THIRD "MSCF" string is the actual CAB. Changing x2000->x6000 BEFORE the "copy /b" (i.e. AFTER the MAKECAB) will work AGAINST THE CREATED CAB. (finding "wusetup.exe"). This would be the "tricky" part in a CMD script. CABARC is downloadable directly from MS but MAKECAB will also do LZX-21. Will use CABARC... @Dencorso - It appears that MUWEB.DLL is from "muweb_site.cab" and is for the ActiveX for Microsoft Update as opposed to Windows Update. edit - OOPS! see this. It can be obtained...

Seen on ABC TV's "ticker" at the bottom that MS is planning on RTM for the ARM version for Tablets as we speak to "compete with iPad". No mention of us poor suckers...

Re-read the thread. It's already a given that the "Standalone" is not available. It is, however, being rolled out via WSUS Servers (see 5eraph's posts). I'm working on "constructing" what you might called a "latest add-on" (replicating Ricktendo64's manual(?) effort via a CMD/WGET directly from MS), same as -X- is doing. I already have the ENU files in place. File Dates are June 2, 2012... Comparing to Ricktendo64's package now... (Still need to re-find the 3 CLIENT cabs apparently for Vista/Win7.)You might call this an "exercise in obtaining the latest WU"... @Ricktendo64 - I don't see that in any of the CABS? From KB2720211? Also, how did you get the "self-extract" portion of the Package (hex-out the front-end?)?@-X- (and anyone else...) Attached is my "work in progress". Feel free! edit - Attachment removed... See post#63 for the "x86 finished product".

http://allthingsd.com/20120614/microsoft-schedules-la-event-for-some-windows-tablet-talk/?mod=tweet

Congrats! -X- what do you think? I think the "system" has been beat! edit - Absolutely NO time to test, but from all appearances it looks good! Got a Sound Engineer gig in about 3 hrs (two groups). 90-Proof Twang and Ryan Broshear - "New" Country + originals (up-and-coming groups out of Oxford, OH).

ARRGGG! Shades of Win9x!!! That is something I NEVER did! Worse, working on someone else' PC it was GAWD-AWFUL to see anything! Give me DRAB so I can be HAPPY when I get something to "work"!To each their own... Doubting the majority of Techies ever fiddled with it either (eye-candy)... More than likely (32-bit). Doubt that. You must NOT be referring to the DOS-based games. I.E. later Entertainment Packs were 32-bit as opposed to EARLIER ones. Indeed you needed the Windows 3.x 32-bit add-in to achieve it with many. Better read up on 16-bit... They will NOT run on XP and up hence my doubt (you NEED a dual-boot). Go ahead and try OLD Duke Nukem (could be wrong about that one)! edit - My bad - there is a "switch" for 16-bit... http://www.winbeta.org/news/windows-8-will-run-16-bit-apps-says-microsoft http://www.askvg.com/windows-8-comes-with-built-in-16-bit-application-support/ XP 16-bit problems - http://support.microsoft.com/kb/324767 ...and more than likely Vista and Win7... SO... they must have FIXED the nasty "bugs"... Kind of like "Compatibility Mode"...

...and I would venture to say that the other LANG files could be obtained. Appears that all you need is the latest Standalone (Extracted), replace all files for the downloaded above into Extracted, modify the INF, repack, and run the SETUP via the ENTRIES.INI. Not really sure about that, but APPEARS to work that way. This could be a "workaround" until (and IF) MS decides to release the "StandAlone". (WUSETUP in this case appears to be irrelevant per the Version? Only appears in PreFetch and "came from" the Generated Folder Name during install). I don't want to even bother with the MU-part; I had apparently "Stepped Up To" once, then, "disabled" it (apparently that's what happened during the "Customize/Use Windows Updates Only), and used your method in a VPC to "force" Update WU, and it "collected" everything into the correct places. Afterward, I "Stepped Up to MU" and it appears that all it did was re-enable the ActiveX that already existed (v7.4.7600.226, BTW). Side note - I had Installed (over top of the v226) v7.6.7600.243 before I pulled your "stunt"... I guess I should try (later) a Clean Install, then v2.43, then your "stunt" to confirm a few things. Won't be able to today because BUSY BEE! edit - As far as -X- is concerned, he only does ENU anyway...

@Ricktendo64 - what's a great idea? Getting tied up BY Grandkids? edit - see previous posts ramblings... edit2 - OH!!!! I just looked inside the "blah-blah - rename to CAB" cab!!! DUH!!! "I can see clearly now, the rain has gone..." (old-skool song)

@5seraph - added another question And my interest lies also in -X-'s listings (no offense, just another method of integration). It appears that with the "add-on" that he creates (just a CAB with an ENTRIES.INI and the WUA.EXE) that IN THEORY this could be done BUT one would have to obtain the REMAINDER from MS on a "live" OS and constructed on your PERSONAL computer (to keep from violating the EULA's vis-a-vis redistribution) on-the-fly (since all files are downloaded directly from the "source"). edit - WOW! Becoming a semi-hot topic! (see Ricktendo64 comment below) One might also note the the actual older v243 Package has everything in it to install (i.e. WUSETUP.EXE/INF?). What would be "missing" is all the latest MUI files for non-English, correct (ref. the KB article)? (could be obtained directly, though, according to Languages) edit2 - errr... the WUSETUP.EXE would have an erroneous version, BUT the INF could be modified to "fit" the Correct Version?

@5eraph - Gotcha! Then (in theory) one could "construct" a full package pre-release... perhaps using the prior version's Setup Package as an example? BTW, good further investigation! edit - and I assume that the x86 version of WSUS update will work on an x86 as well? (you didn't mention that in instructions - only the WSUS-KB2720211-x64.exe) I guess I should mention I'm kinda tied up with Grandkids, so I may not be totally understanding/coherent...

KernelEx is a kind of "mod" inappropriate to an actual Service Pack ("Just the fixes, Ma'am"), hence listing items separately (and not including) that work with it. Are you speaking about using it (and associated Fix Files) as OPTIONAL?

(heh... wiped my comment as well. NBD tho... the point was made..??? When I went to "link" it was THROW PILLOWS.) Qwee-Sarah-Sarah!!!

Did you mean to include the x86 "muweb.cab" with the x64 set? For the purpose of using the x86 version of IE on an x64 OS? Note: This doesn't include ALL of the files listed in KB949104... some appear to be missing for the non-Vista/Win7... (UNLESS the "force" variation "collects" them all...)

"C:\Program Files\7-Zip\7z.exe" a %zipFileName% %allFromOutputDir% copy /b "C:\Program Files\7-Zip\7zSD_LZMA.sfx" + config.txt + %zipFileName% %outputFile% where : %zipFileName% = "MySetup.7z" %allFromOutputDir% = all of the items that currently exists in the output dir of the setup project. (bin\release\...) %outputFile% = "MySFX.exe" this is the config content : ;!@Install@!UTF-8! RunProgram="setup.exe" GUIMode="2" ;!@InstallEnd@! Contents of %allFromOutputDir% (after which the zip contains these items): - setup.exe (OBVIOUSLY WRITTEN IN-HOUSE TO CHECK/INSTALL) - "WindowsInstaller3_1" folder (pre - requisite) --- WindowsInstaller-KB893803-v2-x86.exe (FILE WITHIN FOLDER!!!) - "DotNetFX35" folder (another pre-requisite) --- dotNetFx35setup.exe (FILE WITHIN FOLDER!!!) - MySetup.msi (NOT WITHIN A FOLDER!!!) ===== The Actual SFX Execution ===== <snip> Running checks for command 'WindowsInstaller3_1\WindowsInstaller-KB893803-v2-x86.exe' <snip> Running checks for command 'DotNetFX35\dotNetFx35setup.exe' (My Note: This is the Bootstrapper and NOT the "Full", correct?) (http://www.careerride.com/Dot-Net-bootstrapper-application.aspx) <snip> Launching Application. Running command 'C:\WINDOWS\system32\msiexec.exe' with arguments ' -I "C:\DOCUME~1\...\LOCALS~1\Temp\7zS909.tmp\MySetup.msi" ' ----- Result (according to Your Notes): "This installation package could not be opened..." (My Note: OBVIOUSLY a result of NOT FINDING THE MSI FILE!) (My Note: You APPARENTLY have used "\...\" to keep us from seeing UserID?) -OR- "Could not read configuration or configuration not found". (My Note: OBVIOUSLY because CONFIG.TXT is NOT properly included!) ===== Your Comments on Failures ===== The setup alone does work on both OS... (XP and win 7). Only after creating SFX and using it - it does not work on win XP. And yes - the setup pre-requisite is to install .net frame work. (My Note - Your are programmatically checking MS-Installer+DotNET) On my comuter which OC is win7 - it works good! (My Note: You are referring to the SFX Install.) But when i try to run it on WinXP pro x86 i get this error after extraction : "This installation package could not be opened..." ===== From 7-Zip ORG files ===== Failure #1 - create the SFX like this : "C:\Program Files\7-Zip\7z.exe" a %zipFileName% %allFromOutputDir% copy /b "C:\Program Files\7-Zip\7zS.sfx" + config.txt + %zipFileName% %outputFile% When running its product - it cause this error : "This installation package could not be opened..." Failure #2 - or like this "C:\Program Files\7-Zip\7z.exe" a %zipFileName% %allFromOutputDir% copy /b "C:\Program Files\7-Zip\7zSD_LZMA.sfx" + config.txt + %zipFileName% %outputFile% When running its product - it cause this error : "Could not read configuration or configuration not found". Failure #3 - 1 - DO NOT USE THAT ONE!!! USE THE FIRST ONE (the BETA one!!!) 2 - OR DON'T USE IT, BUT USE THE 7-ZIP ORG ONE 3 - PLEASE NOTE! MSIEXEC CANNOT FIND THE MSI!!! 3a - TRY to put it in a SUBFOLDER and see if that works 3b - NOTE that when you RUN the MSIinstaller AND/OR the DotNETinstaller that they CREATE A TEMP FOLDER ON THE ROOT OF THE LARGEST FREE-SPACE DRIVE! Your Application is NOT doing that! It is INVOKING the MSIEXEC.EXE Program! The question is... IS YOUR SETUP.EXE CORRECTLY PASSING THE PATH TO THE MSI FILE??? -To test this - WHEN it Fails with "This installation package could not be opened..." NAVIGATE in EXPLORER to the TEMP folder and SEE IF IT IS INDEED THERE! Bottom Line - We have NO CLUE how you CREATED the SETUP.EXE PROJECT!!! (My Note - MAYBE you need to use DOUBLE-QUOTES?) Go BACK here and read CLOSELY the "Configuration Parameters" section. YOU NEED TO CORRECTLY PASS THE PATH TO THE MSI! PERIOD!!! FORCE it to "somewhere"!!!

Drag-And-Drop is COPY!!!!!! Via "Temp" Folder! Period!

Whew! I thought I was losing the last of what was left of my mind!