dougiefresh

What's Changed in v3.0.0.7: - Updated space requirement info on Live Install and Integration Source pages. - Fixed the version check code when it checks for updated GUI versions. - Restored visual elements of Extra's GUI Page back to v2.2.0.4. - Rewrote internal code dealing with duplicating Home resources for Win2k/2k3 when necessary. - Fixed code that moves theme-specific visual styles from resource folder to extra folder. - Added code to build dated CAB of all logs made when keeping log files option. - Re-Added location of BLISS.BMP to XPtsp.ini (Somehow it got deleted). Additional Options page: - Added "Misc" tab with more options to the Additional Options. - Moved option to disable resource translation from Extra's page to new tab. - Added an option to not translate non-English XPSP?RES.DLL files during Integration. - Added an option to keep all logs regarding resource file integration. - Added an option to enable GUI debugging mode from within the GUI. - Added an option to use Professional visual theme instead of Home on non-Pro OSes. - Added an option to disable correcting checksum values in files on Live Install. Everybody: Fixit raised the issue that non-Pro users might find it confusing if they saw the pictures that we have in our gallery, downloaded the GUI and packages, applied it and found something completely different than what they expected. So I added an option to allow the user to force the GUI to use the XP Professional's visual theme instead. The other options are mostly to make any future debugging easier, and may or may not be useful to other people. This version also fixes a fairly major issue with Live Install, mainly that of the incorrect visual theme getting applied to a system. I had to strip out the visual theme from the Extra's package and properly include them in the resource package in order to fix the issue with the Green theme. I will be working on the other themes this weekend in order to correct the visual theme problem, as well as to update the dialog coordinate information so that translations will be allowed within the GUI. Once that is complete, I will be investigating x64 installs to see what needs to be modified in order to get the GUI to integrate the theme packages into the operating system correctly. I expect it to take a while... However, the logonui.exe.res explicitly for x64 will be included in each theme. Unfortunately, this means yet another download for y'all, but it really is unavoidable in order to fix these issues....

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!