[Rel] System File Patches >09/23/08<
Both.
For the update specific files, then you can release directly to whatever file is in the update pack.
For a general hotfix PatchAddon, always include both because you can never predict WHICH will actually go in by the users hand or simple mistake or any number of other things that you don't happen to think of until they actually end up happening.
I'm slowly expanding these addons. Fortunately, the uptime at work is tapering off, so not so much overtime is needed, so I can focus on getting more things done, including patches for private hotfixes and the like.
For the update specific files, then you can release directly to whatever file is in the update pack.
For a general hotfix PatchAddon, always include both because you can never predict WHICH will actually go in by the users hand or simple mistake or any number of other things that you don't happen to think of until they actually end up happening.
I'm slowly expanding these addons. Fortunately, the uptime at work is tapering off, so not so much overtime is needed, so I can focus on getting more things done, including patches for private hotfixes and the like.
Thank you Zacam 
By the way, I've updated some of your addons to work with french files version :
http://dl.free.fr/mDLeYUKsu/PatchAddon_SFC_OS_v13g.7z
http://dl.free.fr/m1tKc54b2/PatchAddon_UXTHEME_v13g.7z
For those files, the header checksum waas incorrect. Here is what I did :
I modified the files manually with ultraedit, not the header part at offset 320, the other part. Then, I did a modifype to correct the checksum header. Finally, I got this value with ultracompare and modified your addon.
Kal

Well, let's suppose I've included botch tcpip.sys (GDR/QFE) in my update addon. The end user that will integrate my addon with RVMi won't be able to choose?! I mean, the choice is done by me in the inf file, where I decide which tcpip.sys version I will replace in I386. I'm a little bit confused.Zacam wrote: For a general hotfix PatchAddon, always include both because you can never predict WHICH will actually go in by the users hand or simple mistake or any number of other things that you don't happen to think of until they actually end up happening.
By the way, I've updated some of your addons to work with french files version :
http://dl.free.fr/mDLeYUKsu/PatchAddon_SFC_OS_v13g.7z
http://dl.free.fr/m1tKc54b2/PatchAddon_UXTHEME_v13g.7z
For those files, the header checksum waas incorrect. Here is what I did :
I modified the files manually with ultraedit, not the header part at offset 320, the other part. Then, I did a modifype to correct the checksum header. Finally, I got this value with ultracompare and modified your addon.
Kal
So that means that we can avoid patching header part ? That won't be a problem during windows install (integrity check) ?ENU_user wrote:kal, the checksume in integrator was not working for a long time now and the patches were not usually offered with headers ...
nevertheless, you just made a good point as to why its correct offering the patches with no headers.
and for anyone who is using new RC1 , its ok to remove them.
good luck.
Zacam updated his files according to the new version, just download this :biatche wrote:kal:
I downloaded your PatchAddon_TCPIP_250_v13g.7z ... what do I need to modify in this to make it patch for 100 concurrent connections.
http://zacam.ueuo.com/rvm/PatchAddon_TCPIP_100_v13g.7z
No, it's just to add compatibility with french file versions for the header part (which seems not really important)biatche wrote: for uxtheme/SFC, will I need to download that 'g' version? or can I use zacam's F version?
thanks
Kal
I actually had not thought of other languages or had someone point out(thank you again) that diff lang versions of a file had diff checksums.
Since the patching data should be the same, the only conflict would be in offset. But, since the original checksum for the unmodified file is different between them, and since I don't do wildcard replacement, keeping them seperate (without having to uise seperate files) will be easy.
The only reason why I began patching the offsets for Checksum was because Vista broke modifype. To prevent such future breakages or anything else of the like, I'm going to continue doing so. However, though the offsets for checksum are different for French versions, all that will happen is that the addon will fail to patch with the provided information and the integrator (providing the modifype replacement does what it is supposed to) will automatically correct the offset before it compresses the file. In short: I'm including it because I can to prevent having to do it because it needs to be.
I am glad to see you do things the same way I do: manually. I hope you also test the same way.
As to GDR/QFE patch addons: If you don't know which version is in the source that the addon is going to be used on, include the information for both.
biatche: Apparently you cannot read, since only two posts up from yours I documented that I already changed stuff.
Since the patching data should be the same, the only conflict would be in offset. But, since the original checksum for the unmodified file is different between them, and since I don't do wildcard replacement, keeping them seperate (without having to uise seperate files) will be easy.
The only reason why I began patching the offsets for Checksum was because Vista broke modifype. To prevent such future breakages or anything else of the like, I'm going to continue doing so. However, though the offsets for checksum are different for French versions, all that will happen is that the addon will fail to patch with the provided information and the integrator (providing the modifype replacement does what it is supposed to) will automatically correct the offset before it compresses the file. In short: I'm including it because I can to prevent having to do it because it needs to be.
I am glad to see you do things the same way I do: manually. I hope you also test the same way.

As to GDR/QFE patch addons: If you don't know which version is in the source that the addon is going to be used on, include the information for both.
biatche: Apparently you cannot read, since only two posts up from yours I documented that I already changed stuff.

I am not able to access http://zacam.ueuo.com/
Can anyone give me another link to those patchs
Can anyone give me another link to those patchs
-
- Posts: 17
- Joined: Tue Feb 20, 2007 10:13 pm
Zacam just been looking through the TCPIP (100 to 250) v13g.ini that under the ExtraFileEdits section you have made a typo
Shouldn't the KB be kb941664 not KB91644
Code: Select all
;RVM 2.2.1 - Beta 3
I386\rvmtemp\extracted\RVMUpPck.inf|KB91644\Filelist\0","BuildCheckSum",0,"649a2"|KB91644\Filelist\0","BuildCheckSum",0,"649fc"|1
RVMUpPck.inf|KB91644]\Filelist\0","BuildCheckSum",0,"649a2"|KB91644\Filelist\0","BuildCheckSum",0,"649fc"|1
Hi Zacam Sunday has come and gone and no update..Zacam wrote:I'll have 3282 & 3300 done up by sunday night. I have a new method to force check that will (or should) correct any sleep dep typo's.
(My smallest pay period in hours since Mid October was 88 hours and we are now under a vacation freeze. Oh joy.)

Thanks
dolivas
Yeah. I'm going to have to take in to work with me to get it done. I don't like the idea because it can allow for more errors to occur than I would like, but I need to get this done for all of you.
I can definitively state that you will have updates before this weekend OR within 24hr's of when Ryan's UpdatePack goes final, which ever comes first.
I can definitively state that you will have updates before this weekend OR within 24hr's of when Ryan's UpdatePack goes final, which ever comes first.
the typos are easy to fix, but for newer versions of the hotfix these patches work on i have no idea.
XP theme source patcher
patches/overwrites ure default xp visual resources
patches/overwrites ure default xp visual resources
3282 & 3300 use the same patch offsetsfor TCP.
As an experiment, I'm going to remove PEChecksum patching to open up compatibility. Since RVM b3 and b4 use a 3244 that is different than the SP3 3244 and to support muli-lingual offsets.
This means that we are going to have to hope that integrators checksum patching never breaks or get's broken.
(I'll still be recording all actual PECheckSum's, I just won't be including them. It will also greatly speed up my release process. Updates will be here soon.)
As an experiment, I'm going to remove PEChecksum patching to open up compatibility. Since RVM b3 and b4 use a 3244 that is different than the SP3 3244 and to support muli-lingual offsets.
This means that we are going to have to hope that integrators checksum patching never breaks or get's broken.
(I'll still be recording all actual PECheckSum's, I just won't be including them. It will also greatly speed up my release process. Updates will be here soon.)
Thanks for taking the time Zacam. Many users will appreciate it. 
As for the PEChecksum stuff. I think I've got it working smoothly so we shouldn't have to worry.
Edit:
Link is bad for PatchAddon_SFC_OS_v13h.7z.
I can provide you hosting for your addons in the addons database if you'd like? http://integrator.siginetsoftware.com/index.php?addons
Currently Jurjen is working on a registration page so that users can easily register for an addon posting account. But for now just PM Me and I can create an account for you.

As for the PEChecksum stuff. I think I've got it working smoothly so we shouldn't have to worry.

Edit:
Link is bad for PatchAddon_SFC_OS_v13h.7z.
I can provide you hosting for your addons in the addons database if you'd like? http://integrator.siginetsoftware.com/index.php?addons
Currently Jurjen is working on a registration page so that users can easily register for an addon posting account. But for now just PM Me and I can create an account for you.
I just found a flaw in the uxtheme patch.
You places a colen : instead of a semi-colen ; On the SP3 spot.
:KB936929 - SP3 Should be ;KB936929 - SP3
Here is a fixed entries file:
Hope you don't mind Zacam. I posted a link to the fixed uxtheme patch. You can edit it with your link when you get back. 
You places a colen : instead of a semi-colen ; On the SP3 spot.
:KB936929 - SP3 Should be ;KB936929 - SP3
Here is a fixed entries file:
Code: Select all
[General]
Author = Zacam
Builddate = 02/17/2008
Title = Multi-Patch: UXTHEME.DLL
Description = Addon which allows unsigned Themes
Version = 1.3h
Website = http://ryanvm.net/forum/viewtopic.php?t=2274
[ExtraFileEdits]
;RVM 1.2.0 - 2.0.4
I386\rvmtemp\extracted\RVMUpPck.inf|KB319740\Filelist\0","BuildCheckSum",0,"412c0"|KB319740\Filelist\0","BuildCheckSum",0,"40540"|1
I386\RVMUpPck.inf|KB319740\Filelist\0","BuildCheckSum",0,"412c0"|KB319740\Filelist\0","BuildCheckSum",0,"40540"|1
;RVM 2.0.5 -
I386\rvmtemp\extracted\RVMUpPck.inf|KB908536\Filelist\0","BuildCheckSum",0,"44c63"|KB908536\Filelist\0","BuildCheckSum",0,"43ee3"|1
I386\RVMUpPck.inf|KB908536\Filelist\0","BuildCheckSum",0,"44c63"|KB908536\Filelist\0","BuildCheckSum",0,"43ee3"|1
[HexEdit]
;XP SP2
I386\UXTHEME.DLL|6.0.2900.2180|113178|83EC1C568D4DE4|33C0C9C2040090
;KB319740 - RVM 1.2.0 - 2.0.4
I386\UXTHEME.DLL|6.0.2900.2523|104714|83EC1C568D4DE4|33C0C9C2040090
;KB908536 - RVM 2.0.5 -
I386\UXTHEME.DLL|6.0.2900.2845|104746|83EC1C568D4DE4|33C0C9C2040090
;KB936929 - SP3
I386\UXTHEME.DLL|6.0.2900.3180|104746|83EC1C568D4DE4|33C0C9C2040090
I386\UXTHEME.DLL|6.0.2900.3205|104746|83EC1C568D4DE4|33C0C9C2040090
I386\UXTHEME.DLL|6.0.2900.3244|104746|83EC1C568D4DE4|33C0C9C2040090
I386\UXTHEME.DLL|6.0.2900.3264|104746|83EC1C568D4DE4|33C0C9C2040090
I386\UXTHEME.DLL|6.0.2900.3282|104746|83EC1C568D4DE4|33C0C9C2040090
I386\UXTHEME.DLL|6.0.2900.3300|104746|83EC1C568D4DE4|33C0C9C2040090

- nonno fabio
- Posts: 1627
- Joined: Mon Jun 06, 2005 10:36 am
- Location: Northern Italy
- Contact:
Zacam, thanks for your great work.
Is it possible to make a Syssetup.dll patch for W2k and W2k3 too, at least for newer file?
Windows 2000 professional: syssetup.dll v5.0.2195.6611
Windows 2003 Server: syssetup.dll v5.2.3790.3959
thx in advance
Is it possible to make a Syssetup.dll patch for W2k and W2k3 too, at least for newer file?
Windows 2000 professional: syssetup.dll v5.0.2195.6611
Windows 2003 Server: syssetup.dll v5.2.3790.3959
thx in advance
Don't ask for a different configuration of Onepiece's XP AIO Update Pack: use one of the existing vanilla XP UpdatePack with your preferred addons instead
I recently used the TCPIP.SYS 100 addon and noticed this in the Integrator log:
10:45:17 - TCPIP.SYS 5.1.2600.3244 Patched at offset 325830.
10:45:17 - TCPIP.SYS 5.1.2600.3244 No match at offset 325958. Patch skipped.
10:45:17 - New checksum: 0x64A5E (I386\TCPIP.SYS)
Sorry for the newbie question but is this OK or an error???
10:45:17 - TCPIP.SYS 5.1.2600.3244 Patched at offset 325830.
10:45:17 - TCPIP.SYS 5.1.2600.3244 No match at offset 325958. Patch skipped.
10:45:17 - New checksum: 0x64A5E (I386\TCPIP.SYS)
Sorry for the newbie question but is this OK or an error???
That is because it checks for different file types. It fails on one type then is successful on another.compstuff wrote:I recently used the TCPIP.SYS 100 addon and noticed this in the Integrator log:
10:45:17 - TCPIP.SYS 5.1.2600.3244 Patched at offset 325830.
10:45:17 - TCPIP.SYS 5.1.2600.3244 No match at offset 325958. Patch skipped.
10:45:17 - New checksum: 0x64A5E (I386\TCPIP.SYS)
Sorry for the newbie question but is this OK or an error???

Beta SP3 has a version # 3244. RVM update pack ALSO has a 3244 version of the file, but they are NOT identical.
Hence the message, which is commented in a general sense on the first post as being ignorable.
Now, if it had found the file and failed to patch both/either offset, then I'd want a copy of it to find out why.
Hence the message, which is commented in a general sense on the first post as being ignorable.
Now, if it had found the file and failed to patch both/either offset, then I'd want a copy of it to find out why.

I'd really like to second this request.nonno fabio wrote:Zacam, thanks for your great work.
Is it possible to make a Syssetup.dll patch for W2k and W2k3 too, at least for newer file?
Windows 2000 professional: syssetup.dll v5.0.2195.6611
Windows 2003 Server: syssetup.dll v5.2.3790.3959
thx in advance


I think this is the magic of the integrators [HexEdit] section. It can allow us to support so many different versions/types of the files to be hex edited with a simple entries file.

Sig: Post me a link for whatever files you have (2K in one sort, 2K3 in another).
Normally, I'd try the OS installs myself and go from there, but I honestly just have NOT had the time that I've wanted OR needed to do this.
If I have before/after, I can evaluate the patch offsets in debug and enumerate the correct allocations to then patch all versions (forewards and backwards) and I can do it with a PDA on my morning commute on the train.
compstuff: If I may, what was the issue causing the problem?
Normally, I'd try the OS installs myself and go from there, but I honestly just have NOT had the time that I've wanted OR needed to do this.
If I have before/after, I can evaluate the patch offsets in debug and enumerate the correct allocations to then patch all versions (forewards and backwards) and I can do it with a PDA on my morning commute on the train.
compstuff: If I may, what was the issue causing the problem?
Hi Zacam I have a question for you I was looking at the PatchAddon_TCPIP_100_v13h trying to figure out how to make it work with the new SP3 3311 build and noticed what I think is an error in the ini is this correct?
Should the end not be just 64 ? also would I just add this to the ini file to get the SP3 3311 build patched?
I have been reading all I can find to figure out how to determine the correct offset. Any tips on finding this information.
Thanks,
dolivas
Code: Select all
;KB941644 - RVM b3 - RC
I386\TCPIP.SYS|5.1.2600.3244|325830|0A|C64
Code: Select all
I386\TCPIP.SYS|5.1.2600.3311|326214|0A|64
Thanks,
dolivas
Corrections made, Updated to 3311.
In the case of SP3, it doesn't appear that they are making any REAL changes to the files for TCPIP, so the same address offset has continued to work so far.
This, however, is not always the case and as such is something to keep in mind.
For TCPIP I run through a dis-assembler and do a query search until I find the base value + search tag. I then run a search in Hexedit for the resultant code to find the decimal address location.
The surrounding code around the base value (0A) can vary, unlike UXTHEME. Even still, I apply the same method to all patches to make sure of the locations falling into the approriate sections.
In the case of SP3, it doesn't appear that they are making any REAL changes to the files for TCPIP, so the same address offset has continued to work so far.
This, however, is not always the case and as such is something to keep in mind.
For TCPIP I run through a dis-assembler and do a query search until I find the base value + search tag. I then run a search in Hexedit for the resultant code to find the decimal address location.
The surrounding code around the base value (0A) can vary, unlike UXTHEME. Even still, I apply the same method to all patches to make sure of the locations falling into the approriate sections.
-
- Posts: 17
- Joined: Tue Feb 20, 2007 10:13 pm
This seems to have a pretty good list of some patched uxtheme files someone made.
http://www.withinwindows.com/uxthemes/
Do you need the originals as well?
http://www.withinwindows.com/uxthemes/
Do you need the originals as well?
Hi, found something in tcpip 250 patch that seems to be a typo, here are lines 31-32:

shouldn't be KB941644 instead?I386\rvmtemp\extracted\RVMUpPck.inf|KB91644\Filelist\0","BuildCheckSum",0,"649a2"|KB91644\Filelist\0","BuildCheckSum",0,"64a92"|1
RVMUpPck.inf|KB91644\Filelist\0","BuildCheckSum",0,"649a2"|KB91644\Filelist\0","BuildCheckSum",0,"64a92"|1

Here's the code needed for the official 2003 Server SP2 uxtheme file v6.0.3790.3959. 
Tested and working.

Tested and working.

Code: Select all
;2003 Server SP2
I386\UXTHEME.DLL|6.0.3790.3959|175801|81EC88000000A11C|33F68BC6C9C20800