This is an excellent tool. Thanks for all your efforts...

v3 is removing ntsd.exe and not replacing it after patching.

Therefore in vm ntsd.exe can't be copied because it no longer exists in I386.

Also, netsetup.exe and regedit.exe

Thank you and you're welcome! Let me investigate the issue some...

Trying v3.0.0.0 and I'm getting a fail during integration.

Integrating into xp pro sp3 with u_h 1.3.0 update pack.

Integration halts here with no progression if I close the cmd window.

The cmd window will continue to respawn in an endless loop until I reboot.

I think I left some debugging code in v3.0.0.0 that revolves around the XPSP?RES.DLL files.... Off-hand, I don't think that you're experiencing a loop, as the code is designed to pick up on other versions of XPSP?RES.DLL named differently and patch them. But let me investigate the issue....

I've looked at the code and the debug flag has been incorrectly set. It's supposed to be set only for uncompiled versions, or if the "/DEBUG" switch is passed to the GUI. I've cleared the flag for compiled versions, but I need to research the missing files issue that rr650 brought up first before I release the next version. I apologize about the mistake!

EDIT: For clarity's sake, I'll also change the code so that the filename being edited is shown instead of which res file is being used.

EDIT2: Re-uploaded v3.0.0.0 with the debug variable cleared.

EDIT3: If you have GUI v3.0.0.0 with a MD5 hash of a51bf47f3018675b13eaff8044b9f4c1, please redownload the fixed GUI. Thank you!

The problem with xpsp?res.dll still exists.

I decided to test the updated v3.

Each test started with clean source xpsp3.

I integrated U.H. update pack 131.

Results: 1) without applying xptsp v3...install in VM went flawless.

2) When xptsp v3 is applied...there are 7 files missing...dvdplay.exe, ntsd.exe, regedit.exe, netsetup.exe, telnet.exe, winntbbu.dll, ntkrnlpa.exe

I've done each test twice with identical results.

sorry for the bad report

rr650: I hadn't fixed the issue you brought up yet because of lack of time. 2 posts back I had stated "I need to research the missing files issue that rr650 brought up first before I release the next version." The debug flag was such an easy fix that I decided to reissue GUI v3.0.0.0 (which is something I rarely EVER do).

I was planning on research the issue you found this weekend. I apologize since my communication wasn't clear on that point.... However, I'm pretty sure it's not an easy fix like the issue with the debug flag....

I've cleared the flag for compiled versions, but I need to research the missing files issue that rr650 brought up first before I release the next version. I apologize about the mistake!

Mr_Smartepants: I've had a chance to sit down and work on the code. The debug flag for v3.0.0.0 is still incorrectly set. It'll be fixed with the next version. I apologize about any inconvenience this has caused.

EDIT: It seems that there is an issue with the XPSP2RES.DLL resource file when it is translated into other languages. I am working on this issue right now.

rr650: I can verify that files are missing from the install source. I think I know what section of the code is causing this issue. I apologize about any inconvenience this has caused.

No problem. I'm standing by waiting to test.

From my perspective, there's nothing wrong with 2.2.0.4, but I'm all for progress and supporting more users. :thumbsup_anim:

What's Changed in version 3.0.0.1

- Fixed issue where debug flag was incorrectly enabled.

- Fixed an issue that resulted in uncompressed files being deleted after patching.

- Modified patching routine to show if compressed name is different from resource name.

Experimental 64-bit support:

- Modified all registry read/write functions for compatibility with x64 operating systems.

Mr_Smartepants and rr650: This version should fix the issues both of y'all found. Thanks for the bug reports!

Everyone: The x64 operating system support still does not work as expected. At first, the x64 OS would report a corrupt MSGINA.DLL. So I removed that file from being patched and I could get a little farther. Now, EXPLORER.EXE and TASKMGR.EXE are coming up as corrupt or causing some sort of problem which prevents it from running..... So that's where I stand with patching a x64 OS at the moment.

Just testing now. 3.0.0.1 is detecting my XP MCE source as XP Pro now.

I'll continue with the integration and let you know of any other problems.

What's Changed in v3.0.0.2:

- Added Reshacker and Resource Compiler log handling code to the GUI.

- Fixed the code that does MCE detection for integrations.

- Fixed the code that changes the Setup resolution for integrations.

- Changed code so that checksum of PE files only happens during integrations.

Experimental 64-bit support:

- Fixed the code so that UXTHEME.DLL.RES isn't deleted prior to x64 patching.

- Added empty MSGINA.DLL.RES to resource X64 folder if it doesn't already exist.

- Added empty EXPLORER.EXE.RES to resource X64 folder if it doesn't already exist.

This release fixes the MCE detection for integrations, as well as the hive editing code for changing setup resolution. I apologize about the delay, as I have been working many hours at work :confused02: :crying_anim02:

x64 support still does not work, much to my irritation. Removing the checksum correction code from non-integrations seems to help, but EXPLORER.EXE is still being corrupted somehow..... I'm gonna have to eliminate res files in groups until I figure out which ones will and won't work...

I just got done testing my Pro disc which had 3.0.0.1 integrated in it, so I don't know if you've already fixed it in 3.0.0.2 but it had issues.

When I go through the installer I usually uncheck the "Additional Programs" UberIcon, Visual Task Tips, Transparent Bar, True Transparency, & WinFlip but they ALL got installed anyway.

I have not yet tested 3.0.0.2.

I was unaware of that bug, so it didn't get fixed....

What's Changed in v3.0.0.3:

- Fixed issue where Additional Programs were installed regardless of item's checked state.

- Added code to Theme Selection page to check to see if newer version of GUI is available.

Experimental 64-bit support:

- Changed method of passing list to a function so that entire list can be processed for 64-bit files.

- Removed empty EXPLORER.EXE from resource x64 folder.

- Added empty SHELL32.DLL.RES to resource x64 folder if it doesn't already exist.

- Added code to skip hex-editing on TASKMGR.EXE and REGEDIT.EXE.

- Removed option to edit bootscreen during patching of x64 operating systems.

Mr_Smartepants: This update takes care of the issue you reported.

Everybody: While x64 support is still in the experimental phase, I am now able to boot into my x64 VM after patching and rebooting. Patching MSGINA.DLL results in a corrupt operating system. Patching SHELL32.DLL results in a corrupt EXPLORER.EXE. Creating an empty res file that gets copied over the ones in the root resource folder solves both of these issues in the interim, so anything that is modified in those files will not show up. Also, the visual themes don't show up correctly, probably because UXTHEME.DLL isn't patched correctly. Patching the kernel results in a corrupt executable, so it has been disabled. TASKMGR.EXE isn't hex-edited because it results in a corrupted executable.

It's likely that new theme packages will be uploaded within coming weeks, with updated resources for x64 operating systems.

EDIT: I should mention that while the MSGINA.DLL and SHELL32.DLL patching has been essentially disabled, the program will show that these files are being patched, but no resources are actually being modified.

I just got done testing my Pro disc which had 3.0.0.1 integrated in it, so I don't know if you've already fixed it in 3.0.0.2 but it had issues.

When I go through the installer I usually uncheck the "Additional Programs" UberIcon, Visual Task Tips, Transparent Bar, True Transparency, & WinFlip but they ALL got installed anyway.

The above problems still exist in 3.0.0.3 on my MCE build. I have not yet tested Pro.

The above problems still exist in 3.0.0.3 on my MCE build. I have not yet tested Pro.

Just confirmed with Pro. The problem still exists. Additional programs are installed even if they are deselected.

The Automatic Update screen has problems. The link for "How does Automatic Updates work?" is broken. I cannot make a selection stick and if I choose "Automatic (recommended)" I cannot pick a day and time.

I'm modifying the code so that the res translation doesn't change the text for any English versions of XP, regardless of location. I'm hoping this will solve the issue...

Just confirmed with Pro. The problem still exists. Additional programs are installed even if they are deselected.

I can't reproduce the problem with version 3.0.0.3.

Are you integrating into a XP source? If so, are you sure you are using a copy of XP that hasn't been modified with XPtsp yet in your tests? I'm just asking because I ran two tests unselecting the additional programs. One test was the entire group. The other test was unchecking individual items.... Each test that I did on a clean XP source failed to integrate the specified apps.

I integrate XP SP3 MSDN sources with U_H post-sp3 updatepack along with WMP11 and a (fairly conservative) list of addons. I'll do another test just to make sure.

*Edit

OK, confirmed. The problem still exists. Just did XP Pro SP3 with my normal updatepack/addon load.

I make the following de-selections:

All other settings are defaults.

Here's the relevant portion of the xptsp log:

XPtsp v3.0.0.3 Patching Started: 07/04/2010 06:53

<snip>

Patching WBEMOC.INF

Patching SVCPACK.INF

Modifying TRUETRAN.CAB add-on for OS

Copying theme package to i386 folder...

Adding Optional Components

Patching Completed in 0 seconds.

And the relevant portion of dosnet.inf

[Files]

d1,XPtsp_CF.inf

d1,XPtsp_CF.Cab

d1,AeroCurs.inf

d1,AeroCurs.Cab

d1,VistaPix.inf

d1,VistaPix.Cab

d1,WinFlip.inf

d1,WinFlip.Cab

d1,CAD2009.inf

d1,CAD2009.Cab

d1,TrueTran.inf

d1,TrueTran.Cab

d1,TransBar.inf

d1,TransBar.Cab

d1,NR_VisTT.inf

d1,NR_VisTT.Cab

d1,UberIcon.inf

d1,UberIcon.Cab

d1,XPtspCom.inf

Before integrating, I used ccleaner to nuke my temp files, used a clean XP source, reintegrated fresh updatepack/addons. Redownloaded xptsp 3.0.0.3 (MD5 matches site) and let the GUI download fresh themes, extras etc.

I'll test again on a bare XP Pro sp3 source just to be certain.

*Edit#2

Problem still exists even with an unaltered MSDN XP Pro SP3 disc. Dosnet.inf entries are made and files added even if de-selected.

What else would you like me to try?

*Edit#3

OK, de-selecting the entire group, then manually re-selecting the components I wanted solves the problem.

Edited July 4, 201015 yr by Mr_Smartepants

Okay... That's really weird, cause I haven't been successful at reproducing this problem... I just integrated a clean XP Pro SP3 with XPtsp without the add-ons you specified. This is the section that I found in DOSNET.INF:

[Files]

d1,XPtsp_CF.inf

d1,XPtsp_CF.Cab

d1,AeroCurs.inf

d1,AeroCurs.Cab

d1,VistaPix.inf

d1,VistaPix.Cab

d1,CAD2009.inf

d1,CAD2009.Cab

d1,XPtspCom.inf

d1,xptsporb.bmp

and my XPtsp log:

Patching WBEMOC.INF

Adding XPtsp Orb to XP installation

Patching SVCPACK.INF

Copying theme package to i386 folder...

Adding Optional Components

Patching Completed in 0 seconds.

EDIT: Oh, I tested with XPtsp GUI v3.0.0.3, as well as the unreleased v3.0.0.4. For me, neither integrated add-ons that were unchecked.

EDIT2: In case you're interested, the only change I've made to v3.0.0.4 so far is to the resource translation code, as mentioned to Burned a few posts ago.....

Now that I know what to look for, I can work around this issue. It's possible that 3.0.0.4 will solve the problem inadvertently.

I apologize about the delay. I've been rather busy with other things and haven't been able to release a copy that should take care of these problems.

Burned: Can you send me a copy of %WindowsDir%\System32\WUAUCPL.CPL and %WindowsDir%\System32\WUAUCPL.CPL.MUI (if available) by PM, please? I would like to look at those files before releasing the new version. Thanks!

EDIT: Oh yeah, can you also send the original files as well? Thanks!

What's Changed in v3.0.0.4:

- Modified resource translation code to translate only non-English text.

Just got done testing the new 3.0.0.4 GUI and I can confirm that the Automatic Updates tab problem Burned reported affects all versions (Home, Pro, MCE) AND not just the 3.* versions of GUI but 2.2.0.4 also, which never previously had a problem now has the same problem.

The bug must be in the resources (green.xptsp tested) or somewhere else.

I tried with resources translation option checked & unchecked.

Just got done testing the new 3.0.0.4 GUI and I can confirm that the Automatic Updates tab problem Burned reported affects all versions (Home, Pro, MCE) AND not just the 3.* versions of GUI but 2.2.0.4 also, which never previously had a problem now has the same problem.

The bug must be in the resources (green.xptsp tested) or somewhere else.

I tried with resources translation option checked & unchecked.

Frack! I'll look into it....

I created a brand-new XP VM and applied the XPtsp Green batch to it. I see the issue that you and Burned are talking about.

I got the dialog box to appear correctly, like it should (and did before v2.2.0.4). Here's the problem: In order to do so, I had to manually launch Reshacker, navigate to dialog 62302, and recompile the script within Reshacker. That seems to solve the problem, but it's a very MANUAL approach to solving this issue.

At this point in time, I have absolutely NO IDEA how to solve this issue within the confines of the program. Any res file that is translated via XPtsp will have this issue with the WUAUCPL.CPL.MUI (WUAUCPL.MUI for integrations). Now, I could invoke AutoIt's ability to send keystrokes to Reshacker while it's open, but what if the file has different resources in them? Or is missing resource sections? I just can't account for unseen and unforeseeable differences within the MUI file....

I've attached the modified WUAUCPL.MUI file to this post. You can manually replace the file after extracting the theme package -- installs: %ProgramFiles%\XPtsp\Resources, integrations: %temp%\7ZipSfx.000\Resources (replace 000 with appropriate number). I'm currently looking into other options for solving this problem....

wuaucpl.7z

Is that file the same through all the different XP versions? Removing the resources and doing a simple file replacement would be the simplest option, but not very elegant. Also the safest option, but not ideal either would be to not patch that file in the first place (until a fix is found).

Having a partially patched system is better than a broken system.

What's Changed in v3.0.0.5:

- Added function to recompile dialog in WUAUCPL.MUI prior to applying res file.

- Modified code so that original resources aren't overwritten when translating.

- Modified TASKMGR.EXE hexing code so that possible out-of-bounds array error doesn't occur.

Is that file the same through all the different XP versions? Removing the resources and doing a simple file replacement would be the simplest option, but not very elegant. Also the safest option, but not ideal either would be to not patch that file in the first place (until a fix is found).

Having a partially patched system is better than a broken system.

I think that file is the same throughout all versions of XP. I really don't like replacing system files like that because of the potential problems that the action brings about. For example, earlier versions of XPtsp replaced the files for Remote Desktop. Well, sometime after that, an update came out for Remote Desktop. Guess what? XPtsp broke Remote Desktop for systems with that update installed and/or integrated! Not good, if you ask me!

Last night, I tried out some other resource compilers, hoping to find one that could compile the resources correctly. On that count, I failed. I got to thinking about using Reshacker and came to the realizaion that I don't need to alter the actual MUI file, but the RES file, since it will always be the same, no matter how much the MUI file changes. So I decided to go the visually unappealing route: launching Reshacker and sending keystrokes in order to get it to compile that res file correctly. I've tested this modification and it works to correct this problem with the Automatic Updates control panel.

EDIT: Oh, I almost forgot that the modification made doesn't require that a new theme package be downloaded.... It can correct the WUAUCPL.MUI.RES file so that it works properly.