Welcome to Windows XP Service Pack 4

[bphlpt]

@ianymaty, the problem of not being able to integrate any SP in XP while on a host system OS of Win7 has always been a no-no either using the /integrate switch or using RVMi or nLite. So the fact that it did not work for you in some of those modes is not a bug. You will find the same results just trying to integrate SP3 in XP RTM. I'm very surprised that you got it to work in nLite at all and I would not count on that ever happening again, even if it might. Again, the fact that you need to do the SP4 integration while on an XP system, either a VM or real metal, is expected behavior, is not a bug, and is completely correct, even if it is annoying if you have a Win7 system.

Cheers and Regards

[ianymaty]

Thanks, bphlpt for explaining. I didn't say it was a bug or something, just feedback with my experience. It's true I did not do any slipstream of any SP on Win 7, just Update Packs of OnePiece and all the needed tweeks with nLite and RVMi. Actualy my favorite way was to integrate UpdatePack and Add-Ons with RVMi than unattend and tweeks with nLite, add DriverPacks than build ISO with RVMi. All this was done on Win 7 countless times, barely had some problems and I blame mostly the incompatible Drivers. Lately I only integrated MassStorage, Chipset, LAN and WLAN and had no problems to remember. But as I found this SP4 is NOT compatible with RVMi even on XP. Maybe RVMi needs some adjutments as it's old now.

@harkaz, seems that the Event ID 60055 is inconsistent.

The source is the same on both installs, nLite integrated.

Now the ISO install in VM setuperr is clean and also Event Viewer show no error.

The USB install on live has this time setuperr and Event Viewer showing problem.

Maybe my mind is playing up with all those installs. Anyway I attach the files for you from both installs.

http://www.datafilehost.com/d/932153ef

[Anthony21]

So far no luck with Vegas, until my nlight doesn't want to see my disk to erase or make ISO to disk is disabled other than my rom won't see what's on it either, I accidentally erased my windows 8 (thk god not much of importance was on 120gb SSD) (was only activated till August 2014) so I can't test it out on a VMware anytime soon.

Maybe one of u guys can test it out to install sonyVegas 10e to one of ur beta test in VMware to c if u get the same problem.

[ianymaty]

@Anthony21

What was your problem with Vegas? Is it at install or when you try to run it?

Here is the proof it works in VM. http://s30.postimg.org/5c0tmk7sh/vegas.png

[Anthony21]

Ok, I'm trying to run it after installing it, is when I run into an error.

Was plan'n on redueing 3pcs that are old to have this program.

How did u do ur upgrade install? From sp2?

[ianymaty]

It's original SP3 - en_windows_xp_professional_with_service_pack_3_x86_cd_vl_x14-73974.iso

[harkaz]

I have just tested the WinNTSetup on real hardware with the latest internal SP4 build slpistreamed in Windows XP SP0 Home Edition OEM media. No problems were found in setuperr.log. No driverpacks were used.

Currently working on ianymaty's issue.

[adric]

Patch Tuesday (Jun 11, 2014) WEPOS and POSReady 2009

KB2957689 MS14-035 (IE8 Cumulative) replaces KB2953522 and KB2936068
KB2939576 MS14-033 replaces KB2916036
KB2957503 MS14-036 replaces KB2834886
KB2957509 MS14-036 replaces KB2850869

[harkaz]

I won't include the June updates in SP4, although the IE8 cumulative update is huge.

[darkrats]

Your IE8 ported update (POS to XP) was very much appreciated.
Are you going to be doing the same for KB2957689 MS14-035 (IE8 Cumulative)?

I was successful in updating IE8 on my system despite problems with Symantec,
and I am very interested in seeing if I can do the same with the June 10th update.

Thanks.

[Atari800xl]

harkaz, thank you very much for testing with WinNTSetup, that is really an "extra" service you're providing!!
So did you change anything to fix the issues, or did you not experience them at all? I would be interested to learn why the issues occurred in the first place.

Adric, could you please tell me how I can tell which previous updates are replaced by new ones? As I understand from your list one of last month's updates is now replaced already, so I can remove it from my nLite updates folder. So thanks for mentioning that, I would really like to know how I can check that in the future.

[adric]

Determining superseded updates is a PITA. There is no good way that I know of. The first place I look is in the KBs, although Ms doesn't always get it right or misses mentioning if superseded.

The 2nd thing I do is hfextract the new fixes and check the pertinent file(s) for their version numbers and see if I have the same file(s) installed; all with the same/older version numbers. If all files meet that criteria, then they are superseded. The next step is to determine what fix the superseded files belong to. Sometimes Google can help. It's time consuming so if anyone has a more efficient method, please tell me about it.

Also, 5eraph's changelog helps too.

Al

[Atari800xl]

Thanks Adric, really appreciate your explanation.
So it's really as complicated as I thought it might be...
So thanks again for mentioning the superseded ones, you're saving us a lot of trouble! Thanks to 5eraph as well!

[5eraph]

You're welcome.

To determine supersedence, it helps to have a good list of updates and their files to start. For XPx86 you can find such lists in user_hidden's or OnePiece's update packs (in qfeUpPck.inf or OPMWXPUP.inf, respectively). Once you have a good starting reference it's just a matter of unpacking the newly released updates and matching files and versions in the aforementioned INFs.

Just remember that my 64-bit changelogs don't always match up with the 32-bit counterparts (user_hidden's and OnePiece's) due to differences between XPx86 and Win2003 (which XPx64 is based upon).

Also be aware that some packages only update subsets of files from other packages, and those subsets may be updated at different times. When this happens, my changelogs only reflect the latest subset that completely supersedes a larger update. For example, my changelog shows KB2893294 supersedes KB2653956:

[2013/12/10 23:40 UTC] - 2013-12_1

• High priority update KB2893294 replaced high priority update KB2653956.

But that's not the whole story. KB2749655 must also be installed for that supersedence to take place:

[2012/10/10 10:20 UTC] - 2012-10_1

• High priority update KB2749655 added.

Deep file tracking of this sort can get complicated when one package updates files from two or more others incompletely. This is the main reason I won't do it except by request, and never in my changelogs. It takes a long time.

[harkaz]

@Atari800xl It's not an extra service, it is a required fix

To be specific, I changed many things in this build, as far as CD-ROM installation is concerned. I added missing references in dosnet.inf, removed double references, cleaned up missing files/ redundant references from all dosnet/layout/txtsetup.sif files.
DXRedist CD2 files are now copied in GUI-mode setup (you can't remove it however) and includes WinRMC as an optional component, enabled and installed by default in GUI-mode setup. This was done to ensure a smooth winnt32-based install.

Now, for the WinNTSetup, an additional step was required: I digitally signed every single file in the SP4 package, including even the WIN51IC.SP4 and WIN51IP.SP4 tag files. In the previous build, txtmode setup files were not digitally signed, and this caused a file copy failure.

@darkrats Although it's not really necessary (due to the POSReady registry tweak) I will upload them soon.

[darkrats]

Thanks, harkaz.

I am playing around with the registry tweak.
So far it gives me a BSOD, but I'm guessing that, once again, it's Symantec that causing the problem.
I just have to find out at what point it happens.

I change the registry, and then the moment I turn on Windows Update (which is usually off) I get the BSOD (memory dump & disk check) and then it reboots.
Then (likely because I still had Windows Update on) it goes through the cycle again. Luckily I can easily restore my drive from an external source, so I can try again.

For now, I look forward to your uploads.
Being able to get continued security fixes for my trusty (although old, and sometimes broken) Internet Explorer 8 makes me very happy!

[harkaz]

Here you go:

POSReady 2009 June 2014 ported-to-XP installers:

https://drive.google.com/folderview?id= ... =drive_web

[darkrats]

I hope you can be persuaded to upload the ported-to-XP installers as they are released each month.
Not sure about other users, but my first choice would be to get updates without using Windows Updater, so thanks again!

[bphlpt]

I would like to see them added to SP4 at least every 3-6 months.

Cheers and Regards

[harkaz]

@bphlpt This is not easy at all. The main problem is removing superseded update references without breaking something. I can't say anything at the moment.

Beta 3 will be uploaded very soon.

[ltsnow]

Here you go:

POSReady 2009 June 2014 ported-to-XP installers:

https://drive.google.com/folderview?id= ... =drive_web

Thanks so much harkaz for posting these.

[bphlpt]

@bphlpt This is not easy at all. The main problem is removing superseded update references without breaking something. I can't say anything at the moment.

Of course, I understand. It was just wishful thinking. Maybe someone can come up with an update pack specifically designed for use with SP4 which can be updated monthly with any new updates/hotfixes and anything that was not appropriate to be included in SP4 for whatever reason. Just a thought.

Cheers and Regards

[harkaz]

Windows XP SP4 Beta 3 is ready.

Release highlights:

- Improved Windows XP SP4 live installation in some scenarios (updated mso.dll file, filelist.xml improved, WU may not register properly, the spupdsvc.inf is not always deleted in a second, third installation of SP4).
- Improved Windows XP SP4 CD-ROM installation: Changed swflash registration to prevent some setuperr.log errors, digitally signed all files, updated driver.cab with usbd.sys and other files, created a WRMC OC for Windows Rights Management Client, tested winnt32 installations, tested WINNTSetup tool, added missing references and removed double ones from dosnet/layout/txtsetup files.

I will start writing the documentation right away. I want to release an RC, or even better, a final build by the end of the next week.

Beta 3 will be available soon enough. Stay tuned.

Name: WindowsXP-USP4-Beta3-x86-ENU.exe
Size: 827 MB (867240652 bytes)
MD5: 07C96E797AD0D082D0876D712EFAB0D0
Date/Time Stamp: 11 Jun 2014 17:00 (UTC)

[darkrats]

Following the same procedure as last month (disabled completely all Symantec products and associated non-plug&play drivers) the IE8 update installed perfectly.
Rebooted to start Symantec and its drivers, and now my IE8 on XP has the latest security patch. I don't think it can be said enough, but thanks to harkaz for the ported updates!

[harkaz]

Beta 3 is now available

Download Link: https://drive.google.com/file/d/0B7k-l_ ... sp=sharing

See post above for release details.

[PJAmerica]

I would just like to take the time to say thank you harkaz. I and many others deeply appreciate all of your work and those who inspired and contributed to it being all it can be. Your time is valuable so know I appreciate it very much.

Ps. I hope one day you resume your Windows 7 SP2 work as well. No clue where your site for that is now as they all seem to be taken down but I am glad you found a home here with everyone for this project.

[Atari800xl]

Could hardly wait to try integrating the new beta in my XPSP3 source, then install with WinNTSetup. SUCCESS!!! Amazing work Harkaz!!...
(more later).

[ianymaty]

CMD and nLite slip give this in VM install from ISO.



Nothing in setuperr.log and no errors in in Event Viewer. The new POSReady updates show up and ready for install.

Apart from the screen the rest looks normal.

I'm not testing this time the USB install due to that screen.

I did also RVMi slip but still smaller image so I quit testing it on install.

Here are both setupapi.log files http://www.datafilehost.com/d/fa181dfc

[harkaz]

@ianymaty The command that causes this issue is:

%systemroot%\System32\rundll32.exe setupapi.dll,InstallHinfSection SWFlashUpdateServices 132 %systemroot%\inf\SWFlash.inf

First of all, tell me if this command completes successfully when you execute it manually.

[Atari800xl]

ianymaty, why don't you use the standard /integrate switch?

Harkaz, I now also ran my "Postinstall" (just a little autoit tool that installs all my [little] apps, tools, settings, etc.) so I'm already testing all my regular stuff on the new SP4 system, in the exact same configuration as I normally use on XP. Everything seems fine, thanks again!

Of course now the next question for me is: which one's "better", XP with OnePiece pack (quite easy to rebuild every month, localized, with latest POSReady updates, compact) or SP4-based stuff.

I guess time will tell, I just find it amazing that you've created this "alternative" for us, using SP4 with (or without) modified POSReady updates certainly is a nice way of keeping XP alive for a while longer.

Now I'm looking forward to the documentation (localization?), and anything else you can throw at us...

I have one more question for everybody here: I guess there's no way that a SP4-integrated XP source can be used (as a "clean source") for RyanIntegrator or nLite, now can it?!

[ianymaty]

No error comes up when I run it from CMD window or from Run box.

[harkaz]

OK, I will add the Adobe Flash player update service manually with addreg.

[ianymaty]

ianymaty, why don't you use the standard /integrate switch?

...

I have one more question for everybody here: I guess there's no way that a SP4-integrated XP source can be used (as a "clean source") for RyanIntegrator or nLite, now can it?!

I am using /integrate just made it a .bat for easy to run. How do you use the /integrate? Is there an easier way other than a .cmd or .bat file to run this?

...

It should work as a clean source. At least that is the intention.
nLite presents it as - Windows XP Professional (Media Center v4.0)
RVMi presents it as - English - Windows XP Professional x86 - Corporate SP4

[Atari800xl]

It should work as a clean source. At least that is the intention.
nLite presents it as - Windows XP Professional (Media Center v4.0)
RVMi presents it as - English - Windows XP Professional x86 - Corporate SP4

Sounds good, will test that tomorrow (eg. add unedited POSReady hotfixes with nLite).

[adric]

Sounds good, will test that tomorrow (eg. add unedited POSReady hotfixes with nLite).

I've never used NLite before. Can it easily be used to integrate the POSready 2009 updates with the output from RVMIi after integrating a user_hidden updatepack + addons?

Al

[bphlpt]

I have one more question for everybody here: I guess there's no way that a SP4-integrated XP source can be used (as a "clean source") for RyanIntegrator or nLite, now can it?!

It should work as a clean source. At least that is the intention.

That is my understanding as well.

Of course now the next question for me is: which one's "better", XP with OnePiece pack (quite easy to rebuild every month, localized, with latest POSReady updates, compact) or SP4-based stuff?

After SP4 has a bit more field use, I'm hoping that someone creates a OnePiece type update pack specifically for SP4.

Cheers and Regards

[Atari800xl]

I've never used NLite before. Can it easily be used to integrate the POSready 2009 updates with the output from RVMIi after integrating a user_hidden updatepack + addons?
Al

I am by no means an expert on this, but this has worked for me until now:
(1) Use RVMi for updatepacks/ addon packs (2) Then use nLite for Classic setup screens, remove help system, add hotfixes (in this case: POSReady updates). Of course these settings are just an example, just to show I don't do a whole lot of tweaks, because I don't want to "break" stuff, specially for install with WinNTSetup, etc. (3) Use DPBase to add (in my case) SATA drivers (4) Build iso (add hosts file, winnt.sif, remove LANG folder.
So I would say: Yes, nLite should work in your example.

It should work as a clean source. At least that is the intention.

That is my understanding as well.

Well, my first quick test, adding the June POSReady updates to the clean XPSP4 source didn't work. I will try again soon.

[=[FEAR]=JIGSAW]

Once again all I can say is : "THANKS"

[harkaz]

@Atari800xl A workaround for this is to temporarily rename the WIN51IC.SP4 or WIN51IP.SP4 tag file to WIN51IC.SP3 or WIN51IP.SP3, respectively.

Then integrate updates with nLite.

After that rename these files back to original.

[Atari800xl]

harkaz, that seemed to work perfectly, I was very excited about it actually, this way I could use the "integrated SP4 source" as the new base for monthly "integration" runs of the POSready updates with nLite.
Everything went smoothly, until this "old friend" at the end of gui setup:
"C:\WINDOWS\system32\grpconv.exe - Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item."

If there's no solution for this particular issue, please forget about it, but it looked like a nice solution to create fully a fully updated XP source (maybe bphlpt would have liked it as well...), like I use with the OnePiece pack.

[harkaz]

@Atari800xl Unfortunately, fixing that is not so easy, because you need tor re-sign the files nLite modded.

Don't use WinNTSetup with true-mode integration of updates. Try using it with SVCPACK integration of updates, if you want to stay updated. And try to do this manually.

[bphlpt]

@Atari800xl, Do I understand this sequence correctly? If you integrate SP4 manually to your SP3(?) source and change the name of the tags harkaz suggested, use nLite to add a few updates and make a very few minor tweaks and make an ISO, then use WinNTSetup to try and install you get the single grpconv error. But if you take the same SP3(?) source, use nLite to add the OnePiece update pack and a few updates and make a very few minor tweaks and make an ISO, then use WinNTSetup to try and install you don't get any error at all. Correct? So in one case SP4 is used and the other the OnePiece pack is used, while in both cases nLite is used to add the same few updates and make a very few minor tweaks and make an ISO. Correct? harkaz, if this is true, then I can't see how that either nLite or WinNTSetup is causing the grpconv error, unless I'm missing something. Wouldn't nLite be modding the same files in either case? Or is this the case of one of the small differences of what SP4 vs OnePiece's pack includes?

Cheers and Regards

[poolside]

This question may have been already asked before:

When I try to install SP4, I get the message "Failed to install catalog files." and all the progress is rolled back.

Any idea how to fix this?

[Atari800xl]

bphlpt: First of all, I really like your very clear and precise questions/ contributions.
Yes, you understand the sequence correctly. I will do one more test right now, with a slight variation on the procedure, but I believe the last error/ warning I mentioned has to do with signing of the files (as harkaz mentioned).
As you said, there must be some fundamental difference in how SP4 and OnePiece treat the files, but I guess we'll have to accept that. I do like the SP4 project, but the way it looks right now I'll probably keep my "OnePiece final with monthly POS updates added with nLite" method for now.
Still, SP4 is a very nice alternative to have, I'm absolutely sure it will come in very handy sometime. Also, it's a lot of fun testing this stuff.

EDIT: bphlpt: I read your message again, and wanted to add this: harkaz clearly said that nLite modding the files is the problem, it throws off the signing of the files, which is a problem in SP4, not with OnePiece packs (as far as I can tell).

[harkaz]

@poolside Can you send me the C:\WINDOWS\svcpack.log file? Which is your XP SKU (Home/Professional/ Home N, etc.)?

UPDATE: This issue is probably caused because there are too many catalog files to archive. Probably I will remove the KBxxxxxx.CAT files from the archive.

@Atari800XL I think Onepiece has changed some options in dosnet/txtsetup.sif file regarding moving of some files in winnt-based setup. Windows XP SP4 uses the original settings.

[bphlpt]

Ataeri800xl, You are correct that I think that it is very important to be precise in order to see where a problem lies, especially since there are so many things going on that might be interacting in some way in order to cause the problem. Yes, harkaz said that nLite modding the files is the problem, but I'm trying to help figure out not only which files are being modded, but at which step which hopefully will point to why and so hopefully help point to a solution. In other words, this is the way I understand your workflow which works successfully for you: (The first couple of steps I'm guessing)

1.) Start with XP RTM (?)
2.) Integrate SP3 using /integrate switch (?)
3.) Use RVMi for OP updatepack and addon packs
4.) Use nLite for Classic setup screens, remove help system, tweaks, add hotfixes
5.) Use DPBase to add (in your case) SATA drivers
6.) Add hosts file, winnt.sif, remove LANG folder
7.) Build iso
8.) Install using WinNTSetup
9.) Run "Postinstall" (an AutoIt tool that installs all your [little] apps, tools, settings, etc.)
10.) Check to see if everything is working correctly then backup your system image for recovery purposes. [You didn't say that you did this, but it would be a good practice to be able to get back up and running the quickest if your system ever crashes for any reason ]

NOTE: I just want to say that I completely approve of this type of workflow. You use each of the various tools for the purpose that they are best suited for.

My confusion is that if the above is indeed your successful workflow, then nLite is being used in it. So why is whatever files that nLite is modding not causing you an issue? What files are being modded differently in this case vs when you try to use SP4?

I also assume that in the test that gave you the grpconv error, the only steps you changed in your workflow were:

2a.) Integrate SP3 using /integrate switch (?) [Same as above assuming you have an SP3 source you keep for building your install source every month. If we can get this working you could eliminate this step and integrate SP4 directly to RTM.]
2b.) Integrate SP4 using /integrate switch and temporarily rename the WIN51IC.SP4 or WIN51IP.SP4 tag file to WIN51IC.SP3 or WIN51IP.SP3, respectively.
3.) Use RVMi for addon packs [I don't know if the exact list of addons changes with SP4 vs OP pack]
4.) Use nLite for Classic setup screens, remove help system, tweaks, add hotfixes [I don't know if the exact list of hotfixes changes with SP4 vs OP pack]

Is this correct? If the list of addons and hotfixes you add in steps 3 and 4 are not identical in your SP4 vs the OP pack tests, could you make them identical and rerun the tests? With identical files used, if you still get the grpconv error with SP4 and not with the OP pack, then I'm really confused as to where/how/why nLite is modding a file differently when SP4 is used vs when the OP pack is used. Yet another test that might prove enlightening is if you could use RVMi to add the hotfixes in both the SP4 and OP tests and only use nLite for Classic setup screens, remove help system, and any other tweaks you do. I would think that this would minimize the possible impact of whatever nLite does. (Was there a particular reason you used RVMi for addons and nLite for hotfixes?)

harkaz raised an interesting point:

I think Onepiece has changed some options in dosnet/txtsetup.sif file regarding moving of some files in winnt-based setup. Windows XP SP4 uses the original settings.

Could it be that the particular changes that were made in WinNTSetup to accommodate the OP pack are somehow involved? Just a thought.

You had indicated above that:

Could hardly wait to try integrating the new beta in my XPSP3 source, then install with WinNTSetup. SUCCESS!!! Amazing work Harkaz!!...

but I assume that was without some of the steps in your complete workflow, correct? Like maybe without adding any addons or hotfixes at all?

I, and I assume harkaz, really, really appreciate all the test you have been doing, I'm very glad you enjoy the detective work, though I know it can get very tedious. If this issue can be resolved so that RVMi, nLite, DPBase, and WinNTSetup can all be used successfully with an XP source with SP4, then that will give a lot of flexability to anyone trying to build an XP system in the future. Thanks for all your hard work.

Cheers and Regards

[harkaz]

A thread related to the WinNTSetup issue is this one:

http://www.ryanvm.net/forum/viewtopic.p ... ght=icfgnt

This may help you understand why files signing causes this issue.

EDIT:
In addition, check OP's txtsetup.sif file. It contains these file flags section:

Pay attention to the =16 flags and compare with the thread mentioned above.

Code: Select all

;==OPWXPUP 
[FileFlags]
agt0c0a.dll = 16
agt0c0a.hlp = 16
agt040b.dll = 16
agt040b.hlp = 16
agt040c.dll = 16
agt040c.hlp = 16
agt040d.hlp = 16
agt040e.hlp = 16
agt041d.dll = 16
agt041d.hlp = 16
agt041f.hlp = 16
agt0401.hlp = 16
agt0404.hlp = 16
agt0405.hlp = 16
agt0406.dll = 16
agt0406.hlp = 16
agt0407.dll = 16
agt0407.hlp = 16
agt0408.hlp = 16
agt0409.dll = 16
agt0410.dll = 16
agt0410.hlp = 16
agt0411.hlp = 16
agt0412.hlp = 16
agt0413.dll = 16
agt0413.hlp = 16
agt0414.dll = 16
agt0414.hlp = 16
agt0415.hlp = 16
agt0416.dll = 16
agt0416.hlp = 16
agt0419.hlp = 16
agt0804.hlp = 16
agt0816.dll = 16
agt0816.hlp = 16
arial.ttf = 16
arialbd.ttf = 16
arialbi.ttf = 16
ariali.ttf = 16
ariblk.ttf = 16
AVICAP.DLL = 16
AVIFILE.DLL = 16
bnts.dll = 16
cfgmgr32.dll = 8
cga40woa.fon = 16
cga80woa.fon = 16
cga40850.fon = 16
cga80850.fon = 16
comic.ttf = 16
comicbd.ttf = 16
COMMDLG.DLL = 16
cour.ttf = 16
courbd.ttf = 16
courbi.ttf = 16
coure.fon = 16
courf.fon = 16
couri.ttf = 16
custsat.dll = 16
dosapp.fon = 16
driver.cab = 16
ega40woa.fon = 16
ega80woa.fon = 16
ega40850.fon = 16
ega80850.fon = 16
estre.ttf = 16
framd.ttf = 16
framdit.ttf = 16
gautami.ttf = 16
georgia.ttf = 16
georgiab.ttf = 16
georgiai.ttf = 16
georgiaz.ttf = 16
hal.dll = 12
halmps.dll = 8
halsp.dll = 8
impact.ttf = 16
kartika.ttf = 16
kbdclass.sys = 16
kernel32.dll = 1
KEYBOARD.DRV = 16
l_10646.ttf = 16
latha.ttf = 16
lsans.ttf = 16
lsansd.ttf = 16
lsansdi.ttf = 16
lsansi.ttf = 16
lucon.ttf = 16
LZEXPAND.DLL = 16
mangal.ttf = 16
marlett.ttf = 16
mchgrcoi.dll = 16
MCIAVI.DRV = 16
MCISEQ.DRV = 16
MCIWAVE.DRV = 16
micross.ttf = 16
MMSYSTEM.DLL = 16
MMTASK.TSK = 16
modern.fon = 16
mouclass.sys = 16
MOUSE.DRV = 16
MSVIDEO.DLL = 16
mvboli.ttf = 16
napprov.mof = 16
napschem.mof = 16
nhelper.exe = 16
nlite.inf = 16
NOTEPAD.EXE = 16
ntdll.dll = 1
ntldr = 2
OLECLI.DLL = 16
OLESVR.DLL = 16
pala.ttf = 16
palab.ttf = 16
palabi.ttf = 16
palai.ttf = 16
raavi.ttf = 16
roman.fon = 16
rsop.mfl = 16
rsop.mof = 16
sapicpl.hlp = 16
script.fon = 16
serife.fon = 16
seriff.fon = 16
setupapi.dll = 8
SHELL.DLL = 16
shruti.ttf = 16
smalle.fon = 16
sniffpol.dll = 16
SOUND.DRV = 16
sp3.cab = 16
speech.chm = 16
SPOOLSS.DLL = 16
SPOOLSV.EXE = 16
ssdpapi.dll = 16
ssdpsrv.dll = 16
sserife.fon = 16
sseriff.fon = 16
sstub.dll = 16
sylfaen.ttf = 16
symbol.ttf = 16
SYSTEM.DRV = 16
tahoma.ttf = 16
tahomabd.ttf = 16
TAPI.DLL = 16
TASKMAN.EXE = 16
TIMER.DRV = 16
times.ttf = 16
timesbd.ttf = 16
timesbi.ttf = 16
timesi.ttf = 16
trebuc.ttf = 16
trebucbd.ttf = 16
trebucbi.ttf = 16
trebucit.ttf = 16
tshoot.dll = 16
tunga.ttf = 16
udhisapi.dll = 16
umpnpmgr.dll = 8
upnp.dll = 16
upnpcont.exe = 16
upnphost.dll = 16
VER.DLL = 16
verdana.ttf = 16
verdanab.ttf = 16
verdanai.ttf = 16
verdanaz.ttf = 16
vga850.fon = 16
VGA.DRV = 16
vgafix.fon = 16
vgaoem.fon = 16
vgasys.fon = 16
vrinda.ttf = 16
webdings.ttf = 16
WFWNET.DRV = 16
win32k.sys = 1
wingding.ttf = 16
WINSPOOL.DRV = 16
wscenter.mof = 16

That's probably done by nLite automatically during update pack integration

Now compare with Windows XP SP4 Beta 3:

Code: Select all

 ;==Windows XP SP4
[FileFlags]
halmps.dll = 8
halsp.dll = 8
kernel32.dll = 1
ntdll.dll = 1
win32k.sys = 1
ntldr = 2
cfgmgr32.dll = 8
setupapi.dll = 8
umpnpmgr.dll = 8
hal.dll = 12
kbdclass.sys = 16
mouclass.sys = 16
driver.cab = 16
sp3.cab = 16
custsat.dll = 16
NOTEPAD.EXE  = 16
TASKMAN.EXE  = 16
AVICAP.DLL   = 16
AVIFILE.DLL  = 16
COMMDLG.DLL  = 16
LZEXPAND.DLL = 16
KEYBOARD.DRV = 16
MCIAVI.DRV   = 16
MCISEQ.DRV   = 16
MCIWAVE.DRV  = 16
MMSYSTEM.DLL = 16
MMTASK.TSK   = 16
MOUSE.DRV    = 16
MSVIDEO.DLL  = 16
OLECLI.DLL   = 16
OLESVR.DLL   = 16
SHELL.DLL    = 16
SOUND.DRV    = 16
SYSTEM.DRV   = 16
TAPI.DLL     = 16
TIMER.DRV    = 16
VER.DLL      = 16
VGA.DRV      = 16
WFWNET.DRV   = 16
WINSPOOL.DRV = 16
SPOOLSV.EXE  = 16
SPOOLSS.DLL  = 16

[bphlpt]

I'm not saying that file signing is not the issue, I just don't see why it doesn't seem to effect Atari800xl when he uses the OP pack, but it does when he uses SP4. If nLite is used for both SP4 and OP pack builds, it would seem that the file signing issue would be a factor in either case, unless I'm missing something.

EDIT: I posted while you were editing. I'll go read and see if I can understand. It would be nice to resolve this.

Cheers and Regards

[harkaz]

@bphlpt I have modified the post: the reason is those differences in FileFlags section.

They are added during update pack integration which is done by nLite itself (Windows XP SP4 slipstream is merely file copy - nLIte does nothing).

[harkaz]

I will not modify the txtsetup.sif in SP4 package, because these are the Microsoft defaults. However, it's easy to create an addon to integrate the additional file flags in txtsetup.sif of a SP4 slipstreamed disk. This should enable WinNTSetup installation.