XP SP3 Problems/Help

[Guest VanguardLH]

Re: XP SP3 Problems/Help

 

"Ale" wrote in

<news:7E351AF2-679B-4661-9137-69ACB93F6AA8@microsoft.com>:

>

> "VanguardLH" wrote:

>

>> "Ale" wrote in

>> <news:27BC58E5-5BA0-4361-90EE-3E10A73BEADE@microsoft.com>:

>>

>>> The reason why I did not mention the option of slipstreaming SP3 into the XP

>>> SP2 CD is that from what I read it is not possible to slipstream, or at least

>>> it's more problematic, when the CD is an OEM version, right?

>>

>> I slipstreamed SP-2 into my OEM CD for Windows XP Pro SP-1. So why

>> can't SP-3 be slipstreamed into an OEM CD for Windows XP Pro SP-2? The

>> slipstreaming is done on your hard disk and then you copy the files onto

>> your own recordable CD. Unless I missed it, I never saw mention that I

>> cannot slipstream using an OEM CD as the baseline version. Obviously a

>> service pack updates retail or OEM versions of Windows.

>>

>> Please point me at the articles you read that say OEM cannot be used as

>> baseline to create a slipstreamed modified version of it.

>>

> Vanguard, read this thread which at the time I posted in the Dell Community

> Forum:

> http://www.dellcommunity.com/supportforums/board/message?board.id=sw_winxp&message.id=120692

 

I wasn't aware that Dell ever gave you a *install* CD but instead gave

you a reimage CD (with a setup program wrapped around it). You cannot

slipstream using an image as your baseline. Dell has their own

bastardized setup scheme. I'm not sure if following their procedure to

burn a CD from their hidden partition containing the restore image will

actually create an *install* CD. Dell has a license to distribute

Windows but that dictates nothing of how they deliver a recovery or

reinstall for it. When I had to order restore CDs from Dell (because

the disk went back so the hidden partition was unavailable and the user

didn't previously burn the restore CDs), those weren't what I'd call

install CDs.

[Guest Tim.C]

Re: XP SP3 Problems/Help

 

Now I *am* confused!

I did another box last night and went for the movefile-with-two-source-files

approach. The end result was the reverted version of browseui.dll sat in

dllcache and the SP3 version still sat there staring at me from system32!

Both source files vanished, so both moves fired correctly (and I did run

pendmoves before the reboot to double check on this one).

To make matters more interesting, WFP didn't seem to have an issue with this

rather obvious discrepancy.

I again resorted to a Bart PE disk (although I'm sure that Recovery Console

would be as effective) to overwrite the new with the old and all was as

expected after that.

Now, I wonder if the traffic here indicating that this mod does not work

with the Release version of SP3 is due to there being something in there

that's not allowing this reversion to be accomplished with conventional

weaponry......

 

 

"VanguardLH" wrote:

> "Tim.C" wrote in

> <news:C720420A-FAF6-4EF1-9DB6-0E4DDBDBE1BF@microsoft.com>:

>

> > Vanguard,

> >

> > I hate to be a bearer of bad news, but methinks that there's an "oops" in

> > there. I reckon, from trying this, that "movefile" does what it says on the

> > tin (i.e. *moves* the file). So, what happens is that the move to dllcache

> > goes off and then the move to system32 goes pear-shaped as there's now no

> > source file for it to move from :-}

> > Took me a while to work that one out. I resorted to using a Bart PE disk to

> > copy the DLLs, but I reckon that using "movefile" with two copies to start

> > with should also be OK.

> >

> > Anyhow, despite traffic to the contrary, this *does* restore the address bar

> > to the vanilla, release version of SP3.

>

> Thanks for the check. I had assumed 'movefile' would do copy but it

> makes sense that it moves. I tried using Microsoft's 'inuse' utility

> but it it checks if the file is protected by WFP. Since it is a

> protected file, inuse refuses to setup the pending file change on

> Windows startup using the registry key. I wanted to instruct using a

> utility rather than have users go editing the registry.

>

> When I did the original test in a virtual machine, I had only used

> 'movefile' with the system32 destination. Then later I realized that it

> should also get replaced in the dllcache to subvert WFP.

>