I've created this thread for the discussion of the XP Theme Source Patcher GUI, whether it be bug reports or feature requests. If there is any problem with the GUI, discussion should take place here.

Please keep in mind that the goal of the GUI is to create a GUI for the project, NOT to create or modify resources for it. Both the resources and extras have been seperated from the GUI in order to minimize the download size of the package. Downloading the theme package and extras package will be required in order to use the GUI. If there is any problems with the resources, please report those problems in the appropriate thread, as this isn't the thread to report them in.

UPDATE: Starting with v2.1.0.0, the patcher requires administrative privileges in order to run. I found out that without administrative privileges, any local copies in the same folder as the GUI SFX won't show up.

file: XPtsp_v3.0.0.26_GUI.exe

md5: 32ced219c6e33d9a1c1aa7fc057a7771

size: 1.6mb (1,702,137 bytes)

Official Changelog: here

GUI To-Do List (in order of preference):

- Integrated online Theme management tools

- WINNT.SIF manipulation tab in Additional Options

- ISO Burning ability

- A request to do additional MUI Patching

Notes about the GUI:

- All resources are ENGLISH ONLY! Please don't ask for translations for any languages, as this isn't the purpose of this thread.

- If the archive is put in the XP source folder, the script will pick up the folder that the archive resides in and use it as the default folder. Otherwise, source folder will be blank.

Poll Results:

GUI Version with Translation Code: posted here

cool, im very happy that every one's happy and that they have their own space to work.

What's Changed in v1.4.3.0:

- Updated resources to match XPtsp batch v1.4.3.

- No code changes occurred.

Thanks a lot Dougie (and bober et al), must have add-on.

I do have a question which I should've checked out before, but oh well: I had 1.4.02 and then used 1.4.1 directly over it (i.e. didn't uninstall the first one). Now I see the backups are backups of what was modded. So first question I guess is since I think I have no "backups" (pre-patch), uninstalling it would probably reinstall the version's of 1.4.02, or am I wrong?

And for future reference, should I uninstall the previous? Thanks :thumbsup:

I do have a question which I should've checked out before, but oh well: I had 1.4.02 and then used 1.4.1 directly over it (i.e. didn't uninstall the first one). Now I see the backups are backups of what was modded. So first question I guess is since I think I have no "backups" (pre-patch), uninstalling it would probably reinstall the version's of 1.4.02, or am I wrong?

When you uninstall the GUI, you should end up with pre-patched versions of all files ASSUMING that another version wasn't installed over it. This situation wasn't anticipated, so it wasn't coded for. So, when you installed v1.4.1 over v1.4.0.2, the backups created by v1.4.0.2 were overwritten with the patched files created by v1.4.0.2.

And for future reference, should I uninstall the previous? Thanks :thumbsup:

At the moment, the GUI doesn't have the ability to detect whether another version of the GUI has been installed. That was intended to be part of component selection, a major part which I haven't written yet. So, yes, it is recommended to uninstall the previous version before installing the current version. (Updated first post)

Ok, i see Extra\blue_ss.dll and Extra\home\home_ss.dll

FileMove($XTRA & "\BLUE_SS.DLL", @WindowsDir & "\Resources\Themes\Luna\Shell\NormalColor\ShellStyle.dll", 1)
FileMove($XTRA & "\HOME_SS.DLL", @WindowsDir & "\Resources\Themes\Luna\Shell\Homestead\ShellStyle.dll", 1)

am i missing something or the path for home_ss.dll is wrong in da script ?

No, the path isn't wrong. The script moves the files from Extra\home into Extra prior to patching, overwriting files as necessary. If the file doesn't exist, the filecopy isn't done.

EDIT: I've edited the code so that the original HOME_SS.DLL isn't moved if the replacement isn't available.

Edited January 31, 200916 yr by dougiefresh

No, the path isn't wrong. The script moves the files from Extra\home into Extra prior to patching, overwriting files as necessary. If the file doesn't exist, the filecopy isn't done.

EDIT: I've edited the code so that the original HOME_SS.DLL isn't moved if the replacement isn't available.

thank U and i hope, U understand that i'm just wholeheartedly trying to help :welcome:

thank U and i hope, U understand that i'm just wholeheartedly trying to help :welcome:

You're welcome and thank you for bringing the problem to light.... Please feel free to ask questions if you have any. I appreciate any assistance that can be given.

Thanks a lot dougiefresh

dougie, in next release there be 2 new files to be copyed to a xp pro source :

blue_ss.dll

metal_ss.dll

Okey-dokey! I can easily add those files to the script!

EDIT: Um..... I'm having some difficulty building the compiled script. Something about FileInstall not working, yet the files it's trying to include exists..... I exclude that file, another file is complained about. I remember someone stating that UXTHEME.DLL.RES wasn't being installed on his/her computer.....

EDIT2: Found and fixed it..... I'm just having a "blond day".....

What's Changed in v1.4.3.1:

- Fixed patcher so that hex-edited files are still present in XP source folder.

- Fixed situation where visual theme files were moved when replacement wasn't available.

- Removed Clear_WFS_Message.vbs and JPGtoBMP.exe from the Programs folder.

- Added code to copy BLUE_SS.DLL and METAL_SS.DLL to proper folders when files are available.

- Added code to replace the external JPGtoBMP.EXE program.

- Internalized Clear_WFS_Message.vbs script into compiled script.

- Replaced MAKECAB.EXE and EXPAND.EXE programs using CABLITE.DLL.

- Rewrote CAB building function to use CABLITE.DLL instead of CABARC.EXE program.

EDIT: I'm still finding files going missing during source integration, even with this version. I'll try to track the bugs down and kill them, but it probably won't be today.....

EDIT2: The bug I reported earlier appears to have everything to do with uncompressed original files, as well as the non-English XPSP?RES.DLL files.... I've removed this version from downloading because this version will screw up any XP source folder it is run on....

Update on situation: I've figured out what I needed to do for the uncompressed files. And I also discovered an annoying bug that will keep me from patching non-English XPSP?RES.DLL files. ResHacker will add the resources to those files, but won't overwrite non-English resources..... I've found CAB files don't want to patched anymore..... This is annoying. :censored:

EDIT: CAB file problem was due to files not existing anymore in SP3.CAB, due to previous issue with uncompressed files.

What's Changed in v1.4.3.2:

- Fixed patcher so that uncompressed files are copied instead of attempting to decompress.

- Fixed CAB expander so that it moves files expanded from CAB files into proper folder.

- Code dealing with non-English XPSP?RES.DLL files commented out.

- Fixed code so that XPNETDG.EXE gets patched.

about replacing stuff that dosent have the same lang id,i think ull have to use the delete feature of reshacker then patch. and or determine the lang of the file being patched and attribute that id to the res file or write it batch to the file after its been patched.

lol sorry man i pushed the edit button instead of reply, i cleared you're post by accident..hehe im a moron,

edit:

about deleting a resource and then patching it with the wrong ID res file. i have no idea if the system will complain. about patching lang ID's,i do know restorator is able to do this, but im sure we can find a way to do it with reshacker.specialy since res patcher dosent show a window when using it in command line,restorator does...

here is some info that may or may not help you:

  [COMMANDS]
  -delete   MENU,,0
  -delete   DIALOG,,0
  -delete   STRINGTABLE,,0
  -add	  MyProg_Rus.res, MENU,,1049
  -add	  MyProg_Rus.res, DIALOG,,1049
  -add	  MyProg_Rus.res, STRINGTABLE,,1049

so if u useaddoverwrite and give it the lang code it migh replace the actual item and keep the previous lang id

Well, I didn't like that post anyway..... It asked too many questions! :doh: LOL!

Anyway, I'll try the suggestion with the English resources, cause I'm don't have any Russian ones. See if it works....

EDIT: The resource file has to contain Russian resources in order for those commands to work! :doh: Silly me, thinking it might work otherwise.....

well you should try with neutral contents.

what r U people trying to achive with LangIDs, if i may ask ?

english id is 1033. i don't think Reshacker is capable of changing LangID from command-script and U may end up with two resources with different LangIDs.

Restorator does have -guiless (Do not display main window)

http://bome.com/Restorator/help/help.html#_Toc350126141

btw, it was mentioned on russian forum that xpsp2res.dll is called sprt0419.dll in the source, so i can assume,

other langs will be sprt*.dll... (Fixit can check on his NL source...)

Edited February 2, 200916 yr by amnesia

other langs will be sprt*.dll... (Fixit can check on his NL source...)

i can add this for people who are translating XPtsp:

you can find name changes in layout.inf in xp source folder.

example :"lhmstsc.chm = 100,,111872,,,,,21,0,0,mstsc.chm)"

My finds (in dutch xp)

mstscax.dll = -> "lhmstscx.dll" before install

mstsc.exe = -> "lhmstsc.exe" before install

xpsp1res.dll = -> "sprs0413.dll" before install

xpsp2res.dll = -> "sprt0413.dll" before install

xpsp3res.dll = -> "spru0413.dll" before install

note:

when live patching on live system the files will be named just like the english files...

Extra:

Resfiles with langID: "0" (neutral) on foren xp..

msgr3en.dll.res

srclient.dll.res

setup.exe.res

msi.dll.res

I know that XPSP?RES.DLL are named something else. GUI scans through the TXTSETUP.SIF in order to get the filenames of other XPSP?RES.DLL files. Until I commented it out, the GUI patched those files.

Now, I've got to try to patch other languages, which that ain't gonna be easy (if it's possible at all). I'm thinking that maybe, at some future point, I can transform the dialog and menu resources so that they can take the new form. But I have some challenges there that just won't be easy.... Will this receive attention? Probably, just not soon.....

However, that's for the future. I've got a lot more that demands urgent attention, such as installing a different version of XPtsp over an already installed/intregrated copy of XPtsp....

Amnesia: On my copy of XP, the XPSP1RES.DLL files are named SPRA????.DLL, XPSP2RES.DLL files are SPRB????.DLL, and XPSP3RES.DLL files are named SPRC????.DLL (where ???? is the language ID hexed). The GUI can easily search TXTSETUP.SIF for the proper names of the alternate files, but it's the patching itself that's going to be a problem.....

still i'm lost on the reason of patching different LangIDs when all dialogs patched by XPtsp are in english and customized

Edited February 2, 200916 yr by amnesia

its to eventualy support multilang... i guess