Zorba the Geek

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.

Maybe you should try the Lentoid decoder again on your current Pcs, and share the results with us. When using it with my low power Core2Duo setup the statistics panel in MPC-HC showed no dropped frames, although it was not as smooth as I would like. Others following this topic should give it try and report back. Possibly the only option for XP users is to use a PC with the highest performance CPU whose drivers can be installed under XP and do h265 video decoding entirely through software. Does anyone know what is the highest spec CPU that can be installed under XP?

DXVA for h265 requires DirectX 11 which is out of the question for XP, so I wonder why people are uploading screenshots from the DXVA Checker program. Here is the alternative options: Sixth generation PureVideo HD Supports partial hardware decoding for H.265 FHD. Hybrid CPU/GPU decoding. Microarchitecture: Maxwell Chipset: GM107 Models: GTX 745, GTX 750, GTX 750 Ti, Supports 368.81 driver for XP: Yes Seventh generation PureVideo HD Full hardware decoding of VP9 and HEVC (Main and Main 10) video Microarchitecture: Maxwell 2nd generation Chipset: GM206 Models: GTX750 SE, GTX 950, GTX 960 Supports 368.81 driver for XP: Yes NVDEC (formally CUVID) Full hardware decoding H.265 (HEVC) 4:2:0 profile, 8 bit and 10 bit Microarchitecture: Maxwell 2nd generation Chipset: GM206 Models: GTX750 SE, GTX 950, GTX 960 Supports 368.81 driver for XP: Yes The only media player for Windows that supports nvdec that I could find is versions of mpv since 2017 which are not compatible with XP. However, the version 0.35 of mpv released by Maroc at MDL here does provide the option --hwdec yes, and --hwdec-codecs hevc. There may be versions of ffplay that could support hardware acceleration with the commands ffplay -vcodec hevc_cuvid, and ffplay -hwaccel cuvid PureVideo HD is supported by MPC-HC, WMP, VLC, etc.I am not sure what the settings for hardware decoder to use in LAV would be.

By "work" I mean hardware accelerated GPU processing. Using the Lentoid h265 decoder for CPU processing of h265 is a bit too demanding for my Core2Duo CPU, although it is watchable.

I did not expect my ancient nVidia graphics card to offer hardware assisted decoding of h265. Normally when playing back h265 video on my HTPC there are dropped frames galore and the video is unwatchable. However, using the fast Strongene/Lentoid h265 decoder for CPU decoding the results are almost acceptable, so this decoder may be suitable as a last resort for XP users who have a fast quad core CPU. The Lentoid decoder only works with the Strongene Mpeg-4 Demux, filter, so if using MPC-HC it will be necessary to deselect the internal MP4/MOV source filter. I found that selecting the Overlay Mixer Renderer in the output section, gave the best decoding performance.

Can someone provide a summary of what is required to make h265 work under Windows XP without going into deep technical analysis and speculation. Examples of the information that is required is The minimum specification of video card. The optimum version of nVidia GeForce driver The preferred decoder or is the LAV filters the only option. If so what version? Does CUDA work under XP when playing back h265 video? The preferred video renderer The preferred media player What about AMD Radeon cards? You might like to check out the Strongene H.265HEVC Decoder which is still available through the internet archive here. I was able to achieve almost acceptable results with my GeForce 610 card and the 368.81 driver, although the CPU maxed out all the time.

Microsoft are being a real pain in the a**, so if I want direct download links I will have to migrate to Dropbox and Google Drive. I have started to edit my links to a new Google Drive account, but it is a long job. If any one can succeed with opening a OneDrive account and is interested obtaining direct download links from it here are the instructions which I have tested before they locked me out. OneDrive Sharing URL = https://1drv.ms/u/s!AqnydgOyPCAKbj58b7Xy9guiMuo?e=SaXqa5 Base64 encode = aHR0cHM6Ly8xZHJ2Lm1zL3UvcyFBcW55ZGdPeVBDQUtiajU4YjdYeTlndWlNdW8/ZT1TYVhxYTU= Convert the base64 encoded result to unpadded base64url format by removing = characters from the end of the value, replacing / with _ and + with -.) Example: aHR0cHM6Ly8xZHJ2Lm1zL3UvcyFBcW55ZGdPeVBDQUtiajU4YjdYeTlndWlNdW8_ZT1TYVhxYTU Append u! to be beginning of the string. Example: u!aHR0cHM6Ly8xZHJ2Lm1zL3UvcyFBcW55ZGdPeVBDQUtiajU4YjdYeTlndWlNdW8_ZT1TYVhxYTU Final format = https://api.onedrive.com/v1.0/shares/u!XXXXX/root/content Final direct download link = https://api.onedrive.com/v1.0/shares/u!aHR0cHM6Ly8xZHJ2Lm1zL3UvcyFBcW55ZGdPeVBDQUtiajU4YjdYeTlndWlNdW8_ZT1TYVhxYT/root/content

Microsoft have removed all the content from my OneDrive account, so I have to re-register, upload the addons, and change the links in this topic. What a bummer.

I am not aware of .NET Framework addons derived from POSReady 2009 updates. I did apply updates to .NET after making the POSReady registry hack and it lead to problems, so I did not pursue this approach further. It might be worth experimenting with a .NET Framework addon that includes POSReady updates, but where would I obtain the updates?

MilkChan I noticed that you released an updated version of YumeYao's WMP11 addon at My Digital Life and you list some corrections of errors in the original version 3.4.5. Could you clarify some points for me so that these corrections can be incorporated into my addon? In the registry the build date of KB973540 is shown as 14/07/2009, while the build date shown in the properties of wmpdxm.dll is shown as 13/07/2009. Is this the build date error you were referring to? What is the missing security catalog. There were no errors shown in setuperr.log. What is the fix for ptpusb.inf required for Windows 2003 wpd.inf is not included with WMP9 or WMP11. Why was it supplied as a dummy INF file with only the header? wmp11.cat appears in OnePiece's AIO update pack and the YumeYao WMP11 addon. Is this the .cat file conflict you were referring to? Is the resolution to rename wmp11.inf? mpg4ds32.ax_ and msadds32.ax_ would have the effect of removing these decoders from the system. Is there a reason for this? What are the files essential to the system that were deleted in YumeYao's WMP11 addon? What was the KB973540 string not working properly? What was the issue in version 3.4.1 that prevented mp3 files from playing?