Zorba the Geek

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.

Deleted

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.

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.

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

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.

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|1 because hsf_fsks.sys is not updated with the POSReady update and the line is garbled and does not do anything.

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 HexEdit

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_MTP but 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_4003 Windows 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"

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|9090 If entries are removed from syssetup.inf and syssetup.dll is not patched the installation is halted due to a fatal error with these messages: 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|EB The 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.

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.

Redacted

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?

Surely the ssudmtp.inf file should contain a generic MTP device descriptor of the form MTP, USB\MS_COMP_MTP so 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.

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.dll As far as I can tell these addons do not have a problem with multiple cat files for one updated file.

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.

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.

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.

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

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.

Have you checked the checksum of the downloaded addon against the checksum published? Which file hosting service did you download it from?

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\KnownDLLs which 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,00 The 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.

This could be remedied by making an entry in mpc-hc.exe.manifest pointing to the correct comctl32.dll in the WinSxS folder. I used Nirsoft's Search My Files to search for files named *.manifest for an example of how this could be done. Here is such an entry in the file ncpa.cpl.manifest: <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" publicKeyToken="6595b64144ccf1df" language="*" processorArchitecture="*"/> </dependentAssembly> </dependency> I assume that the file is searched for using it's public key token

The Checksum does not appear to change from the value set in the Optional Headers section of the header, so this integrity check must be based on something else. I have tried creating manifests to redirect API calls to the Windows kernel32.dll to the One Core API version in the local directory for mpc-hc v1.7.13.112, and the same thing happens. The program begins to load and then it closes. Here is the manifest named kernel32.dll.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="kernel32.dll" version="6.0.6000.16386" processorArchitecture="x86"/> <file name="kernel32.dll" hashalg="SHA1"> </file> </assembly> Here is the manifest named mpc-hc.exe.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="mpc-hc.exe" version="1.7.13.112" /> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="kernel32.dll" version="6.0.6000.16386" processorArchitecture="x86"/> </dependentAssembly> </dependency> </assembly>