dougiefresh

Awesome news! Thanks!

I'm sure that once the theme is complete, it will be published.

What's Changed in v2.0.0.4: - Modified code so that SVCPACK folder isn't removed during integration. - Modified code so that variable for temp folder isn't changed inadvertently.

I successfully reproduced the problem on my end. It seems to occur during the routine altering the SVCPACK folder. For some reason that I haven't tracked down yet, it removes the folder. I will try to resolve the problem (whatever it may be)... EDIT: I've fixed the problem with the code. It didn't occur in the routine altering the SVCPACK folder, it actually occurs during the compression of the files in the EXTRA folder. The compression routine deletes the source file before compressing the new file into the place of the old file. Apparently, if specifying a folder using FileDelete, AutoIt deletes the contents of the folder! To fix this, I've added a check to filter out folders to the routine responsible.

First post has been modified for mirror links.

What's Changed in v2.0.0.3: - Modified download code so that correct download rate is shown. - Added code to Page 6 to ensure resource folder is created before extraction. - Page 9 modified so that the empty COMCTLxx.DLL files are created properly. Sidenote: No progress was made on the translation code. I have made the necessary changes to the Black, Blue, Purple and Red themes, based on whether the resources contained in each pack is different from the Green theme. I have found a new server that supports PHP. Once the new website design is complete, it will be going up on the new server and xptsp.filetap.com site will be redirected to the new site so that updating functionality cotinues to work as always. PHP support will mean that the user will be able to manually download updates from the site, as well as provide some flexibility in terms of website content. A forum is not planned to be among the changes to the website.

Jatin Beniwal: I think I've found the problem that you're referring to. I'll upload a new version probably tomorrow. Mr_Smartepants: Thank you for pointing out the problem with the download rate. I've fixed the code so that it shows the proper download rate. What the....? Have you tried rerunning the GUI on another source to see if the SVCPACK folder disappears? Because I don't see anything in the patcher script that would remove the I386\SVCPACK folder.

Okay, I want to let you all know what's going on and what will be happening. My first tests of the translation code consisted of a file from both the French and Dutch version of XP. It was suprisingly successful, with very little issue of transcription of text from one language to another. The spacing and position need to be adjusted, but it actually worked! It took about a third of a second to perform the resource alteration, so I'm guessing probably no more than an extra minute to translate the actual resources to the destination language. Then I tested with the other files that I received, thinking since one file worked, the rest should too! WRONG! Every test failed, mostly because the text was out of order. In the case of the Sysdm.cpl, the script wrecked the resources so bad that recompilation wasn't possible. So, I started looking at the resources themselves, looking to adjust the positioning to the same layout that the Dutch version of XPtsp. I extracted everything and realized how many different files I'd have to go through. This was distressing to me (for some reason) because there are 240+ files that need to be fixed across 5 resource themes! So I pondered this situation.... After discussion with Bober and Fixit, I have decided to seperate the theme-specific elements from the rest of each resource file. It will be mostly the left-side bitmaps that are being added, but it will also include anything that is different from the original Green theme. Seperating the resources like this will allow us to edit the dialog boxes and have it effect EVERY theme without having to edit the same file in every theme. It will also result in smaller update files that will have to be downloaded by the user in order to update their installation, as they won't contain the theme-specific resources. Given all this, you're probably wondering how this will effect the patcher program. Well, first, there are some minor alterations going to happen to the resource integration code, mainly to add another res file to the patching. But Page 6 (Theme Selection) will be modified to download TWO files, the master package and a theme package. The Updating Code will be modified to check both sets of files for updates, as well as handle the transistion from v1.x.x.x and v2.0.x.x to v2.1.x.x. Lastly, versions prior to v2.1.0.0 will only be able to download the new patcher executable because the resource files themselves will have changed significantly. The master package, as well as a theme package, will have to be downloaded before applying the packs.

nice work! hope to see the final version soon!

Link has been fixed! I'll look into it.

What's Changed in v2.0.0.2: - Fixed patching code so that it correctly patches XPNETDG.EXE. - Modified install code so that alternate versions of COMCTL32.DLL are located before patching. - Modified last-minute code so that it finds & patches alternate versions of COMCTL32.DLL. - Page 7 modified to handle up to 7 alternate versions of COMCTL32.DLL. - Page 7 modified for more options on XPtsp program integration into XP source. - Integration: Driver Signing set to "Ignore" to handle unsigned drivers. - Integration: If no WINNT.SIF exists in i386, a WINNT.SIF answer file is created. - XPTSP.EXE is run via SVCPACK when Repatcher program isn't included. - File structure changed so that "Misc" and "Extra" folders are merged. - "Extra\SP3" folder created to handle files that shouldn't be added to pre-SP3 installs. - MSC files, as well as replacement MSTSC files, moved into "Extra\SP3" folder. - Internal function reorganization and streamlined for clarity. - Added code to auto-detect language if none selected. - Vista User Accounts Pictures have been put into it's own add-on. Ever since the notice that there is something wrong when integrating into a XP SP2 install, I've been doing my tests using a Windows XP SP2 install. I haven't seen any BSOD's like with v2.0.0.1, so hopefully, whatever the problem was has been resolved. But I'd say that the problem lies with the SP3 Microsoft Management Console (MSC) files that were integrated. A lot of differences took place between SP2 and SP3 and it's possible that the new MSC files call on some functionality that is present in SP3, but not in SP2, but that's just a guess.... My SP3 detection code declares an install to be SP3 if the kernel is the SP3 RTM build or later that was released. Please, do not ask if the SP3 beta or release candidate versions can also be declared SP3 by the GUI because it won't happen. I am going to start on the translation code. I've gotten some sample non-English files and will be experimenting using them to build non-English versions of the resource files. At this point, the code will be limited to those program files using a non-English language ID. Right now, I'm not sure how I will handle the MUI files installed after XP installation.... Like everything else, I guess I'll figure it out....

Okay, latest poll has been closed. (Yes, I know it's a day late!) Here are the results: I'm not sure how these poll results will influence the GUI at this point, but I'm sure it will....Regarding the GUI, I'm still trying to make the GUI work on a XP SP2 installation without blue-screening the VM. So far, the results haven't been good... This doesn't mean "abandon SP2, all ye!", so don't take it that way! I just thought I'd let y'all know that I'm making progress...

Nevermind....

Well, I've modified the CAD2009 add-on so that the COMDLG32.DLL file isn't copied to the Windows\System32 folder if the installed OS isn't SP3. I think that this might be at fault, but I won't know for certain until I run my next test.... EDIT: Making that modification made no difference.... Something I've noticed during this last test is that the last-minute stuff doesn't happen. Bootscreen wasn't patched, nor was the section in XPtsp.ini populated.... Wonder why....

I created a VM using virgin copy of XP SP2 (no update packs, no add-ons, no patches). With the exception of an array error, the VM behaves properly, as far as I can see. EDIT: Huh, after rebooting, I tried to run the Repatcher proggie within the VM. The VM promptly crashes. Once it rebooted, I tried again. Promptly crashed again.... I'll have to look into this issue because something isn't right about this.... EDIT2: After disabling automatic reboot, I got a blue-screen with this message: This site says that the reason this error occurs is that either the winlogon.exe or Csrss.exe process fails.You can disable automatic reboot by going to Start Menu, right-clicking on My Computer, click on Properties, go to Advanced tab, click on "System startup, system failure, and debugging information" button. Uncheck the "Automatic reboot". Once you do so, please tell me what the error message is. Thanks!

How To Move The Progress Bar In XP (applies to SP2): here Hex values to look for: Top = 62 01 00 00 Bottom = 6A 01 00 00 Left = 01 01 00 00 (Unconfirmed) Right = 78 01 00 00

Huh.... so there is no prompt to reboot? Let me create a VM with XP SP2 and see if I can't duplicate this "situation" you've encountered. No, there's no "special" or custom settings that have to put in. I've run the GUI using the default options for all of my tests. I've tested it on SP3 on all my tests, but there is no reason why it shouldn't run successfully on SP2. Now, one of the modifications that the GUI is forced to do have everything to do with SP3, like the WBEMOC fix. The WBEMOC problem literally doesn't exist in SP2, but is a major pain in SP3 (and I suspect it was deliberately done to annoy those that integrate stuff!) But everything else should work properly on a SP2 install. I have doubts as to whether that will change anything, but if it does, please let me know.

No problem. I doubt that integrating something simple as a theme would hamper the extract. Integrating an Update Pack into an install after XPtsp integration should only cause the system to patch those files that have been updated once the XP source has been installed. Unfortunately, I really am at a loss on how to explain what's going on, because I haven't encountered this issue. Have you tried the latest version? Maybe it'll make a difference....

What's Changed in v2.0.0.1: - LANG: Added "P_30a7" thru "P_30a15" for Control Panel applet "Settings" tab. - Modified "Settings" page from "32,48,64,128,256" to "32,48,64,96,128,256". - Modified "Settings" code to correspond to correct values for icon spacing per icon size. - Added a reboot prompt for icon title wrap, horizontal & vertical spacing changes in "Settings". - Added "Desktop View", as well as "Hide Desktop Icons" and "Icon Title Wrap" in "Settings". - Added disabled "Font" button to "Settings" tab. - OEM Info Generator is run during last-minute patching instead of RunOnceEx. - During last-minute patching, kernel is copied and patched with new bootscreen. - Kernel patching code can now edit progress bar's position on the bootscreen. - Added the black (actually blue copied) and red taskmanager resource files. - Updated XPtsp.ini with Black and Red taskmanager hex edit lines. - GUI patches UXTHEME.DLL and SFC_OS.DLL again. - Integration: File destinations are populated during Windows Setup. - Integration: File timestamps removed from file information in XPtspCom.inf. - Code modified so that files are not unnecessarily copied if no modification needed. - Code modified so that alternate versions of MSTSC.EXE & MSTSCAX.DLL are handled. - Fixed code on Page 10 (ISO creation) so that working folder isn't changed unexpectedly. - Page 6 (Theme Selection) changed to default to Green package. - Adjusted WinFlip.INF to avoid breaking installation. I've been focusing on testing the integration of XPtsp resources into a source folder. The code used to want to patch 336 files immediately after installation of the WinXP source, but the number of files have been reduced to 4 or 5 (MSTSC.EXE, MSTSCAX.DLL, XPNETDG.EXE, COMCTL33.DLL and maybe COMCTL34.DLL). I am still working on trying to fix the GUI to handle these files correctly. Otherwise, repatcher works as expected. EDIT1: Before you starting asking "what is COMCTL33.DLL or COMCTL34.DLL?", let me explain. I'm aware of three copies of COMCTL32.DLL, each with a different version number, filesize, etc. I don't really know what the difference in functionality is, nor do I care. I backup each COMCTL32.DLL to a different name, hence, COMCTL33.DLL for the first "other" copy, COMCTL34.DLL for the second, etc. COMCTL34.DLL may get patched depending on whether the path for the 2nd copy exists. Unfortunately, it seems to differ depending on whether you use and which Update Pack you integrate, so this problem will have to be fixed.... There seems to be two different copies of MSTSC.EXE and MSTSCAX.DLL in the XP source. I don't know why the originals even exist, but the others (LHMSTSC.EXE and LHMSTSCX.DLL) are copied into place.... EDIT2: The code expands the XPNETDG.EX_ to a different filename, which is why the GUI isn't picking up the file information necessary to keep it from being flagged for repatching.

Huh, that's weird.... I really can't imagine a situation where it would fail to create a 0-byte file.... I've been doing a lot of testing on the GUI in the last 2 weeks and it's extremely rare that that particular message shows up, primarily because a FileInstall in AutoIt doesn't usually fail....

No problem. Trying to answer the question "Is it worth trying on greek version": Maybe. It depend on whether you want to read English.... I can say that once multi-language support has been built-in to the GUI, my answer changes to YES! Frankly, I don't know what the net result would be of applying the English resources to a non-English system. I suspect you will find that the English version of the dialog box would appear completely different than the Greek, and I'm not talking about the language, either. Was the original language of your version of XP in German or English? Curious to know....

I understand what you are saying. Let me see what I can do in the GUI.... no promises. However, I can tell you now that the batch file will never be able to do either of your requests. The GUI may be able to.

Everybody: I've posted a new poll asking the question "When installing XP on your system, do you have to install a MUI pack in order for your language to be supported?".... Please answer even if your language is English. Thanks! Bober: Thanks!

stsaerox: I'm sorry. I agree that it's hard to correctly construct ideas using words so that everybody (including myself) understands. If I knew how to make it "stringable", then I'm sure that it would be made that way. I looked at the original English language ACCESS.CPL in Reshacker, searching for "clues" on how to do so. All I found were dialog boxes and string tables with English text. There was no other language strings in that file. I also downloaded the Greek MUI package that you linked to and extract the contents of it. I looked in the ACCESS.CPL.MUI file using Reshacker and found both dialog box and string tables, all of it in Greek. There were no other language strings in that file, either. Naturally, this is a surprise to me. I had assumed that each file contained enough "info" to represent it for each language. I was WRONG! Given this new information, I assume I would have to integrate the changes into each MUI file I could find on the system.... I see no way to integrate the MUI files into the XP source, which in a way is a relief because it's less than I have to check for, but still.....

Qwesta: I quite agree that support for multilanguage would be great. stsaerox: Since you seem to know so much about this particular topic, please demonstrate how to do so. If the method you show me is reproducable via AutoIt, it will be incorporated into the GUI.