dougiefresh

Regarding the "virus" message that you received, I am running Norton 360 on my machine and I can verify that SAV Norton AV reports an trojan during patching. I don't understand why it does though, as the only thing it changes is one icon.... I can only suggest that antivirus software be disabled prior to patching.... Okay, I changed v3.0.0.6a back to 3.0.0.6 on the server in order to remedy this version checking bug at the moment. I've got some new code put in to deal with the version upgrade bug you found, however, it can wait until the next version is released. Is there anything else I should look at?

:thumbsup_anim: Okay.... I introduced that feature in v3.0.0.3, i think... :doh: Stupid version numbers.... Just click no... :shy:

What's Changed in v3.0.0.6a: - WUAUCPL recompiling code modified to wait up to 60 seconds for Reshacker to close. What the :censored: ?! OMG, that's a new one.... Even if the theme package had changed, it still doesn't make any code changes in any files, with exception of TASKMGR.EXE, REGEDIT.EXE and the kernels. Both TASKMGR.EXE and REGEDIT.EXE are hex-edited to enable high-res icons within each program, a trick I found on the WinCert forum. The kernels are hex-edited to replace the palette for bootscreens. I've made an additional modification so that the patcher waits up to 60 seconds for Reshacker. Refreshing current copy online now....EDIT: Current copy uploaded.

What's Changed in v3.0.0.6: - Added check to make sure hex value are valid for TASKMGR.EXE and bootscreen palette. - Rewrote function to recompile dialog in WUAUCPL.MUI because it apparently doesn't work. Updated Extra Packages - July 12, 2010: - Upgraded internal version number from 2.0 to 2.1 - Updated TrueTransparency to version 1.4.0. - Updated CAD 2009 Edition add-on so that branding doesn't result in error message. Thanks. No, as of this time, it only affects correcting the WUAUCPL.CPL.MUI resource file because it occurs before the actual patching occurs. If any other files require correcting like this one does, I'll be sure to wait until Reshacker is finished before proceeding.... BTW, the XP SP1 compatibility code resulted in 10 extra lines, but who's counting when there are 5,600+ lines in the script? LOL!

:shy: Well, I tested the snippet of code dealing with WUAUCPL.CPL.MUI in a separate script. To my surprise (as well as utter lack thereof), the script failed to patch the WUAUCPL.CPL.MUI file. Adding a line of code to wait for Reshacker to close solves this issue..... Why this situation didn't come up sooner baffles me.... As for XP SP1, I implemented a slightly different approach to the same task. The AutoIt help file says that XP SP1 had an update released that blocks the ALT combos passed by AutoIt when user input is blocked. Why would I want to block user input, you ask? Because I need the script to complete the task so that the RES file is correct and user interference during this brief time is completely undesirable. It's maybe 1 to 3 seconds that user input is blocked. Hopefully, it won't cause any problems for anyone, but this "dirty" solution is the only way I can solve this particular problem... EDIT: Before you ask, I define a "clean" solution as one that the user can't see the process happening, such as our hex-editing code. EDIT2: Another "Before you ask" question answered... Why don't I upload a new theme package with the corrected res file? Well, the answer is simple: Translated RES files will need this fix as well, as the problem seems to be induced by the Microsoft Resource Compiler.

:doh: Thanks! It occurred to me to ask that question, but you beat me to it! I'm running it on a Win7 x86 host.... Yeah, me neither. However, I'm sure there are people running it. My wife works for a company whose computers are still running Windows 95.... The affected code is only a difference of 3 lines.... Not much of a difference in order to guarantee compatibility, in my opinion.

Thanks. Evidentally, I'm missing something.... EDIT: I inserted the modified MUI file into a VM. It has the problem you mentioned. I ran Reshacker and recompiled that dialog. Relaunched Automatic Updates control panel and all was right.... So what am I missing? I wrote the code so that all instances of 2000/XP/2003/Vista/Seven will run it, but I'm thinking that maybe the script manually closes Reshacker too soon, so the modified RES file doesn't get saved.... I'm rewriting the code to do it one way for XP SP1 (special requirements) and another way for everything else....

Can you send me a copy of your WUAUCPL.CPL.MUI file? It's found in your Windows/System32 folder. It would be greatly appreciated! Thanks! Integration: It's WUAUCPL.MUI or WUAUCPL.MU_ in the i386 folder....

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. 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.

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

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

What's Changed in v3.0.0.4: - Modified resource translation code to translate only non-English text.

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!

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: and my XPtsp log: 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.....

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... 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.

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 was unaware of that bug, so it didn't get fixed....

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...

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.

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.

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 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!

Thank you and you're welcome! Let me investigate the issue some... 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....

Whoops! I thought I corrected the thread name correctly! But by the time I saw your post, it had been corrected already.... It's definitely version 3.0.0.0!

What's Changed in v3.0.0.0: - Fixed the operating system detection code so that the correct OS is reported. - Added code to check for pending file operations before allowing program install folder to be selected. - Modified code dealing with file browsing to use SFX folder as default folder. - "Disable Resource Translation" checkbox added to Extra's GUI page (enabled for v2.x themes) - Removed OOBE replacement for Windows 2000 and Windows 2003. - Split NetMeeting components into their own group in Component Selection. - Rewrote code so that hardlinks to res files are created when possible to reduce disk space used. - Fixed file patching percent bar to start at 0% instead of 10%. - Eliminated unnecessary file copying in order to try and speed up Live Install process. - Corrected some GUI issues regarding disabling and enabling GUI pages. Features from Beta v2.999.0.x series: - Translation code has been included and enabled. - English language file has been updated with new strings for dialog boxes. - XPtsp.INI has been updated with dialog box line mapping information. - Using older themes with beta GUI will result in inability to translate package. Updated Experimental 64-bit support: - Upgraded Reshacker to version 3.5.2 in order to support 64-bit files. - Removed "Experimental Support" message from Repatcher after installation on x64 OSes. - Added another task for patching the AMD64 folder on x64 operating system source folders. - Added another task for patching the 64-bit files during a Live Install. - Added code to fix a Reshacker problem with icon 0 in Setup.exe and SrClient.dll. - Added code to account for file redirection mechanism in order to patch files in 64-bit OS. Other Words: First, I've been working a lot of hours at my workplace and haven't been able to get the 64-bit patching code working right. I'm not sure why the code is failing to patch the system correctly, as I'm still trying to figure out what I'm doing wrong. Furthermore, testing on Windows 2000 and Windows 2003 still hasn't been done, so I can't tell you whether it works or not. Feedback would be appreciated from anyone willing to try it..... Second, Fixit brought to my attention that with the .theme file extension, the theme appears to have deeper operating system support than should be implied. So I have decided to change the file extension to .xptsp, since it directly implies XPtsp ownership of the files instead of to the operating system. This shouldn't affect previous versions of the GUI, as the website will redirect requests for .theme files to the ones with the .xptsp file extension..... Third, I've made some code changes to try to speed up the patcher by removing unnecessary file copies and moves. There isn't much difference, but trust me, the difference is there... Lastly, the website is being redesigned to make it look even better (in my opinion) and to add forum functionality to it. Yes, I know I said I wouldn't add a forum to the site, but the fact is that the forum membership functions are substantially better than the code I can write. We've also have been having issues with the comments sections of some pages. One solution is to move that functionality to the forum, which would solve some or all of those issues.