Jump to content

XPtsp GUI v3.0.0.26 - February 27, 2012


dougiefresh

  

46 members have voted

  1. 1. What language OS do you use XPtsp on?

    • English
      28
    • non-English
      12
    • Both English and non-English
      6

This poll is closed to new votes


Recommended Posts

GUI_Header.png

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.

download.png

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

Link to comment
Share on other sites

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:

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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 ? :blink:

Link to comment
Share on other sites

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 by dougiefresh
Link to comment
Share on other sites

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:

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

:o 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..... :blush:

Link to comment
Share on other sites

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 by amnesia
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

×
×
  • Create New...