so if it doesn't, it won't install it ... to prevent the error ...
this would help those who remove the other i386 directories

I don't think HFSLIP shouldn't put the line if WINNTUPG is not detected. The user isn't forced to copy the entire CD source prior to running HFSLIP.

@Super-Magician: Sorry for the delay but your suggestion regarding MakeNoISO and MAKEISO is implemented in 60613b.

I'm thinking a few months from now someone will encounter this issue when they run HFSLIP with InstallRC=1 in his or her HFANSWER.INI file and no WINNTUPG folder. Then, they will come yelling for help.

Thanks!

salamat kabayan!

ish.. my original source CD from hp, slipstreamed with SP2, does not even come with those WIN**UPG folders.. But, of course, I'll get those folders if I manually slipstream SP2 (or "let HFSLIP do it, if I'm too lazy") to a pre-SP2 source...

I agree that it is up to the user to copy or not the entire source. And if the user chose not to include, or delete those folders, then the user must not use the InstallRC=1 option.

For this reason, I was thinking of a simple addition to the HFSLIP instructions that as a prerequisite for using InstallRC=1 option, winntupg folder must exists in the source..

No -- The user should be able to enter "InstallRC=1" at any time without restrictions. My point was that the user should be allowed to copy the WINNTUPG folder *after* running HFSLIP.

That the WINNTUPG folder is required for the RC to be installed will of course be mentioned on the "Special features" page (the only page that will refer to this functionality).

that sounds good...

I'm testing HFSLIP now with the latest updates for Windows XP...

Just a quickie (just in case no one reads my thread)...

latest test rel. (060613b) with latest HFs for XP (7) with changes I made in my post works 100%.

yup, same result here...

Congrats, Tomcat! You only needed a few hours of work this time !

All right, I understand.

A new final is in the works. At this point, I don't intend to add more functionality except maybe a [FileFlags] section for Windows 2000.

To be checked:
- all new hotfixes should be supported on Win2K SP4, WinXP SP1, WinXP SP2 and Win2K3 SP1
- KB911562 for MDAC 2.8 SP1
- Win2K .ART extension support
- USP5

Any volunteers?

don't mention it ... just trying to give it back to the others who might have the same issues like mine ... besides, everybody here is so helpful that i'd love to be 1 too in my own little ways

glentium .. it is great to have a "Pinoy" too here in HFSLIP ... though i know that you've been here quite longer than i have been but perhaps you opted to just be silent ... as for me, i've been bugging these guys for quite sometime now ... my apologies

i understand the concept better now ... i remember reading in the instructions before that only i386 directory is a must for HFSLIPping ... although w/ this RC request i placed forward to the accomodating moderators would require WINNTUPG dir to work ... and yes ... clarifying the said issue via "Special Features" link would truly be enlightening (especially to those who miss out on going through the entire thread )

awaiting for the new final ... test release or final ... heck, doesn't matter to me ... been using whichever is available anyway
as for any volunteer ... i've been raising my arm here for XP SP2 ... well, testing that is ... as i've said i'll be glad to be of little assistance ... as for dotnet2, it shouldn't pose any headache for us anymore ...

thanks!

I try the HFSLIP_60614b.CMD version and i have problems integrating .NET 2.0 and .NET 1.1

I need a little help!! Read my post with the explanation of the problems here:
Install Problem with Net Framework v2 and Language Pack

I´m using XP Professional + SP2 in Spanish.

Thanks in advance.
zartrix

Just a few hours left : biology and german. And also post-exams+end-of-the-year "meal" : ice cream, ice cream, macarons, macarons, sweets, ice cream.

All HFs good (except kb887472 STILL [no biggie]), no more file copy errors in XP. I will be attempting slipping .net 2 on XP momentarily. Is there some kind of test for 1.1 and 2.0 to validate functionality?

hi NtegrA!
the simplest would probably be to check their presence via Add/Remove programs ... those 2 should be there ...
further you may try to use some .msis & .exes to see if they do not prompt for the dotnets ...

OK so...

using both RyanVM supplied .nets (2.0[dotnet2.exe] in HF, 1.1[netfxsp1.exe] in HFSVPK). in Add/Remove I see 2.0 but not 1.1. MSBSA does not complain about missing hotfixes (any that matter). I can't get to WU cuz I can't activate my build in VM (OEM source).

Is there certain naming convention for 1.1 executable?
Anything out there that I can test against both(known progs that will complain)?

EDIT: OOOPS, reading other post noticed that I am using wrong folder for 1.1 Sorry, ignore this post until I try again.

The name doesn't matter. I use RVM's installer renamed to DNF11.exe.

he! he!
HFSLIP now allows for dotnet to be placed in HF dir ...
if switchless, still in the HFSVCPACK ...

That was ditched 9 minutes before you wrote your post, I'm afraid.

I might consider putting the functionality back if it's really necessary but only in the HFSPLUG1.CMD file.

heh. Of course I should have hung out just a BIT longer before starting over as I see you released a new version on me (My build is at the end of course [.net 2.0 just finished])

Also, would you care to explain why I gained 6-10 mins on slipping? Used to take 22-26 mins (60613b), now 15-16 mins(60614d+). (Does it sound like I'm complaining?)

Don't know... You experienced DST or something?


It's probably the Service Pack...

BTW... Did you install that .NET 2.0 build or not?

i think this is basically because of the add-ons we are using ... dotnet 1.1 & 2 for instance takes a considerable amount of time ...

mine used to be about 30+ mins ... now i'm going 40+ mins (of course + the add-ons)

no, my time is going in the other direction. My slipstream process is getting faster not slower. This one clocked in at 14:59 mins. Mind you other than HFs I'm only doing things from Tomcat's list, all apps that I could be slipping (acroreader, java, office, windvd, notes, etc...) I'm installing via batch during first logon from network share.

@Tomcat - SP made no diff in time. 2.0 yes using 060614d. Attempting right now with 060615a. Where I am now is add/remove shows 2.0 but not 1.1. MSBSA2 doesn't complain. Could 1.1 be installed but not listed? Does it matter what order they are installed in? I noticed with 060615a in svcpack.inf order is dotnet2 then netfxsp1. I am going to manually rearrange and try both ways.

I think that might be a problem. But it worked for me on Win2K...

ha! ha!
let me recover from this shame very quickly ...
i'm merely sharing that mine has gone up!

Sorry it took so long. Passed out for a bit there (YAWN)...Anyways, I tried both ways. If dotnet2 is first, 1.1 does not show in Add/Remove. Other way around, everything looks cool. Still is there a way to test for 1.1?

If you go to WINNT\Microsoft.NET\Framework or WINDOWS\Microsoft.NET\Framework, do you see a subfolder called v1.1.4322 or just v2.0.50727? Don't mind the folder for 1.0...

I already suspected that the order might be playing a role so removed the extra .NET 2.0 handling from the latest releases again. For that work, HFSLIP would have to take into account the inclusion of .NET 1.1 too which means a heck of a lot more code (to exclude it from being parsed by other sections, etc).

Here's two options for you (all from HFSVCPACK)...

Option 1:

1DOTNET1.EXE (your silent .NET 1.1 installer)
2DOTNET1SP1.EXE (your silent .NET 1.1 SP1 installer)
3DOTNET1up.EXE (your silent KB886903 installer)
4DOTNET1lng.EXE (your silent .NET 1.1 langpack)
5DOTNET2.EXE (Aserone's silent .NET 2.0 installer)
6DOTNET2lng.EXE (your silent .NET 2.0 langpack)

Option 2:

DOTNET11.EXE (silent .NET 1.1 installer including SP1, KB886903 and langpack)
DOTNET20.EXE (silent .NET 2.0 installer including langpack + hack for installation at T-13)

You can make these two installers with the "beta" of MultiCompiler 2. Have you tried it already?

To all (not Tomcat) - What is the big h@rdon about DOTNETx? I mean, IMHO, it's not really required for the OS. It's a program. Is MS Office a operating system an OS requirement? No. Why not just use your own crafted post-windows installers for installing dotnet (and any other programs you want to install)? My PC runs GREAT without dotnet.

Um, technically, the actual variable names are not case-sensitive. I tested this the other day.

Not a biggie to me, just figured I'd give it a try. I had always been installing 1.1 after first install along with other base apps. BUT, I kinda consider dotnet a part of the OS as other apps rely on it. Same with say, JAVA (even though I install this at first reboot as well). I only load JAVA because IE requires (kinda) it.


Just compared both runs. They each have both folders populated. Any further test? (I think I need a 1.1 specific app?)

Is this built into the 060616a?

No (sorry)

HFSLIP has always supported silent installers from HFSVCPACK (formerly HFSVPK).

BTW... I just updated MultiCompiler 2. If both .NET 1.1 and .NET 2.0 are detected, it asks you whether you want to merge it all into one file...

I just meant because of the filenames. Should naming a certain way order the install? I think I will just continue installing at first reboot. That worked for my situation.

HFSLIP just copies the files from HFSVCPACK into SOURCESS\I386\SVCPACK and echoes the executable names into SVCPACK.INF alphabetically. So if the order is important change the name(s) and you're good to go. Looking at your other thread, you're already doing that.

DUH, I wasn't paying attention Dosnet2 before netfxsp1. I really need some sleep!!!

Whoops... It just occured to me that I'm mixing you up with someone else... There is no "other thread" from you and I didn't ask you to try MC2 before...

Looks like I'm the one who needs some sleep, hehe...

hi!
just wanted to share ... i saw these ran through my screen ...

SBP-2 drive stops responding when you try to write data in Windows XP
WindowsXP-KB885464-x86-ENU.EXE
TEMP\SP2QFE\ohci1394.sys
1 File(s) copied
0 File(s) copied

Initialization phase of a Setup program may take longer than expected to complete in Windows XP
WindowsXP-KB885898-x86-ENU.EXE
TEMP\SP2QFE\msi.dll
TEMP\SP2QFE\msiexec.exe
2 File(s) copied
0 File(s) copied

A component that runs in the same process as the Windows Time service is stopped or is disabled unexpectedly in Windows XP
WindowsXP-KB888432-x86-ENU.EXE
TEMP\SP2QFE\w32time.dll
1 File(s) copied
0 File(s) copied

MS05-020: Cumulative security update for Internet Explorer
WindowsXP-KB890923-x86-ENU.exe
TEMP\SP2GDR\browseui.dll
TEMP\SP2GDR\cdfview.dll
TEMP\SP2GDR\iepeers.dll
TEMP\SP2GDR\inseng.dll
TEMP\SP2GDR\mshtml.dll
TEMP\SP2GDR\msrating.dll
TEMP\SP2GDR\shdocvw.dll
TEMP\SP2GDR\shlwapi.dll
TEMP\SP2GDR\urlmon.dll
TEMP\SP2GDR\wininet.dll
10 File(s) copied
0 File(s) copied

Packet-writing programs for optical media recording devices run slower than expected on Windows XP Service Pack 2-based computers
WindowsXP-KB891070-x86-ENU.EXE
TEMP\SP2QFE\ntkrnlmp.exe
TEMP\SP2QFE\ntkrnlpa.exe
TEMP\SP2QFE\ntkrpamp.exe
TEMP\SP2QFE\ntoskrnl.exe
4 File(s) copied
0 File(s) copied

FIX: You may receive a "Page cannot be displayed" error message when you click a hyperlink to view a Microsoft Office document in Internet Explorer 6 Service Pack 1
WindowsXP-KB892056-x86-ENU.EXE
TEMP\SP2QFE\mshtml.dll
TEMP\SP2QFE\urlmon.dll
2 File(s) copied
0 File(s) copied

FIX: You may receive a "This operation has been canceled due to restrictions in effect on this computer" error message when you try to open the Internet Options dialog box in Internet Explorer 6
WindowsXP-KB894179-x86-ENU.EXE
TEMP\SP2QFE\shdocvw.dll
1 File(s) copied
0 File(s) copied

Software update 898461 installs a permanent copy of the Package Installer for Windows version 6.1.22.4
WindowsXP-KB898461-x86-ENU.exe
0 File(s) copied

The embedded resource version of the LIP MUI files is incorrect in Windows XP Starter Edition
WindowsXP-KB913808-x86-ENU.exe
0 File(s) copied

i may have to take these out or would this be script related issue?

incidentally, i noticed that 60615a was a bit smaller in file size (144 as compared to 145 in earlier vers) ... moreover, the slipstreaming time went down to 30-31mins again for me ... just like what i mentioned in my embarrassing post earlier, it used to last as long as 40+ mins ... considering i even added the newer updates using 60615a ...

i just hope this post is not yet too late knowing that 60616a is already out ... (which i already downloaded)

thanks!

Huh, what? I've never seen this before....

Question:
Is it possible to add a feature in HFSLIP to ignore MAKENOISO in HFANSWER.INI if in MAKEISO mode?

The "MAKENOISO" feature was introduced in 13a and your suggestion (Super-Magician's suggestion, actually) was implemented in 13b... So no need to implement it again...

We're already up to 60616b now .

Oh, I'm still using 60612a... then the next time I logged in it's already 60616b! But I already saw the MAKENOISO feature in 60612a...

Thanks for that feature anyway. Very much appreciated.

60617b is "the RC", people. If no new problems have been introduced over 60528, this will be released as the new final on Sunday evening.

So I tried 60617b with INSTALLRC=1 and WINNTUPG folder present: an error message popped out at T-13 telling me that NETMAP.INF was not found, so I had to press OK, then another dialog box saying the "Windows XP Setup cannot continue" (something like that) and I had to click 'Finished...'

hi TC!
these were basically like what i posted before ... pls don't mind the headers (i just inserted those on top of the real messages) ... it's the same for the others ...
my apologies for the confusion ...

A component that runs in the same process as the Windows Time service is stopped or is disabled unexpectedly in Windows XP ---> this is what i inserted
WindowsXP-KB888432-x86-ENU.EXE ---> HFSLIP shows the following lines
TEMP\SP2QFE\w32time.dll
1 File(s) copied
0 File(s) copied

Super-Magician ... i already downloaded the latest

thanks!

@Kiki: I already explained where the "0 File(s) copied" comes from....


The only reasons I can think of:
1) You don't have NETMAP.INF in WINNTUPG
2) WINNTUPG is not in the right place (it should be in I386)
3) You have an I386 folder in the root of a local partition (eg, C:\), and there is no NETMAP.INF in there

HFSLIP instructs Windows to execute the standard installation command, but with the /unattend switch added to it to make it silent.

T - Please allow a few more days for others to test and report back. Sit back, don't code, relax and wait for the population's feedback. Once all is fine, then go for it.

French XP SP1a reports, Sir!

This does the trick:




Next:



Solution:





This one is a problem:





And now files greater than expected:

@Camarade_Tux:

#1 is odd. HFSLIP copies the installation INF from the hotfix package, and it contains the registry entry you need. So it's strange that the key isn't created. This is the relevant line:

HKLM,"Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProtocolDefaults","shell",0x10001,0x0

It could be that the "0x0" makes it fail but I'm not sure.


#2 is a problem. This hotfix doesn't contain any updated binaries and the installation INF has a name (update_SP1QFE.inf) which is normally associated with an installation folder called SP1QFE which isn't present. These hotfixes are given special treatment but for some reason this fails. The installation INF (which contains the necessary info) is not handled (or at least doesn't end up in SOURCESS\I386). I also see this installation INF is doing some special stuff which is beyond the scope of a "default" install. I'm going to have it installed from SVCPACK but not before I found out why the INF is not processed for such hotfixes.


I still need to check #3.

@Camarade_Tux:

#1... The key is being inserted if you use HFSLIP 60618a. I'm still wondering why it fails. Do you have this key at least:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB839645

That's the other reg key created by the hotfix.


#2... Heh. It looks like HFSLIP already puts this hotfix in SVCPACK. Where are my thoughts?
HFSLIP lets this hotfix install itself so there's nothing that can be done (at least not easily). If I just insert a reg key from HFSLIPWU.INF it will be overwritten when the hotfix installs. It's strange that HFNetChk complains about something that the hotfix does...

#3... Fixed. The IE6 cumulative updates for XPSP1 need the RTMQFE binary versions. I forgot to update HFSLIP for the new cumulative update.

From the browseui.dll issue, it appears browseui.dll wouldn't copy over from the hotfix to the sourcess folder.

the_guy