Onepiece XP Post-SP3 AIO Update Pack FINAL

[OnePiece Alb]

can you make us a German one too?

http://www.ryanvm.net/forum/viewtopic.p ... 276#133276
http://www.wincert.net/forum/topic/5143 ... /?p=100701

Box - Onepiece's INTL Update List

MixtureCloud - Onepiece's Files Repository
Google Drive - Onepiece's Update Pack Files Repository - Google Drive - Onepiece's AddOn List Files Repository
Box - Onepiece's Files Repository
UploadINC - Onepiece's Files Repository

Ciao.

[cosy]

thank you very much for this kind gesture.
A nice weekend

[Ultraform]

can you make us a German one too?

http://www.ryanvm.net/forum/viewtopic.p ... 276#133276
http://www.wincert.net/forum/topic/5143 ... /?p=100701

Box - Onepiece's INTL Update List

MixtureCloud - Onepiece's Files Repository
Google Drive - Onepiece's Update Pack Files Repository - Google Drive - Onepiece's AddOn List Files Repository
Box - Onepiece's Files Repository

Ciao.

THX OnePiece Alb <3

[rvm999]

# nonno fabio

On 5/20/13, bphlpt wrote (with regard to your update pack): "The resulting build is also intended to only be used to do a "clean" install, not any kind of repair or update install, so again no previous outdated and superseded hotfixes are involved in any way." (http://www.ryanvm.net/forum/viewtopic.p ... start=2700).

I'm almost certain that I've seen other opinions posted on this Discussion Board indicating that using your build for a repair install presented no problems. Since I'm here because I am about to do a repair install, I thought it best to go to the source for a definitive answer.

If it turns out that builds using your update pack present problems, could you give a brief explanation? As I understand it, the point of using RVM and update packs is to present Windows with an installation source that is almost exactly what it would encounter with Microsoft's retail disk, which replaces "outdated and superseded hotfixes" during a repair install.

Thanks for any light you can shed on this matter, and for your work in creating these Packs.

[nonno fabio]

A repair install using an updated CD should cause no problems at all, as the result of a correct Onepiece's UpdatePack integration is not different from a hypothetical XP SP4 official CD.
I say "should" because our latest repair install test has ran a lot of time ago.
The most important thing is that you must be sure your XP source is untouched by any other software, manual changes and previous integration attempts before you start to add Onepiece's UpdatePack

[rvm999]

A repair install using an updated CD should cause no problems at all. . . .

That's good news. I'll give it whirl.

Thanks for getting back to me.

[nonno fabio]

you're welcome.
please take note that as "repair install" I mean the one you can run booting from CD and not Winnt32.exe installation, in other words manually executing from desktop of a running system.
In this case, you can have some problems if UpdatePack has been integrated in your XP source using RVM Integrator, as Windows Setup doesn't like very much the driver.cab/sp3.cab merging done by RVMi and you could get this: http://imageshack.us/a/img96/2649/h7gl.png and you will be forced to indicate to Windows setup the path for every single XP driver file!
If you plan to run winnt32.exe installations, you must use latest Nlite build in place of RVMi (as always, on a "clean" untouched CD and with upadtepack only, without selecting removals and other modifications)

[rvm999]

. . . as "repair install" I mean the one you can run booting from CD and not Winnt32.exe installation, in other words manually executing from desktop of a running system.

[If you start the repair after booting into XP], you can have some problems if UpdatePack has been integrated in your XP source using RVM Integrator, as Windows Setup doesn't like very much the driver.cab/sp3.cab merging done by RVMi and you could get this: http://imageshack.us/a/img96/2649/h7gl.png and you will be forced to indicate to Windows setup the path for every single XP driver file!

If you plan to run winnt32.exe installations, you must use latest Nlite build in place of RVMi (as always, on a "clean" untouched CD and with upadtepack only, without selecting removals and other modifications)

What an important difference! I'd forgotten that Microsoft offered (http://support.microsoft.com/kb/978788) the option to start an "in-place upgrade" (aka repair install) after booting into XP normally. Fortunately, I was planning to start after booting from the RVM CD.

Even so, thanks for pointing out such a major pitfall.

[bphlpt]

And how will having IE7, or later, installed effect your ability to do a repair install since MS says IE7 must be uninstalled and IE6 installed before running a repair install?

Cheers and Regards

[nonno fabio]

As you know, one of Onepiece's UpdatePack features is that, in the running system, you can easily remove IE8 and restore IE6 from Windows Component Wizard. To do this, the only thing you need is the original ("clean") XP CD (obviously, as IE6 files have been deleted during UpdatePack integration).

So I think (I repeat, our latest repair install test has ran a lot of time ago) that you must do same way, with a WU-updated XP, if IE7-8 have been installed, and an OPUP-updated one

[rvm999]

A repair install using an updated CD should cause no problems at all

I'm puzzled by the results of my first two experiments. Your "prophecy" was correct once, but not on a second trial. Based on my first repair, I apparently have a nearly perfect DVD after using RVM Integrator to merge OnePiece updates into a retail XP SP3 disk. The repair process proceeded with only one small hiccup, and finished successfully.

I was shocked, then, when I tried to use the same disk on a different XP SP3 installation, located on another partition on my machine. This time, the same type of "hiccup" occurred, but instead of a single isolated incident, it happened over and over. Both times, the problem began after the process began to copy files. The installer complained that it could not perform the copy. That happened with one CHM file in the first install, but occurred for INF, THE, DLL, and several other types of files the second time. I gave up after about 14 errors.

After booting back into Windows normally, I examined the install disk, and found that all but one of the files that were supposedly missing were in fact there in the i386 folder in their original compressed form.

Any ideas on what could have happened? I assumed that once I had a "good build" of my "SP4" disk, it would always work, absent problems with missing drivers.

[nonno fabio]

we are using only Windows 7/8/8.1 on our real machines now but a fast test in a XP VM with desktop repair install (the most "sensitive" one) gave no issues at all.
Could you retry with a Nlite integration and see if you have same problems? In this case, we need names of every file giving you errors so we can investigate

[rvm999]

a fast test in a XP VM with desktop repair install (the most "sensitive" one) gave no issues at all. Could you retry with a Nlite integration and see if you have same problems? In this case, we need names of every file giving you errors so we can investigate

I'd never be able to give you "names of every file giving you errors" because it would take to long to monitor and take notes. I had 14 errors in the first 8% of the file copy process. Among those I made notes on were: blue_SS.dll; classic.the; compatws.inf; dgnet.inf; dnary.mdb;evntrprv.mof; hhctrlvi.dll; and hisecoc.inf.

I can't see how trying again with an nLited build would give any useful info. That would be appropriate if there appeared to be a problem with your Pack or its interaction with RVM Integrator. That evidently is not the case here, since, just like you did in your VM, I had a run with "no issues" (of any consequence). That success led you to assume that your ISO was "good"--for good reason. But what would you think if you tried it on another VM, and it produced errors that it did not the first time?

So, it seems to me we need to look at the larger issue of how an RVM Integrator disk interacts with the Windows installation--and if that is any different than a Microsoft source disk. I don't see how they could be different, but perhaps they are.

I believe that, just as it does in a clean install, the files on the source disk (whether RVM or Microsoft) are copied to the HD regardless of whether or not some version of them already exists. That's what it looks like, as the file names stream by as the copying prograss bar moves across the right. Alternatively, it might only be copying files that are missing, or in the wrong version.

Either way, the main question seems to me to be this: why would a compressed version of a file on the source disk not be recognized and copied when necessary, when another trial of the same disk has already shown that the disk is capable of doing that?

The answer can't be that the files on one installation where the disk ran were "clean," while they were "messed up" on the other. A system that is "messed up" in some, or many ways, is the natural state of affairs for Repair Installations. If the File Copy part of the process relied upon finding a "clean" set of files, Repair Installation would essentially never be worthwhile.

Do you see some error in this logic, or the assumptions I'm relying upon?

[OnePiece Alb]

I had 14 errors in the first 8% of the file copy process. Among those I made notes on were: blue_SS.dll; classic.the; compatws.inf; dgnet.inf; dnary.mdb;evntrprv.mof; hhctrlvi.dll; and hisecoc.inf.upon?

is simple you will notice immediately that these files do not update\touch\edit the update pack, so all the doubts are on the RVMi, but to say exactly what is wrong need a thorough analyzes, is one thing that should not happen, RVMi never modify files on CD, is a situation a little strange, as said should not happen, however for the moment use nLite and you'll be Ok I guess

Ciao.

[ELiTE]

I had 14 errors in the first 8% of the file copy process. Among those I made notes on were: blue_SS.dll; classic.the; compatws.inf; dgnet.inf; dnary.mdb;evntrprv.mof; hhctrlvi.dll; and hisecoc.inf.

Read/Write issues are often hardware related specifically SYSTEM memory errors...........

[rvm999]

I had 14 errors in the first 8% of the file copy process. Among those I made notes on were: blue_SS.dll; classic.the; compatws.inf; dgnet.inf; dnary.mdb;evntrprv.mof; hhctrlvi.dll; and hisecoc.inf.upon?

is simple you will notice immediately that these files do not update\touch\edit the update pack, so all the doubts are on the RVMi, but to say exactly what is wrong need a thorough analyzes, is one thing that should not happen, RVMi never modify files on CD, is a situation a little strange, as said should not happen, however for the moment use nLite and you'll be Ok I guess.

I have to guess what you mean when you say, ". . . these files do not update\touch\edit the update pack." Do you mean something like, "updates of these files are not included in the update pack, and so they are not touched when the Pack is integrated?" That makes the situation even more strange, since they are in the Microsoft source, and are merely copied to the RVM disk.

However, I can't agree with you that "all the doubts are on the RVMi." If there was something wrong with the build, or the resulting DVD, it doesn't seem like it could have successfully carried out one Repair Install.

[OnePiece Alb]

Extract Update Pack and see in entries.ini, only those are the changes that Update Pack tells the nLite\RVMi to edit in CD

Ciao.

[rvm999]

Read/Write issues are often hardware related specifically SYSTEM memory errors........... 8)

That couldn't have been the case here. Both Repair Installations were carried out on the same machine within about 2 hours of each other, so all hardware was the same for both trials. Only the partition was different. The machine had not given any indications of memory problems before the test, and has not given any since then.

Your comment did suggest a related possible cause to me, so I just ran chkdsk on the partition that had the problems. The result indicated that "no problems" were found, so disk errors were not the cause.

[rvm999]

Extract Update Pack and see in entries.ini, only those are the changes that Update Pack tells the nLite\RVMi to edit in CD

OK. I understand. Checking entries.ini is what told you that the files that were "supposedly" missing during my 2nd Repair Install are not files that were updated by the OnePiece pack. That confirms that it was not an integration problem that led to the errors.

Thanks for checking that.

[nonno fabio]

Yes, if the errors are those, definitely UpdatePack is not the culprit.
Perhaps have you checked in RVM Integrator "optimize system files" option? Because sometimes this leads to such an error.
I suggest you again to run a new test with Nlite, then try the repair install from CD and see what happens.

[nonno fabio]

new release (see changelog)

[Botus]

Onepiece's XP Update Pack can be used along with Nite 1.4.9.1 and RVM Integrator 1.6.1 b2.1 on a clean XP SP3 ENU source.

not sure its been mentioned... (I guess it must have been) nlite is back in dev 1.4.9.3 is out

http://www.nliteos.com/changelog.html

[bbmak]

Thank you for the new update.
Question out of curiosity, will onepiece's xp update pack survive after Microsoft ends support for Windows XP? I am personally a big fan of Windows XP and Onepiece pack, have been using the pack for long time, and want XP and Onepiece pack to continue.

[nonno fabio]

Onepiece's updatepack will be updated until Microsoft will release updates.
When MS will stop, UP will go final, in same way as W2k UpdatePack.
In other word, there will never be an Onepiece pack with modded files as its purpose is to act like an official Service Pack by adding new files in "true mode", the Microsoft way for SPs

[cosy]

thank you very much for this update, as usual I would like to have a DEU version too if it is possible.
A nice day

[nonno fabio]

thank you very much for this update, as usual I would like to have a DEU version too if it is possible.
A nice day

http://www.ryanvm.net/forum/viewtopic.p ... 542#133542

Now you can find everything you need to make your own pack also in Mega site: https://mega.co.nz/#F%21Bw1yyQSR%21Hin- ... nG-wWcF0hw

[bphlpt]

Sorry nonno fabio, the mega link you gave gives this as the response:

"The file you are trying to download is no longer available.", etc, etc

Cheers and Regards

[OnePiece Alb]

Hi bphlpt, try using Firefox or Chrome browser

IE11 hmmmmmm


Ciao.

[bphlpt]

Hi OnePiece,

It's a little more complicated than that. As you will see below, out of twelve different browsers tested, only three eight worked correctly.

My usual browser is COMODO Dragon, a Chrome variant, which didn't work. But since you thought the problem was a browser incompatibility issue, I did some futher testing. My results: (My OS - Win7x64 Ultimate, completely updated as of 9/16/2013)

These two browsers didn't work. I got the "Please update your browser" message.
Opera v12.16
Waterfox v11.0


For:
IE v10.0.9200.16686
Opera Next v15.0.1147.61
SlimBrowser v7.00 build 032 (Unicode)
Chrome v29.0.1547.66 m
SRWare Iron v27.0.1500.0 (201000)
COMODO Dragon v28.1.0.0 (portable)
-- [The bottome three are all Chrome variants] --

The above six browsers all give the following:



All acting like the links have been removed.

But,

Firefox v24.0
Pale Moon v24.0 (x64)

worked correctly.

So I did a little updating. (I didn't try IE11, since you tried that and it worked, even if it complained a bit, according to the screenshot you posted. Chrome and COMODO Dragon are already at the latest version, as far as I can tell, so I left them alone as well.)

Opera v16.0.1196.73 - now gives the "No longer available" message
Waterfox v18.0.1 - now worked, but gives the "browser compatibility" warning that IE11 gives
Opera Next v17.0.1241.18 - still gives the "No longer available" message
SlimBrowser v7.00 build 051 (Unicode) - still gives the "No longer available" message
SRWare Iron v29.0.1600.1 (220100) - still gives the "No longer available" message
COMODO IceDragon v22.0.0.1 (Portable) [A Firefox v22.0 variant] - worked correctly

So to summarize, for the browsers I tried, all updated to the latest versions I could find, ONLY Firefox and most of it's variants, work "correctly" if using the latest versions, most work completely correct. Only IE, and those that identify as such, and Waterfox, which is based on an older Firefox version, get the "Browser compatibility" warning, but they can still be used at https://mega.co.nz/

These worked correctly:
Firefox v24.0
Pale Moon v24.0 (x64)
COMODO IceDragon v22.0.0.1

These worked, but gave a "Browser compatibility" warning:
Waterfox v18.0.1
IE11 (from your post)

These give the "No longer available" message, acting like the links have been removed:
IE v10.0.9200.16686
Opera v16.0.1196.73
Opera Next v17.0.1241.18
SlimBrowser v7.00 build 051 (Unicode)
Chrome v29.0.1547.66 m
COMODO Dragon v28.1.0.0 (portable)
SRWare Iron v29.0.1600.1 (220100)

You might want to consider placing a "Only works correctly with Firefox" message whenever you refer folks to the https://mega.co.nz/ link.

EDIT: (See below for reason why - The link was the problem.)

These work correctly:
Firefox v24.0
Pale Moon v24.0 (x64)
COMODO IceDragon v22.0.0.1
Opera v16.0.1196.73
Opera Next v17.0.1241.18
Chrome v29.0.1547.66 m
COMODO Dragon v28.1.0.0 (portable)
SRWare Iron v29.0.1600.1 (220100)

These work, but give a "Browser compatibility" warning:
Waterfox v18.0.1 - (based on an older version of Firefox)
IE11 (from your post)
IE v10.0.9200.16686
SlimBrowser v7.00 build 051 (Unicode) - (identifies as IE)

Cheers and Regards

[OnePiece Alb]

Hi bphlpt, Thanks for all details, I work in Firefox Aurora, but in MEGA as in Chrome Only is enabled option to upload folder ehhh, I used the Chrome v29.0.1547.66 m, but now I'm noticing that everything is the fault of the link hmmmmmm, RyanVM Forum supports only the "%21" not "!", if not after the link is not displayed correctly (for this on my Signature I used the Google URL Shortener ehh), "%21" is always OK, but it seems MEGA need to use only

Code: Select all

https://mega.co.nz/#F!Bw1yyQSR!Hin-l0Fy0BRlnG-wWcF0hw

Onepiece's EN-US Windows XP Post-SP3 All-in-One Update Pack

OnePiece Windows XP Post-SP3 UpdatePack v7.2.0 ENU
Update (11 September 2013)
Update (11 September 2013)
Update (11 September 2013)
Update (11 September 2013)
Hash MD5 ABEB62F34A63EFD5633E938E3BE9ECD9
Filesize: 223 MB (233853024 bytes)

although here the link is displayed correctly, it seems that there are no problems


try to click on my Signature ??

Ciao.

[bphlpt]

[...] but now I'm noticing that everything is the fault of the link hmmmmmm, [...]

You are correct. With the "fixed" link, or using your signature, the browsers that couldn't find the links before, now can. The revised info for those browsers is:

IE v10.0.9200.16686 - worked, but gave a "Browser compatibility" warning
Opera v16.0.1196.73 - worked correctly
Opera Next v17.0.1241.18 - worked correctly
SlimBrowser v7.00 build 051 (Unicode) - worked, but gave a "Browser compatibility" warning (identifies as IE)
Chrome v29.0.1547.66 m - worked correctly
COMODO Dragon v28.1.0.0 (portable) - worked correctly
SRWare Iron v29.0.1600.1 (220100) - worked correctly

So all 12 browsers tested can be used at Mega after all. If using the latest versions, most work completely correct. Only IE, and those that identify as such, and Waterfox, which is based on an older Firefox version, get the "Browser compatibility" warning, but they can still be used. I'll edit my post above.

I guess you should pass this forum "bug" on to Ryan to see if he can fix it.

Thanks for the clarification.

Cheers and Regards my friend

[Ultraform]

Is OnePiece Windows XP Post-SP3 UpdatePack v7.2.1 something new/updated :O?

[5eraph]

Flash Player update from 11.8.800.168 to 11.8.800.174. Nothing more, Ultraform.

[Ultraform]

Thanx=) #5eraph

[viggen66]

Dear users, I'm a brand new user, and firstly I want to congratulate all the users for the amazing work done here, for me XP is and always will be the best OS from Microsoft, too bad its life cycle is turning to an end.

Well I have XP Home Edition with September AIO updates 2013, just run Windows Updates, and all the new updates are installed successfully, I'm always worried about the .net framework updates, because these can cause problems.

Moving forward, I have notice that after October's updates on .net framework 4, the commonly slow boot XP know issue has come to life, we need to do the fix, for the boot time to become as it was before the updates, I reckon everybody must know this issue, but I always follow these steps

1) Run cmd.exe from Start > Run
2) Type cd\
3) Type cd C:\Windows\Microsoft.NET\Framework\v4.0.30319\
4) Type NGEN executequeueditems and press Enter
5) It will take about 10minutes depending upon system speed. After the process is complete, the following prompt will appear in the command prompt C:\Windows\Microsoft.NET\Framework\v4.0.30319\
6) Type exit to close the command prompt.

[nonno fabio]

thank you for pointing this out,
Anyway Onepiece's UpdatePack never had such issue as .Nets are integrated in true mode

[molecule]

not sure if either of these are important ...

I'll ask since they didn't show up in the changelog

----
KB2834902
http://www.microsoft.com/en-us/download ... x?id=39441

released as addon or amendment to the August update

----
edit removed link to SP2 patch

----
huge thanks for all your wonderful work

[nonno fabio]

new release (see changelog)

[molecule]

wow! now that's some fast computing

awesome

[viggen66]

nonno fabio, you truly work fast on giving us a new AIO update only after one or two days after the releases, this month was more about Office updates instead of Windows

[OnePiece Alb]

Hi viggen66, in fact have been many this month, 5 Update for DotNet 35-40 + IE8 Update + 6-7 Update for Windows + Silvelight are enough for Windows XP, that after a few months will be closed

Ciao.

[nonno fabio]

nonno fabio, you truly work fast on giving us a new AIO update only after one or two days after the releases, this month was more about Office updates instead of Windows

it's all thanks to Onepiece, actually I'm always late to update links...

[viggen66]

onepiece, I'm sorry I thought monnon was the person responsible for AIO package, but in here, we all work as a team, so all the help is always welcomed.

As you know Microsoft is going to end the support for XP on April 2014, but there's another XP build namely Windows Embedded POSReady 2009, which is going to be supported until April 2019, I don't have the expertise for doing this, but since both Operating System share the same source code, and Embedded is based on XP Professional, do you think it will be possible to port the Embedded Updates to XP? Giving this way XP more 5 years of existence of Microsoft support.

[OnePiece Alb]

onepiece, I'm sorry I thought monnon was the person responsible for AIO package

Without Nonno Fabio, this would not be possible and udate pack would be here today, I do not say this to be gentle, but it the pure Truth

but in here, we all work as a team, so all the help is always welcomed.

exactly, you're absolutely right

As you know Microsoft is going to end the support for XP on April 2014, but there's another XP build namely Windows Embedded POSReady 2009, which is going to be supported until April 2019, I don't have the expertise for doing this, but since both Operating System share the same source code, and Embedded is based on XP Professional, do you think it will be possible to port the Embedded Updates to XP? Giving this way XP more 5 years of existence of Microsoft support.

update in this regard are rare, just use nlite to integrate certain update

Sorry for my English

Ciao.

[cosy]

you two guys are great, thank you very much for this update too. (hope the DEU will also be there soon)
A job well done

[bbmak]

thank you so much.

[PJAmerica]

I cannot seem to get this to install properly when slipstreamed via NLITE's latest version. It gets stuck at the 23 minute mark. When I use Windows XP Post SP3 High-Priority Updates (x86) I have no issues at all though. I would really like to get this working as it is more comprehensive. Can someone please advise me on how to sort this.

Note: I do nothing but add this pack to a clean SP3 slipstream via NLITE's latest version. No changes are made other than trying to add this Update Pack.

[OnePiece Alb]

http://www.ryanvm.net/forum/viewtopic.p ... 742#106742 DotNet Full, need almost 10 or 15 or 20 or 25 minutes to install, depends on the HW

Ciao.

[PJAmerica]

http://www.ryanvm.net/forum/viewtopic.p ... 742#106742 DotNet Full, need almost 10 or 15 or 20 or 25 minutes to install, depends on the HW

Ciao.

Thank you for the prompt response. I let it run for over an hour and it never budged so I wondered about that. Will let it run longer and see how it goes. Thank you for your time.

Keep up the great work folks.

[nonno fabio]

The longest time requested to full Dotnet setup we have seen has been about 30 minutes on very low-end HW.
With shift + f11 you can verify what is in progress and shift + f10, if you type taskmgr.exe, will show you processes being executed.
If you want to be sure, integrate again updatepack with nothing else in a clean source using RVMi and retry.