Zorba the Geek
Content Type
Profiles
Forums
Events
Posts posted by Zorba the Geek
-
-
On 5/11/2025 at 9:33 PM, seahorser said:
On MSAgent_DeleteAddon.7z at Entries_MSAgent_DeleteAddon.ini file the line TXTSETUP.INF|52 = msagent||1 should be TXTSETUP.SIF|52 = msagent||1 and TXTSETUP.INF|53 = msagent\chars||1 should be TXTSETUP.SIF|53 = msagent\chars||1 as there is no TXTSETUP.INF.
Then there is no need for rd /q /s %SystemRoot%\msagent line on MSAgent.bat
Also what is that [Obsolete_Entries] section? As far I know there is no such thing and deleting that whole section produce exactly the same resuts.
On Agnt_rem.inf the [NLS.DelReg] section can be deleted as [ExtraFileEdits] from Entries_MSAgent_DeleteAddon.ini can perfectly delete double lines.
eg. to delete the following lines from HIVESYS.INF:HKLM,"SYSTEM\CurrentControlSet\Control\GroupOrderList","SCSI CDROM Class",0x00030001,\ 02,00,00,00,01,00,00,00,02,00,00,00 On [ExtraFileEdits] section type the following in one line: HIVESYS.INF|HKLM,"SYSTEM\CurrentControlSet\Control\GroupOrderList","SCSI CDROM Class",0x00030001,\<NEXT>02,00,00,00,01,00,00,00,02,00,00,00<NEXT>||1
<NEXT> is used to proceed to the next line, and the last <NEXT> is used to delete the last CRLF, so the resulting file won't have holes/empty liines. Be carefull to include leading/trailing spaces exactly as they are from your source HIVESYS.INF or include successive lines both with spaces and without spaces, if the source file previously exported form nlite.
Also wrong is the line which contains Arabic|INTL.INF| which must be Arabic| on Entries_MSAgent_DeleteAddon.ini file and those traling tabs must be deleted from the same "arabic" line.
Thanks for bringing the errors to my attention. In particular txtsetup.inf was a blooper that I should have spotted before releasing the addon.
Of course removing entry 52 from WinntDirectories in txtsetup.sif should make a post install deletion of the msagent folder unnecessary. However, these folders for Windows components seem to be impossible to remove because they are locked by winlogon.exe.
There is an Obsolete_Entries section shown in the RyanVM topic Defining Entries.ini. It's description is "This will delete the entries from dosnet.inf and txtsetup.sif that correspond to file names". There should not be a need to include this section with Obsolete_Files which is supposed to delete entries from txtsetup.sif and dosnet.inf. My investigation revealed that Obsolete_Files does not remove lines from dosnet.inf and txtsetup.sif, but rather marks these lines to be skipped during setup. I have also discovered that Obsolete_Files does not always do this as intended and file copying is halted with a message that a file cannot be found. I now no longer include all the file names in Obsolete_Files with the underscore to denote the cabbed version in the i386 folder
I tried doing what you recommended for deleting double lines from HIVESYS.INF, but I could not get it to work. My conclusion is that the <NEXT> tag in ExtraFileEdits is only intended for the revised entry and not for the entry they replace.
AGT.HLP.LGFiles.Arabic|INTL.INF should have been entered as AGT.HLP.LGFiles.Arabic. Another blooper, but not as bad as the first one. This could have happened because of a careless use of the find and replace function in a text editor. Sometimes if you click Replace All things are replaced that you don't want to be replaced. One possible solution is to mark the replaced text under Notepad++ so that you can see at a glance what has been replaced.
There are no trailing spaces in the line including AGT.HLP.LGFiles.Arabic, but there are trailing spaces elsewhere such as INTL.INF|AGT.DLL.LGFiles.Arabic = 10,msagent\intl||1. I always include the spaces as they are on the original line just to be on the safe side, although it probably makes no difference.
0 -
I wonder if people could share their experiences of getting port forwarding to work under OpenVPN. First I would like to emphasize that port forwarding in a router using the usual rules does not work under OpenVPN and attempts to make it work using iptables to manipulate the routing table under DD-WRT, for instance, will probably reveal you IP address which defeats the whole purpose of using a public VPN.
I have finally succeeded in getting port forwarding to work using PureVPN after they revamped their VPN servers and provided a number of servers dedicated to port forwarding. You have to buy a port forwarding addon in your members area of their website, and then obtain the appropriate OpenVPN config files from the Manual Configuration section of your members area. The selection of config files can be filtered by various types including QR (Quantum Resistant), P2P, OBF (Obfuscation*), and PF (Port Forwarding). P2P is basically port forwarding by servers in countries with permissive policies about file sharing.
There is no need to configure NAT port forwarding in your router, but you do have to open this port in the firewall. The problem with this is that the TAP Windows Adapter is assigned a new IP address by the OpenVPN server every time you log in so you have to enter a probable range of IP addresses from the pool reserved by the server. I monitored the IP addresses assigned to my TAP Windows Adapter by the Netherlands server and entered a range of destination addresses in the firewall between 172.111.247.1 - 172.111.247.224.
I use the PFPortChecker tool to verify that the port is open.
*Obfuscation masks VPN traffic so that it looks like regular traffic and stays hidden from anybody trying to detect it.
0 -
On 8/15/2007 at 5:15 AM, ricktendo said:
OK I know this is an old post but just for the purposes of documentation and getting this on the record this worked for me in my addon
[DefaultInstall] AddReg = RunOnce.AddReg [RunOnce.AddReg] HKLM,"%RUNONCE%","CapOCR",0,"RUNDLL32 advpack.dll,LaunchINFSection CapOCR.inf,Cap.Install" [Cap.Install] RunPostSetupCommands = Cap.Setup [Cap.Setup] CMD /Q /C CD """%16422%\%USD%""" & CapSetup.bat [Strings] USD = "Utilities\USDownloader"
I am struggling to make RunPostSetupCommands work with my addons, but I cannot see how this could help me. I cannot see the point of the triple quotation marks. I know that double quotation marks prevents the expansion of a string token, but if that is the intention I cannot understand how the command could run.
0 -
-
After some experimentation I have concluded that this problem is caused by data corruption at one of the stages before Windows is installed in a virtual machine. Repeating all these stages for my addon resolved the problem. Here are the stages that need to be repeated:
- copy contents of INF and INI files in addon/update pack to Notepad and save them from there
- Build new 7z or CAB archive
- Copy Windows source from from ISO
- Use Poweriso or similar to build the ISO rather than the built in ISO maker in the integrator.
1 -
I am one of three people that I know of who are still creating update packs and addons for Windows XP, and the framedyn.dll/srclient.dll not found error is a recurring problem during the development of my addons that I have never been able to get to the bottom of. When I do make changes that fix the problem I cannot remember what I did to make it go away.
According to setuperr.log srclient.dll could not be registered because a specified module could not be found. This means that there is a missing dependency, which in this case is framedyn.dll. In fact framedyn.dll has not been copied to System32 for some reason In txtsetup.sif framedyn has not been assigned a destination directory which means that it's destination is defined in an INF file, but I have searched all the XP INF files using Notepad++ and it is not there, so what controls it's copying to System32 is a real mystery. Also msjava.dll is missing in the dependency tree, but it is not included in I386 or a standard XP installation.
The same issues apply to dgnet.dll not being registered.
eventcls.dll and swprv.dll were not registered and the only missing dependency is the non existent msjava.dll.
According to setuperr.log mofcomp.exe could not be registered and investigation shows that it is not present in the wbem folder.
I have received exactly the same setuperr.log entries multiple times during the development of various addons with the same missing shortcuts and missing wbem modules, which suggests that there is a single cause each time.
0 -
On 2/9/2025 at 11:55 AM, AstroSkipper said:
I have looked at the documentation for disabling programme updates. Supposedly, there is an option with the entry:
Did you really try this switch?
All I can see in your screenshot is a switch for automatic definitions updates, but there ought to be a switch for automatic program components updates. I opened a ticket with Adlice and this is the latest reply I have received
QuoteWe will take a look at the XP problem, but there's a big chance 15.17 isn't working on XP either; At least speaking for Real Time protection.
1 -
On 12/17/2023 at 2:58 PM, XPerceniol said:
Please also don't forget about rogue killer that still supports XP
https://www.adlice.com/roguekiller/
i have it on my system and I has in the past found malware that I was not aware of. I don't use the "Real Time" (they offer "Real Time" )but only the portable "On Demand" free scanner because I can not afford to purchase any license right now and it just works. You have the option to select a trial for personal use that will last for 1 month but that can be reset by a simple reedit and removal of all traces, but I don't do that anymore and I allow the nag to upgrade but my machine hasn't been infected in ages now because I usually look at the same old mundane nonsense every day. Ha!
I hope that at least gives folks another option.
I strongly urge everyone not to buy Rogue Killer because it is complete rubbish. I could see no information about system requirements on their websites so I went ahead and downloaded the latest version 16.0.1.0 but it would not install under XP. A Google search soon located version 15.17.4 whose installation triggered DEP notices even though it has been set for essential Windows and Services. I selected open the program after installation but nothing happened, and when I opened it from the start menu it triggered another DEP notice. Buying a one year license and activating it went without problem. I then made the mistake of upgrading to the latest version of Rogue Killer which has been rebranded as Adlice Protect. This resulted in my license being deactivated, so I had uninstall the application. I then tried to install the last version of Rogue Killer before rebranding which is version 15.19.2.0, but as soon as installation finished it started to update program components to version 16.0.1.0 and I was back to where I was before with an invalid license. After uninstalling Adlice Protect I tried installing version 15.19.2.0 with my internet connection disabled, but I was unable to find a setting to disable program updates. I reconnected my internet connection.but with the license correctly activated I was still in trial mode. I uninstalled the application again and went back to version 15.17.4.0 but even with the license properly activated real-time protection and ransomware protection were disabled and there was a notice in the account section of the application saying these protections are not available in portable mode. Also I was unable to log off or shutdown Windows with Rogue Killer installed. At this point I gave up and uninstalled Rogue Killer for the last time.
I must have wasted two hours on this rubbish, but at least it only cost me 14 euros. A message has been sent to Adlice.
3 -
On 1/25/2025 at 1:39 AM, flanter21 said:
To fix this, you have to change entries_POSUpdates.ini in OnePiece_WinXP_Embedded_Post-SP3_True_AddOn_ENU.7z from
;Prevents Windows Setup copying drivers from driver.cab that the integrator failed to update drvindex.inf|ks.sys||2 drvindex.inf|termdd.sys||1 drvindex.inf|hsf_fs|hsf_fsks.sys|1
to
;Prevents Windows Setup copying drivers from driver.cab that the integrator failed to update ;drvindex.inf|ks.sys||2 ;drvindex.inf|termdd.sys||1 ;drvindex.inf|hsf_fs|hsf_fsks.sys|1
For some reason, messing with driver stuff makes nlite weird.
I see that you have used the POSUpdates.ini from my XPSP3_QFE_POSReady_Addon in the OnePiece_WinXP_Embedded_Post-SP3_True_AddOn_ENU which, for some strange reason, includes an entries_EOL.ini file with only the General section. I cannot remember why I included the line
drvindex.inf|hsf_fs|hsf_fsks.sys|1because hsf_fsks.sys is not updated with the POSReady update and the line is garbled and does not do anything.
0 -
On 1/30/2025 at 9:33 PM, ppw said:
Is it OK if I use Ryan's Integrator on the vanilla image, and then use nLite on the resulting image?
I don't know the answer to this question for certain, but problems have been reported when nLite has been used first on a Windows source before using the RyanVM Integrator, possibly caused by the extensive changes and deletions to Windows INF files along with the addition of new files that change the setup routine. Therefore you are less likely to have problems if you use the RyanVM Integrator first on a Windows source before using nLite.
Here is a list of the directives in the Integrator that are not supported by nLite:
obsolete_files
old_sysoc
removable_cats
WinntSif
FileCopy
FileMove
DirCopy
DirMove
FileDelete
DirDelete
RunFile
HexEdit0 -
I have examined an XP installation that has the WPDMTP driver included with WMP 11 and it includes two INF files - wpdmtp.inf and wpdmtphw.inf. wpdmtp.inf only contains a generic MTP device descriptor of the form
MTP, USB\MS_COMP_MTPbut wpdmtphw.inf is a supplement to wpdmtp.inf which includes a number of device descriptors for cameras/camera phones available in 2008 which are MTP compliant but do not present to Windows the generic MTP device descriptor shown above, A typical example would be
;iRiver PMC %GenericMTP.DeviceDesc%=MTP, USB\VID_1006&PID_4003Windows 7 may have a similar INF file with more up to date entries for device descriptors, including one for your Samsung A55. You could obtain the Device Instance ID for your for your Samsung A55 and use it to insert the device descriptor into wpdmtphw.inf, but this would probably not work because the "needs" and "include" directives do not seem to work under XP. Instead include these entries in wpdmtp.inf
[Manufacturer] %MfgNameVendorModel%=VendorModel.NTx86 [VendorModel.NTx86] %MTP.DeviceDesc%=MTP, USB\VID_xxxx&PID_xxxx [Strings] MfgNameVenderModel = "Standard MTP Compliant Device" MTP.DeviceDesc = "MTP Device"0 -
Back again. I have tested Harkaz's syssetup.dll patch and I must say that it seems to be perfectly suitable for my XP addons that remove Windows applications like Outlook Express. I did reproduce the syssetup.dll patch created by nLite, and although it makes more extensive changes it does cause problems.like syssetup.dll and sfcfiles.dll sometimes being flagged as modified in setuperr.log and the installation being halted because the battery driver had not been copied to System32. Here is the nLite patch adapted for addons
[HexEdit] I386\syssetup.dll|5.1.2600.5512|328|DC27|10A9 I386\syssetup.dll|5.1.2600.5512|211780|56565656|33C0EB29 I386\syssetup.dll|5.1.2600.5512|212461|8BFF558BEC|33C0C20400 I386\syssetup.dll|5.1.2600.5512|360769|7507|9090If entries are removed from syssetup.inf and syssetup.dll is not patched the installation is halted due to a fatal error with these messages:
QuoteAn error has been encountered that prevents Setup from continuing. Setup failed to install the product catalogs. This is a fatal error. the setup log files should contain more information.
Error: The signature for Windows XP Home Edition Setup is invalid. The error code is 800b0100. No signature was present in the subject.
The Harkaz patch without the checksum in the header being updated will result in the halting of the file copy stage with this message:
The file syssetup.dll was not copied correctly. The file Setup placed on your hard drive is not a valid Windows XP system image.The patch has to be combined with the updated checksum at 0x0148 like so:
[HexEdit] I386\syssetup.dll|5.1.2600.5512|329|27|9E I386\syssetup.dll|5.1.2600.5512|211835|74|EBThe Harkaz patch did not produce errors in setuperr.log, but there were errors in setupapi.log about unsigned or incorrectly signed files. Perhaps the Mr Dusha patches were meant to remedy this. Also this patch did not cause the installation of the battery driver to fail.
0 -
Here is my interpretation of Mr dUSHA's patch for syssetup.dll as it would be implemented for the RVM integrator:
[HexEdit] I386\syssetup.dll|5.1.2600.5512|211753|73|EB :????????? (33B29) I386\syssetup.dll|5.1.2600.5512|212480|39|85 ;Disable Syssetup.inf protect (33E00) I386\syssetup.dll|5.1.2600.5512|212481|5D|DB ;Disable Syssetup.inf protect (33E01) I386\syssetup.dll|5.1.2600.5512|212482|08|90 ;DefaultDrvSignPol = 0 (33E02) I386\syssetup.dll|5.1.2600.5512|357631|74|90 ;DefaultDrvSignPol = 0 (574FF) I386\syssetup.dll|5.1.2600.5512|357632|07|90 ;DefaultDrvSignPol = Disable (57500) I386\syssetup.dll|5.1.2600.5512|371506|46|0D :Disable SFC files scan in T-8 (5AB32)As the two entries for Disable Syssetup.inf Protect are adjacent to each other in offsets 212480, and 212481 they can be combined like so:
I386\syssetup.dll|5.1.2600.5512|212480|395D|85DB ;Disable Syssetup.inf protect (33E00)More from Mr dUSHA can be found using a translation in 360 Chrome here.
0 -
-
I am glad that you have raised this issue because I have been struggling to pipe DASH streams to MPC-HC using the latest youtube-dl and yt-dlp from the commandline. When I have time I will give your batch scripts a try.
Do you realize that MPV 0.35 has been backported to XP by Maroc at MDL?
0 -
Surely the ssudmtp.inf file should contain a generic MTP device descriptor of the form
MTP, USB\MS_COMP_MTPso there should be no need for the vendor's VID & PID.
Also if the device is MTP compliant it should be automatically installed using the generic MTP device descriptor in wpdmtp.inf.
When I have installed WPDMTP from a suitable MTP compliant device there was no need to install the device's drivers. Perhaps the Android device has to be switched into debug mode or developer mode before Windows can detect it.
0 -
I am currently developing addons for XP that remove Windows applications like Outlook Express and they all have the missing battery driver problem if I remove entries from syssetup.inf and patch syssetup.dll. Rather than identify the root cause of the problem I do a workaround that involves copying the batt.dll file from the i386 folder to System32. Here are the relevant entries OE_Rem.inf:
[OErem] CopyFiles = Battery.File [SourceDisksNames.x86] 1="Setup Files","WIN51",,"i386" [SourceDisksFiles] batt.dll = 1 [DestinationDirs] DelINFs = 17 Battery.File = 11 Cleanup = 10 [Battery.File] batt.dllAs far as I can tell these addons do not have a problem with multiple cat files for one updated file.
0 -
All you have to do is copy batt.dl_ from the i386 folder to System32 and unpack this cab file using the expand command, Why some nLited installations do not have batt.dll is a mystery considering that there is an entry for batt.dll in txtsetup.sif. This is a problem I am tackling with my addons to remove Windows applications from XP. It only occurs in those addons that delete entries in syssetup.inf and patch syssetup.dll.
Sorry if nLite related post ended up here.
0 -
I am one of three people that I know of who create addons and update packs for Windows XP in 2025. After having tested my addon to remove WMP9 in a virtual machine I noticed spurious bitmaps in the Windows folder which correspond to the files diesel_98a deletes using the commandline. I am baffled as to how they got there or where they come from because they are not listed in txtseup.sif and they are not on the install CD. I suppose I will have to add entries in the inf file of my addon to clean them up.
0 -
On 12/26/2024 at 5:02 AM, MilkChan said:
Your Google Drive but I tested it and the problem only occurs in nLite not RyanVM.
I integrated XPSP3_QFE_UpdatePack_20220212_Home.7z and XPSP3_QFE_POSReady_Addon_20200820_Pro.7z in an XP Pro ISO. It installed on a virtual machine without problems. nLite is not recommended for any update packs and addons.
0 -
I have just installed Glarysoft's Malware Hunter and bought a license, and I must say this is one of the most basic AV applications out there. All it does is real time and on-demand scanning using definitions. No scanning of boot sectors, no heuristics or HIPs, and no anti ransomware. At $26 dollars for a years subscription it is half the price of ESET NOD32 AV, but RogueKiller is only an incredible $15 and it has more features. In it's favour it only consumes 79.3 MB on your hard drive once you remove the language files, but memory usage of MalwareHunter.exe is a whopping 152.468 MB
0 -
I have done some research, and it seems that Microsoft will permit you to create your own side-by-side assemblies in the WinSxS folder, but the custom dependencies have to be digitally signed, and you have to generate a public key token. The whole process looks complicated to me. If it could be successfully be done we could place our One Core API DLLs here without modifying the operating system or applications at all. All that would be needed is a simple text file in the same folder as the application's program file.
0 -
On 12/9/2024 at 1:40 PM, MilkChan said:
Have you checked the checksum of the downloaded addon against the checksum published? Which file hosting service did you download it from?
0 -
On 12/16/2024 at 4:49 PM, ED_Sln said:
I do manifest a little differently, I have it in two parts, and the dlls that are loaded are in a separate folder. Using mpc-be as an example. The first file is called mpc-be.exe.manifest and is located next to mpc-be.exe its contents:
The second share.manifest is located in the "share" folder along with the dll, its contents:
I tried this with mpc-hc v1.7.14.x86 and to my utter amazement it actually worked!. The Microsoft documentation does not disclose this approach, but you can read an answer to a question at Stackoverflow which does suggest this technique here.
Here is my mpc-hc.exe.manifest
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="share" version="1.0.0.0" processorArchitecture="x86" /> </dependentAssembly> </dependency> </assembly>
here is my share.manifest
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity type="win32" name="share" version="1.0.0.0" processorArchitecture="x86" /> <file name="kernel32.dll" /> <file name="kernelbase.dll" /> <file name="ntext.dll" /> </assembly>
It appears that the presence of an application manifest redirecting API calls to a custom version of a system DLL like kernel32.dll will override the entry for kernel32.dll in the registry key "KnownDLLs".
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLswhich places System32 at the top of the search order for those DLLs listed there. Therefore there is no need to place an entry for kernel32.dll in the registry value "ExcludeFromKnownDLLs".
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager] "ExcludeFromKnownDlls"=hex(7):00,00The next step could be to make the assembly a shared assembly available for all applications that may need it by placing it in the WinSxS directory, if that is permitted. It could be that only GDIPLUs, Shell Common Controls, and Visual C++ Run-time Libraries are the only supported Side-by-side assemblies.
0
My Windows XP OS Addons and Update Pack (2023)
in Application Add-Ons
Posted
I have finished a second version of the Obsolete Drivers Removal addon which has had rigorous checking to ensure that no essential drivers installed during setup are removed. I have also retained legacy drivers required bu VirtualPC and Virtualbox. The Vmare Player and Workstation install their own drivers rather than use those in the Windows installation. I have ceased to use the Harkaz syssetup.dll patch because it prevents the %OEM% folder from being fully processed.
File: Drivers_Removal_V2_Addon.7z (Dropbox)
File: Drivers_Removal_V2_Addon.7z (Google Drive)
File: Drivers_Removal_V2_Addon.7z (4Shared)
MD5: 8173FA7A1381AA0B0ABAD59D19C1753B
SHA-1: 484DDDD00789191657720797919359EC67F285FC
SHA-256: 534C363B6578B341BACD69BFCC273D6E217E86C15A3823CAA6B9753F658F9BB6
Release date: 22/06/2025
Size: 376 KB