jvidal

Mimo, new IE cummulative HF, we need an update... bye!

MIMo, MRT v3.5 released today!

Don't worry, I'll make a few experiments and see what happens. I just need to now one thing: Handling of MSI4.5 should somehow be excluded from "regular" HF handling and be dealt with separately, right? (I think that's what happens in HFSLIP) Oh, and BTW, looking at HFSLIP's code, it seems it extracts all mui files, then finds the one corresponding to the language in SOURCE and renames the file to msimsg.mui. Something like that needs to be done. Ok, I now know what's going on: First 942288 has to be added to the "ignore" variables. Then, a special section for MSI45 needs to be created. The file msimsg.dll.xx-yy.mui needs to be renamed to msimsg.mui (where xx-yy is the lang in source) Add the correct values to txtsetup.sif/dosnet.inf Finally the files need to be copied to the appropriate folders. The code could be ported, the problem is that the dir. structure used by HFSLIP64 is different from the one used by HFLSIP, plus the variable names are also different. If that can be figured out, it wouldn't be very difficult, I guess.

Any (simple) way to slip them? (maybe I could try "porting" the code from HFSLIP, with the necessary mods)

BTW, I slipstreamed MSI 4.5 and although it does work, all messages (textboxes, buttons,etc) appear empty.

why would anyone place RAR files knowing they don't work????

I think you should change the description for LegitCheckControl.cab to something more "understandable", like "Windows Genuine Validation" or similar. The other name doesn't actually say anything. It doesn't mean anything also. the phrase has no logic in it. bye! BTW: I survived the Eartquake!

Thx again, Mimo! Oh, and BTW, what the hell does "Found Avoid '0x80080201 Cannot detect product ID (PID)" mean????????

Can someone pick up where tommyp left off? I'd hate to see this project dead...

Tommy, is MSI 4.5 supported by hfslip64?

Why does the KB article say that IE8-KB976662 doesn't replace any previous HF, when it actually does? we need a new version, mimo. thx!

Mimo, I confirm, messenger.msi works fine in HFGUIRUNONCE. I originally had it it in HFSVCPACK_SW1, to have it insatlled at T-13, but it didn't work, for some reason. Moved it to HFGUIRUNONCE and it works perfectly.

thanks again, tommy!

well?

Another thing, mimo, you still haven't addressed the 946648 vs messenger.msi (5.1) issue...

Ok, Done. system32\shlwapi.dll , syswow64\shlwapi.dll , system32\dllcache\shlwapi.dll & system32\dllcache\wshlwapi.dll are all the correct ver. i.e. 6.0.3790.4603. (no need for that wshlwapi.dll check, as you can see) Also, it was never an issue, read #3 again. Plus, MU is completely happy, nthing required. Time for a new final I guess.

thx, tommy. I'll do that and report back to you. c ya! Oh, BTW, wshlwapi.dll also comes in the IE8 installer, inside a wow folder.

Let's not fight about this. Maybe you could add a warning, something like "Known to cause problems. Use at your own risk. Please read the KB article carefuly" That could prevent inexperienced users from using it... BTW, the latest version is corrupted. the file is damaged.Please re-upload.

Disabling advisories may also lead to removing actually useful hotfixes. I insist, if you read the KB article, you'll see what I'm talking about. This hotfix breaks more stuff than what it fixes.PLEASE READ THE KB ARTICLE. Also, a user might integrate that HF without actually knowing it may have nasty effects.

I did another "experiment". This time I installed xp64 SP2 (non-hfsliped). Shlwapi.dll had version 6.0.3790.3959 (the one from the CD) Then I manually installed IE8 (which contains the older version of the file, v6.0.3790.2795). Rebooted and checked the file versions. Turns out the file still was ver. 6.0.3790.3959 (the file was NOT replaced by the older version). Then I installed 975713 and the file was updated to v6.0.3790.4603. bye again!

Ok. I found the problem. Shlwapi v6.0.3790.2795 comes in the IE8 installer. (why it's older than the one in the source it's anyone's guess) If IE is processed first, then why doesn't the file from 975713 replace it? bye!

Ok, did it. AMD64\shlwapi.dll is now v6.0.3790.4603, which is correct (the version from the HF) I386\wshlwapi.dll , same as above. So, there is s/thing interferring with the HF. The weird thing is that the filver from the original file is the same as the resulting one, so there shouldn't be another HF replacing the file, in that case it would probably have a different version num. I mean, before HFslip--> v6.0.3790.2795. After hfslip with 975713--> v6.0.3790.2795. No, wait, that's not right. I just checked shlwapi.dll from source\AMD and it has filever 6.0.3790.3959. So, it seems that one HF is installing a version that's even older than the one in source. I'll check other HFs, maybe there is an obsolete one that's messing things up.

Ok, I'll do that and report back to you asap. bye!

Ok, after my experiment, everything went fine, no updates wanted by MU. So, the question is why is the file shlwapi.dll not being copied to AMD64? bye!

I did a little experiment, I took shlwapi.dll v 4603, renamed it to shlwapi.dl_ (without actually compressing it) and copied it to sourcess\AMD64. Next, I ran hfslip with the makeiso "undocumented" feature. Installing as we speak.