dougiefresh
-
Posts
762 -
Joined
-
Last visited
-
Days Won
8
Content Type
Profiles
Forums
Events
Posts posted by dougiefresh
-
-
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.
LOL, while downloading the "green.7z" package, the download speed was REALLY wrong.
It was showing between 3 and 5 kb/sec when in reality it was cruising close to 1 MB/sec.
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.The entire contents of i386\svcpack\ have been deleted! -
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!link is broken..
I'll look into it.Can we have IE8 Tweaks Addons. Please. -
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....Q: When installing XP on your system, do you have to install a MUI pack in order for your language to be supported?- Yes (3 out of 14) - 21.43%
- No (11 out of 14) - 78.57%
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....
-
might be a comctlc32 problem.
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.STOP: c000021a {Fatal System Error}The Windows SubSystem system process terminated unexpectedly with a status of 0xc0000005 (0x75e9ad23 0x0052fa160)
The system has been shut down.
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.thanks sir again for giving me ur valuable time... i hv downloaded the latest version (XPtsp_v2.0.0.1_GUI.exe) yesterday and installed it in my running WinXP SP2. everything was smooth during installation process.... but after first reboot its continuously rebooting automatically after every Boot.... :shy:then i had to setup a new Windows...
Was there any special/custom settings that have to put down? tx again sir...TC
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'm fairly certain the live install requires SP3.
I have doubts as to whether that will change anything, but if it does, please let me know.ohh tx sir ..... i ll surely update it to SP3 before installing XPtsp_v2.0.0.1_GUI.exe -
thanks sir for ur reply... i have preinstalled VistaVG Theme... is it hampered the extraction or something else?... im noob in this area :doh: .. so plz help me... I Love the Total Theme....TC
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.
-
Getting an error messege showing the following when installation progresses...
ERROR: Unable to Extract " COMCTL33.DLL.RES"!
Could someone plz help me in this regard?
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.Is it worth trying on greek version of windows or it is just in english, nothing changes?
Was the original language of your version of XP in German or English? Curious to know....I have tired this on a German version, all seems to work except the boot screen never gets patched( no wonder though , it has a different IDs, majority of the files are well done,) -
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!
-
I never said that I know how to make it. Instead I would have already made that and given this to you ready. I really hate "words". I think that the only part I could work is giving to you the transalated in greek. I believe it is a hard work to do and I thought that If you fix the stringable part then more and more members could help you to make this multilanguage. just theory... don't really know... As a "member" from my tests I could see that stringable part is on the resourses because my mui did not transalate it just like it does on the original.
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.I do agree with you on this point, a multilanguage version will 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.I also believe that it won't be so difficult. I think that this only needs to be fixed is the part that makes the resourses stringable. In an unattended installation of english xp and preferred language's mui then it will transelated automatically and it would be easier to transalate in different languages by changing the strigable part with the default. -
The thing that bothers me right now is my inability to track down an apparent "bug" in the GUI. What happens: After OOBE, the GUI scans the files to see if anything needs repatching. At this point, it should exit without patching anything, after all, I had just installed the OS and haven't even updated it. But it wants to patch 336 files immediately after OOBE. Isn't this crazy? I think so.... As soon as I figure out how to solve this issue, I'll be releasing v2.0.0.1.
But here's the current changelog for the next version:
- 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.EDIT: I've compared the file information the GUI is putting into the registry before and after OOBE. I've found the only difference is a lack of timestamp info for most files. It was removed so that differences in time zones won't play into the GUI's decision to repatch a file. So I'm gonna add the timestamp during last-minute processes. However, I'm confused on how a file can be one size before XP installation and larger after installation.... and one at least two files, the version numbers aren't even the same! If anyone wants to take a shot at this question, any insights would be appreciated.... (Integration performed on virgin XP SP3 install, no add-ons or updatepacks)
EDIT2: A thought just occurred to me about the different version numbers (and possibly sizes) for files.... Obviously, a different file than the one I patched and recorded info about has been copied to the hard drive.... I've deleted the differences info, so I can't go back and research these files. But I will after my next test of the GUI, which will be tomorrow....
-
-
Does this mean that you will make it stringable like the originals?
If the original files aren't "stringable", then it's not likely that these resources will be made like that. It would require that the MUI files be present and it's not the function of either the GUI or the batch versions to add those files.
I strongly suspect that the MUI pack also installs the "stringable" system files, although I have no personal experience with this and cannot test without a link to the MUI pack. Neither the GUI or the batch version can detect this situation and would replace the original resources that the files contain with XPtsp'ed English resources, thus making it non-"stringable". It is the intention to develop a method to "translate" the resources into language-specific resource files based on the strings in the original file, however, it has yet to be started on and may never see the light of day....
..... i ll surely update it to SP3 before installing XPtsp_v2.0.0.1_GUI.exe
XPtsp GUI v3.0.0.26 - February 27, 2012
in XP Theme Source Patcher
Posted
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.