Jump to content


  • Content Count

  • Joined

  • Last visited

  • Donations


Everything posted by Tomalak

  1. Tomalak

    Windows Updates

    Hello, The Adobe flash player was updated once again (security issues resolved). I have uploaded the addon here at Mediafire (version SHA1 checksum a207aa9f705ba0b5fb27fcb92b69d8640cdae863 MD5 checksum 05e77185a011b177591a714a517e45cc
  2. I use the packages as generated by SNM, no further modifications. If put into the HFSVCPACK_SW1 folder of hslip, they are exectued at T-13 via svcpack.inf with the following parameters: "/quiet /norestart". This has always been the case, no change on hfslip side here. When installing them after Windows setup, I just execute the files without parameters, and this works without a problem. No time left now, so I can continue testing only next weekend. Maybe someone else can try meanwhile what happens if the packages are run with the above parameters, but on an already installed Windows (instead o
  3. Same problem for me (only used 2.0, 3.0 and 3.5, nothing installed at the end, i.e. after Windows setup was completed), used version 20100102 for creation of the installers. But I got an error message during T-13 phase, saying something similar to "Use %FILENAME -h for help" with just an okay button (that's right, only one '%' sign). This has worked before, but I cannot tell you which was the last version I tested it successfully. If required I can re-do this later in a virtual machine to provide a screenshot. By the way, running the same installers after Windows installation was fine, no mess
  4. Of course, here it is. I also played with the settings (e.g. including WIC and MSXML6 for .Net 3.0, as it is default), but that didn't change anything. Note that I'm building a German version of the packages - using corresponding files for the hotfixes - on a Windows XP Professional. Any more information or help I can give? Hope that helps to recreate the error PROCESSDATA.TXT
  5. Problem persists with most recent version (20091229). The MS API error in the cmd window is gone now, but the message window with the 2727 error is still there...
  6. Hello Mim0, I'm sorry but I do not fully agree, these contents are not all mandatory. So here are some remarks from my side regarding table 2 (security updates): First of all, I think it makes not much sense to list updates for components that are by default not installed. In this case they should have a note explaining that they're usually not useful or necessary. This applies at least to the following entries: MS09-023 (Windows Search 4.0): Windows Search 4.0 is not part of a standard Win XP SP3. You do not even have it in the list of optional updates... MS09-051, KB969878 (DirectShow WMA V
  7. I didn't say it's bad - just that it's not the ultimate truth and common sense still applies. And yes, it is very helpful and actively maintained - we can be glad that Mim0 takes care of it! No better list (although I have my own internal list of updates I include), so nothing to write about. I think we're better off with not more lists, but one reliable reference list instead. And so of course I contribute by informing Mim0 about issues I have with his list, and he can then improve if he agrees with my suggestions. This helps us all B) Regards, Tomalak
  8. Ah, yeah, now I see, you already reported this. According to Microsoft the error 2727 means "The directory entry '[2]' does not exist in the Directory table." Seems that something is broken in one of the transform files...
  9. Hello, I have a problem with the most recent SNM script (20091224). During processing of the KB963707 update (for .NET 3.5 SP1) an error occurs with code 2727, and the package is not built correctly (way too small compared to previous runs). See attached screenshot. Settings deviating from default .ini file: DNF35FFXBAPPLUGIN=NO DNF35FFCLICKONCEEXT=NO Thanks for investigating! Tomalak
  10. Of course, because it's not necessary. XMLlite is already included in Service Pack 3. See here, and KB915865 is also directly listed here. Take Mim0's list with a grain of salt as there seem to be some minor issues with it, and do not blindly include everything just because it's listed there... Kind regards, Tomalak
  11. Tomalak

    Windows Updates

    Hello Mim0, Regarding your update list: KB958911 (optional GDI+ update) needs to be removed from table 3 (and your update checker), as it is outdated and has been superseded by KB958869 (MS09-062). KB976098 (cumulative timezone update) is listed as to be put into HFSVCPACK_SW1. Any special reason for this? I have found that it works flawlessly in HF. Kind regards, Tomalak
  12. Tomalak

    Windows Updates

    I've uploaded an updated SWFLASH.CAB (version here SHA1 checksum c0d67df4e53927ecf834ca007816d43a0c62add5 MD5 checksum 07bd474624bfa8e0937dea4eefdf18a8 Are you sure there is an updated cab provided by MS? Not a manually reworked one? As far as I know the most recent version of 'legitcheckcontrol.dll' is to be found in KB905474 (Windows Genuine Advantage Notifications, last updated 2009/03/24). Sorry, but I can only provide the direct link to the German version. Maybe someone can determine the English one (from Windows update log)? Extracting this file and then using "wganotifypack
  13. I tried this tutorial but when I install xp and the files are copied I get error: advpack.mui cannot be copied. Same for me (by the way, you can skip the error and continue), this seems to be a general problem with this kind of setup. I tried the above mentioned SetupWinFromUSB tool as well as WinToFlash, identical result. So yesterday I decided to use the direct approach - put WinPE to an USB flash disc with SOURCESS folder on it (no problem when installed from CD to a VM, so the source is okay), booted from it, launched Windows installation via "winnt32.exe". Installation was overall succes
  14. Okay, short followup. With the test install from CD in a VM everything worked as expected - no file copy errors (except my famous "tweakui.exe" problem ) and no other problems. So everything I experienced with the other install like several files not being copied, one update reported as missing, reg files in HFSVCPACK not being applied etc., seems to be the result of the above mentioned WinSetupFromUSB tool which apparently broke several things by fiddling with my source. So my quest continues to find a way how I can install Windows from an USB stick, but based directly on thee ISO image or at
  15. Well, it was not. Of course. I meanwhile found out the reason... Stupid me Yes, that was exactly what I was doing next - testing with unmodified source. Failed as well, so no hfslip issue. And then I had the crucial idea: I was able to get the full i386 directory from the DVD (resp. Ghost image on it), but not the few files on top level (e.g. setup.exe), they are not stored in the image. So I took these files from the XP Pro source. What I didn't know is that the identifier files for Windows and the applied service packs have different names for XP Home and Pro. So renaming "WIN51IP", "WIN51
  16. Well, to be honest what I said above is not exactly true: one change I did was the replacement of the SOURCE folder content. I was doing my tests so far (for MSI installer and debugging some other things) with an XP Pro source and in a VM, but now as I wanted to install XP on a netbook, I used the respective XP Home source which I extracted from the recovery DVD. I didn't create an ISO image (so a bad burn cannot be the reason), but put the resulting SOURCESS directory to an USB stick and did the installation from there, with the help of WinSetupFromUSB. This might have been the source of my p
  17. Hello, Just wanted to let you know that in a another hfslip run (with version "r" this time) I had several files in the textmode phase of setup with the "could not be copied" error message. Files seemed not to be related to each other or to all belong to the same patch. Nothing changed compared to my previous attempts (except that I this time installed on a real system instead of a virtual one), so I'm really puzzled. Not a big problem, as all these files (6 or 7 IIRC, among them "advpack.dll.mui", "jscript.dll.mui") were translation files only, i.e. "<something>.mui", but strange nevert
  18. This does not work for me, I'm sorry. I added KB974417 yesterday when I rebuilt my silent .Net packages (2.0SP2, 3.0SP2 and 3.5SP1) for T-13 installation (doing my WIndows setup with hfslip) witn SNM of 20090922, but afterwards this patch was still listed as missing in Windows resp. Microsoft Update... For some reason it is not recognized as installed. Can anybody confirm this? Can I help somehow in debugging? Thanks in advance! Regards, Tomalak
  19. Hello, I can confirm that version o (20091012a) works now as desired and slipstreams MSI installer 4.5 perfectly. I was able to install silent packages for DotNet 2.0, 3.0 and 3.5 at T-13 (HFSVCPACK_SW1) and Silverlight (HFSVCPACK_SW2 with modified switches) during setup, as well as some regular MSI based software afterwards, all without any problems. And I also already tested with all new updates from yesterday's patch-day. Again everything okay, no peculiarities. Hail tommyp! But today I got a new error message during the textmode copy phase (see attached screenshot) - never seen that bef
  20. Hello, I found out how to satisfy MU/WU so that it considers KB905474 (item 11) as installed and does not report it as missing when searching for updates. It's one single registry entry that has to be added (not all that are listed by Acheron here are really necessary). Please see my updated post above for details. I think most of the 'open topics' I stumpled upon when returning to hfslip are solved now. Great! Regards, Tomalak Update: Sorry, seems that MSFN currently ruins the URLs of links to other posts even though I entered them correctly...
  21. Yep, you're right, but it was the thought that counted. lol. New beta rev o posted. Added in gluon's contribution too. Meanwhile tried, in contrary to my words above (who needs sleep anyway? Note to myself: don't be that impatient), previous version "n" with corrected logic. Works almost perfectly now, except one problem: the 'msimsg.dll.mui' was copied to system32\mui\1031, and not system32\mui\0407. Seems that the hex value is required here, not the decimal one...
  22. Hello tommyp, Ok, just found the time for a quick test (no changes in my input files except removal of the HFEXPERT\WIN\system32\mui\<LANG>\msimsg.mui file as this should be handled by hfslip now). Sorry to say, but that failed. Still had the old Windows installer after setup (even broken in my configuration as I slipstreamed an updated msi.dll 4.5.something), with all files having version 3.1.something. Looking at the code, without understanding too much of that batch language: sure it should read "IF NOT" instead of simply "IF" at the beginning of line 506? Seems to me that the logic
  23. Tomalak

    Windows Updates

    Hello Muppet Hunter, Another update. I vaguely remember reporting once something very similar (only a minor difference in otherwise very similars URLs for two different files), but I cannot find that again... STUPID STUPID STUPID MICROSOFT! Please change the link for "muweb_site.cab" from this one: http://update.microsoft.com/microsoftupdat.../muweb_site.cab to this one: http://www.update.microsoft.com/microsoftu.../muweb_site.cab Look almost identical? Only an additional "www"? Yes, that's right! But they refer totally different files. The first one is from 2008/10/17 and contains version 7
  24. Moved to the updates thread...
  25. Hello all, Made some progress... Here's a short update (well, not so short, have to give the story as it was some work to figure it out). Seemed a little bit too much work for me, and in this case all the details for the registry from the inf files etc. would not be considered. So I started by repacking the hotfix to a new package, putting just the correct files in it (for German language in this case) and rearranging the file and directory structure so it looks like any ordinary hotfix. Finally had a replacement executable, an "improved update". Only to find out, one hour later, that running
  • Create New...