Zorba the Geek

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>

I suppose most of you are familiar with the technique for extending the XP API for a particular program by inserting a custom system DLL in the same folder as the program and editing it's import table so that a file to which it is linked is renamed to that of the custom system DLL. My custom DLL is xpspkernel32.dll from OneCore API 3.03 renamed to kernel32.dll along with it's dependencies ntext.dll and kernelbase.dll. In the case of the McAfee Viruscan CLI scanner v7.02 for Windows 7 this technique cannot work because scan.exe performs an integrity check on itself, and closes with a message saying the executable has been modified. An alternative approach that I thought I might try is to redirect API calls to the system DLL using manifests to make the local folder the top of the search order for loading the DLL Here is the default search order for loading a DLL: The directory from which the application is loaded C:\Windows\System32 C:\Windows\System C:\Windows The current working directory Directories in the system PATH environment variable Directories in the user PATH environment variable Using information provided at this web page I was able to create experimental manifests to study how this can be done. The secret appears to be using a dll-manifest and an exe-manifest that work together. First you must run the Manifest Tool version 5.2.3790.2076 (mt.exe) which can be found in the Microsoft SDK 7.0A in Visual Studio 10 or as a separate download. The path in Visual Studio is C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\mt.exe. the command to be executed in the local folder containing the custom DLL is: mt.exe -tlb:custom.dll -dll:custom.dll -out:custom.dll.manifest In my example it would be mt.exe -tlb:kernel32.dll -dll:kernel32.dll -out:kernel32.dll.manifest The output has to cleaned up by adding linebreaks and indention. Here is the finished result for kernel32.dll.manifest: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <file name="kernel32.dll" hashalg="SHA1"> </file> </assembly> using the example provided by Ove Halseth in the above mentioned article this is the scan.exe.manifest that I used: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity type="win32" name="scan.exe" version="1.0.0.0" /> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="kernel32.dll" version="5.1.2600.16384" processorArchitecture="x86"/> </dependentAssembly> </dependency> </assembly> Executing scan.exe from the commandline causes it to open without error messages and then it closes, so I suppose the technique works, but scan.exe must have built in protection against DLL redirection which is a well known technique for virus writers. Error Messages The procedure entrypoint InitializeCriticalSectionEx could not be located in the dynamic link library KERNEL32.dll This is the error message produced without modifications to the local folder due to kernel32.dll v5.1.2600.7682 not being able to supply the following imports: CompareStringEx GetLocaleInfoEx InitializeCriticalSectionEx LCMapStringEx Generate Activation Context failed for F:\Internet Downloads\McAfee VirusScan CLI Scanner\cls-w32-702-l\scan.exe.Manifest. Reference error message: The operation completed successfully. This is an entry in the eventlog caused by not entering the assemblyIdentity version of the dependency as the version of the custom DLL The system cannot execute the specified program. This error message results from incorrect syntax of the manifest files Notes assemblyIdentity name can be anything assemblyIdentity version can be any four digit number separated by full stops assemblyIdentity name for the dependency must be the file name of the custom DLL assemblyIdentity version for the dependency must be the version number of the custom DLL The manifest files must be the name of the file they are linked to including it's ending Here is an article by Microsoft titled Assembly Manifests that goes into some detail of the syntax required.

I wish to draw the XP community's attention to some really odd XP compatible anti malware solutions developed by enthusiasts called ROSE SWE Security and Antivirus. Here is a list of the scanners that they currently offer. Most of them are currently under development and have been updated in October and November of this year: VirScan Plus for DOS RHBVS - ROSE SWE's Heuristic Based Virus Scanner for DOS and Windows RMS (formerly known as F_MIRC) - Portable Virus Scanner for DOS16/32, Win32/64, WSL2, Linux32/64 Mr2S - Mister Double Scan (discontinued) for DOS AntiLink for DOS and Win32 MemScan - Memory Virus Scanner for DOS ROSE SWE Virus Collector Toolset I would be interested in reading the opinion of Astroskipper and other XP enthusiasts on these strange applications.

I see Malwarebytes Antimalware Premium v3.5.1 is on the list of working antimalware, firewall, and other security programs for Windows XP, but updates for this product ended on 8th August 2024. I was hoping to get two years out of it, so I am disappointed.

Woops! This was a major blunder which I have put right by re-uploading the corrected file. Thanks for pointing this out. In entries_vcrun140.ini I have added a SysPrepOC section for the WinNT6.x True Integrator which may be available at the archived RyanVM forum. The other links have been fixed. The problem with OneDrive links was caused by Microsoft blocking access to OneDrive from my Microsoft account and requiring me to register for a separate OneDrive account. This means that I had to upload all my files again and revise all my links at the forum. The problems did not stop there because Microsoft had recently revised the API for OneDrive and Sharepoint requiring a complicated procedure involving base 64 encoding of a URL to obtain direct download links. To cap it all they locked me out of the OneDrive account at one point because they had discovered suspicious activity within it. Google Drive has also caused problems by flagging my POSReady 2009 update packs for abuse. This has meant that they have had to be transferred to OneDrive with new links in the forum. In comparison 4Shared is completely trouble free and I would recommend their subscription service if they were not blocked in several countries. Microsoft appear to have revised the API for OneDrive again because the procedure for obtaining direct download links using base 64 encoding of a URL no longer works. Here is a temporary fix until someone can figure out how make direct download links from the embed code. Generate a Share link available for everyone like so: https://1drv.ms/u/c/0a203cb20376f2a9/EQTLKt8TXUBEpnJrimnEPQYBAYHWGxYn5CqS4aj8k1TvWg?e=jBfZbh Then replace the last eight characters of the form e=xxxxxx with download=1 https://1drv.ms/u/c/0a203cb20376f2a9/EQTLKt8TXUBEpnJrimnEPQYBAYHWGxYn5CqS4aj8k1TvWg?download=1 With Sharepoint this would result in a direct download link, but with OneDrive you just get the landing page for the file.

This seems really weird. I can only suppose that there is a problem with paths somewhere. You can see a list of Python's built-in search paths using the following command: python.exe -c "import sys;print(sys.path)" This gives the following list for Python 3.8.1350: D:\Python38 D:\Python38\DLLs D:\Python38\Lib D:\Python38\lib\site-packages D:\Python38\lib\site-packages\win32 D:\Python38\lib\site-packages\win32\lib D:\Python38\lib\site-packages\Pythonwin D:\Python38\lib\site-packages\pywin32_system32 D:\Python38\python38.zip D:\Python38\site-packages Here is the list of paths for Python 3.4: D:\Python34 D:\Python34\DLLs D:\Python34\site-packages D:\Python34\Lib D:\WINDOWS\system32\python34.zip D:\Python34lib\site-packages There does not need to be a path for the TCL directory because tk86t.dll and tcl86t.dll are in the root directory along with python38.dll. tk86t.dll and tcl86t.dll have the paths to their libraries baked in at compilation, but if there is a problem you could set these environment variables; set TK_LIBRARY=%SystemDrive%\Python38\TCL\tk8.6 set TCL_LIBRARY=%SystemDrive%\Python38\TCL\tcl8.6 If you have installed Python somewhere other than the root of the system drive you should use these commands: set TK_LIBRARY=.\Python38\TCL\tk8.6 set TCL_LIBRARY=.\Python38\TCL\tcl8.6 I did a test to see if the Tkinter command line (TCL) could be invoked in the usual way using instructions at a site titled Python-Tcl-Interactions First start the Python interpreter by typing python then enter. At the command prompt enter these commands to start an instance of the Tcl interpreter: import tkinter tcl_intrpr = tkinter.Tcl() You can do a test to show that the Tcl interpreter is actually invoked by doing these commands to make a simple calculation: res = tcl_intrpr.eval('expr 12+23') res '35' This proved that Tcl is operating as expected using cmalex's distribution of Python 3.8.1350 for Windows XP.

Where did you get "PATH=C:\Python38;D:\Mingw_61\bin;%PATH%" from? To me this looks odd because the the path to Python38 is in the C drive and the path to Mingw is in the D drive. No wonder you are having problems. I cannot be bothered with virtual environments and all that, so alI I do is run a batch file to set the Python paths and change into the folder containing setup.py. The path to Mingw is set in the Windows registry in this key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment and is usually entered in System Properties/Advanced/Environment Variables. You probably know this already, but for newbies it is necessary to create a file named distutils.cfg in the folder Python38/lib/distutils with these entries: [build] compiler=mingw32 [build_ext] compiler=mingw32 My batch file for setting the Python environment variables is included below: CP38_Env.bat

I am considering making an XP compatible build of Electrum the BitTorrent client as a Windows executable. The whole thing is written in pure Python, so I compilation of C++ code is not required. All the dependencies like pyqt5 are included with the distribution as pure Python code, so I may not need to install them. Perhaps I am being naive, but I cannot see why Python code should be incompatible with XP as long as the the Python interpreter supports XP. Any insights and suggestions would be appreciated.

Without giving notice Microsoft blocked access to OneDrive from my Microsoft account so I had to create a new OneDrive account and start again. With the new OneDrive account direct downloads now involves a complicated procedure involving base64 encoding of the URL, so I opened a Google Drive account and uploaded all my shared files there. I am now revising all the links to my shared files in this forum which is really time consuming. The link that you mentioned has been revised to point to the file on Google Drive.

II have assembled the compiled Python modules and their Cygwin dependencies into a working Python distribution that you may like to try. File: Python Cygwin 3.6 For WinXP.zip (4Shared) File: Python Cygwin 3.6 For WinXP.zip (Google Drive) MD5: 03FE603F49192CC85B5B6A3F25A15E93 SHA-1: 7C22DA570A0ACD653E4AEF772E684B810E135ED8 SHA-256: D6CA468E4FDBB604DECB36EBE664958FA7C8273388A10D03A999EDAD3882A41C Build date: 25/04/2023 Size: 28.9 MB Of course the minimum 3.x Python version required in the latest applications is 3.7, so a new source code would have to be released to make an XP compatible build under Cygwin. I may contact the developer to request a new 3.7 build or else give instructions on how to create a 3.7 source. Note: 4Shared is blocked in the UK. Use VPN servers located in the United States or the Netherlands.

Why are you so certain that the nVidia 368.81 drivers do not support hardware acceleration of h265 video under XP? Have you tried it with a GTX 950 or GTX 969 graphics card, or do you know someone who has? I am asking because experimenting with these cards would involve me in a time consuming, difficult, and expensive rebuild of my HTPC with no certainty of the result. To a naive person like me all the elements for success seem to be there. For instance there are no missing dependencies in nvcuvid.dll. and the 368.1 drivers were built in 11/07/2016, while the GTX 950 was released in 13/03/2015. nVidia have stated that the 368.81 drivers support these two cards. The results obtained by D.Draker and Ed_Sin are discouraging. Using the GTX 750ti card D.Draker observed dropped frames galore, so it did not appear to be offloading some of the the video processing to the GPU. Ed_Sin did actually achieve full hardware decoding with the GTX 950, but the output was corrupted with artifacts. He suggests that changing the renderer to something other than EVR maybe necessary. Possibly successful hardware decoding of h265 using NVDEC requires EVR, which may or may not work under XP, unless you have a backported build of a recent MPC-HC.