All Activity

Yes, there are no more working license keys for My ancient version of Kaspersky. My last license key for My ancient version of Kasperky expired 10 years ago. When I then contacted Kaspersky in the US they informed me that they had no more license keys for My ancient version of Kaspersky for sale, and that I should contact their head office in Moscow, maybe they could sell me one. But that looked a little complicated to me, and I don't need daily updates. My ancient version of Kaspersky is definitely not eliminated. It is a trial version which has NO EXPIRATION DATE, in contrast to subsequent trial versions by Kaspersky, and runs indefinitely without a license key. It has been used nearly daily over the past 10 years, with near-current signatures, without requiring a license key. The limitation of this trial version is that it can be updated ONE time after installation. After the first successful signature update, the update button is greyed-out and doesn't work anymore. Here is the explanation of why My ancient version of Kaspersky is still updateable: I have been making progressive clean opsys/partition backups, since the initial installation of WinXP: step 1) created a clean opsys/partition backup step 2) test-installed e.g. 5 new programs, and e.g. 4 of them were rejected and 1 should be kept step 3) restored the preceding clean opsys/partition backup step 4) made a clean re-install of the program(s) I wanted to keep step 5) created the next clean opsys/partition backup with the new program(s) I wanted to keep etc The benefit of such progressive, clean opsys backups is that the computer stays clean and free of junk. When I made the clean install of My ancient version of Kasperky (step 4), - I installed the program - made all the desired customization settings - created a new progressive, clean opsys/partition backup (step 5), WITHOUT having updated Kaspersky The benefit of creating a progressive, clean opsys/partition backup of Kaspersky, WITHOUT having run the 1st signature update, is that the opsys backup file and all subsequent progressive backups do not get bloated with 700+ MB of signatures. A side benefit of creating a clean opsys backup of My ancient version of Kaspersky, WITHOUT having run the 1st signature update, was that whenever a subsequent progressive opsys/partition backup was restored (step 3), e.g. when making a new progressive opsys backup, a virgin version of Kaspersky was back again, permitting an update with the current signature.. I make progressive, clean opsys/partition backups about every 2-3 months, with new good stuff added progressively. My ancient version of Kaspersky has worked fine for me, even with signatures up to 3 months old. Below are two screenshots of My ancient version of Kaspersky under WinXP SP3, updated last week to the signature of 3Dec2025. The Server edition of My ancient version of Kaspersky also installs, runs and updates fine under Windows Server 2003 on my Inspiron 7500 laptop (Pentium III of the year 2001, 700MHz). Below are three screenshots under Windows Server 2003 of 20Nov2025.

For XP and Vista, you will also very likely need "VMware Tools 10.0.12". They can be found at the Internet Archive - BUT since they seem to also contain items in violation of MSFN forum rules, I feel it best to not "link" them here. Google/Bing/DuckDuckGo for "archive.org vmware player 12.5.9" then do "parent directory" browsing until you stumble upon "VMware Tools 10.0.12". Some people label them as "legacy" or "preVista". edit: have not used, I tend to stick with VirtualBox versions 5.1.22 and 7.0.26 as I have my system configured to use BOTH OF THEM at the same time. I use 5.x for everything except Win11 testing, which needs 7.x (maybe 6.x, don't recall) or higher. and on second thought, the archive.org links "should" be safe to post here at MSFN. according to Wikipedia, VMware has been *FREE* since mid-2024 (news to me, free is why I've always used VirtualBox instead).

Navigating from the link in post #1, FileHippo has versions 15, 12, 6 and many others.

Maybe, just maybe, you are better-served in reaching out to the seemingly-abandoned Centaury instead of this tactic to get Roytam to alter his releases for your video playback issues to follow the path that Centaury took. Roytam has chimed in, repeatedly. Repeatedly. REPEATEDLY. You don't like his answers so you keep playing this incessant nagging. Consider yourself lucky, if I were Roytam, I would have you on my "ignore list". I don't think I've ever witnessed as much incessant nagging here at MSFN as what you have been doing regarding your comparison to video playback and your apparent preference toward seemingly-abandoned Centaury.

Gaslighting. Gaslighting. Gaslighting. NOTHING MORE.

I'm going to assume you're talking to me. In that case, if you have not read the thread and are not aware of it, this bug does not concern YouTube. And I will repeat once again, Roytam can figure it out without your help. If you have nothing useful to say, then do not get involved in someone else's discussion.

Version 19 no longer installs correctly on a 26100.1 system. The taskbar is hung and keeps looping on a msg to hold down ESC to keep it from loading, but that doesn't stop the hang. Killed explorer and ran the v16 install and taskbar is back to normal. It seems v19 is not downward compatible anymore.

I really think it is time for you to stop festering roytam over your YouTube playback issues. Roytam has replied and you keep festering, festering, festering. @Dave-H - can you please add this to your "watch list"?

Maybe the problem is in the splitter. You have updated ffmpeg 3.4.14, the new version of ffmpeg will not necessarily work better than the old one. You might want to try older versions of ffmpeg from 2009. They may work even faster. Because the new ffmpeg is very much oriented to 64 bit and windows 10. The ffmpeg developers are sponsored by donations from google and microsoft related entities. Also, if possible, I recommend you look up the answer in Centaury's code https://github.com/Feodor2/Centaury/releases

Where can I find VMWare Player for Windows XP and Vista? I am alone having issue finding VMWare Player 15 for Windows 7 (have a copy archived though).

It is possible that the SP3 you used for comparison was somehow corrupted. On my hardware, SP3 was indeed "faster" than SP2. I am not a "gut feeling" type of guy. I took quantifiable and repeatable measurements that led me to using SP3 over SP2. Hard facts that were repeatable. No "gut feeling", no "placebo effect". That's not to say that you are "full of it", lol, it is POSSIBLE that SP2 is "faster" on your hardware. Just saying that was not the case back in the day when I compared the two. One POSSIBLE factor is that I *never* install a Service Pack 'on top of' an existing installation - I SLIPSTREAM IT INTO MY INSTALLATION DISK. Then FORMAT and INSTALL brand new.

A license key and the corresponding, customized download link of DRevitalize can still be bought from the author if you contact him at his email address.

No. h2testw of 11Feb2008 is mainly for SDHC cards or USB sticks and doesNOT work with HDDs >2TB: A 3.09TB partition on an OK 4TB HDD, connected via eSATA to my old Inspiron 7500 (Pentium III, 700Mhz), gets incorrectly displayed under Windows 2003 (32bit, SP2, Enterprise, 18Feb2007) as "879249 MByte".

SP3 on my old 2006 laptop feels a bit bloated and slower, SP2 feels cleaner and faster, so that's why I use SP2. Thanks, I appreciate it.

Yes, it will only install 1.67, need to have browser version 128 or newer

My version is: 10.0.10586.15 by Microsoft. And I have Microsoft Visual C++ 2010 x86 Redistributable - 10.0.40219 installed: https://download.microsoft.com/download/1/6/5/165255E7-1014-4D0A-B094-B6A430A6BFFC/vcredist_x86.exe

Jeez, it turns out that now, for version <yt-dlp_x86_winXP_2025.12.06> to work, you need this “junk” — <Microsoft Visual C++ 2019>, which has to be placed in the same folder! Since I have no intention of polluting my system with that crap, I just copied all the missing files directly into the folder with <yt-dlp_x86_winXP.exe> But here’s another question: why did version <yt-dlp_x86_winXP_2025.11.25> work perfectly fine without those extra DLLs? After all, those files are already embedded inside <yt-dlp_x86_winXP.exe>, and when unpacked, everything gets extracted into the TEMP folder anyway! So what’s the point of this “duplication” now?

I've uploaded v3.6.0 (for which my AMD Ryzen AI MAX 385 for the first time did all the hard, and particularly quick, work). Please confirm it works on WinXP.

hmm i do not know the details but these are 2 different error messages: "api-ms-win-crt-convert-l1-1-0.dll was not found" -> this means that dll/file was not found "ucrtbase.mbstowcs could not be found in the dynamic library api-ms-win-crt-convert-l1-1-0.dll" -> this means that the dll/file was found but not the function "ucrtbase.mbstowcs" in that dll ucrtbase refer to the c-runtime (ucrt - Universal C Runtime Library) so you might can give it a try by installing the vc-runtime https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170 but i do not know if that one needs sp3 - its worth a try but there might also be a different version or modded version of that api-ms-win-crt-convert-l1-1-0.dll - what can give you function maybe if you have one (these files had different compiles for different os´s of windows) (what could explain why that error message says it found the file but not its function) if the c-runtime works - a good method to avoid this problem is to ship the vc-runtime with the executable (in this case ytdl)

I'll try these.

I didn't realise there were so many still using SP2 (why?). I will consider building the next version with PyInstaller 5.13.2 again. But do note, that in the future that may not be possible any more, due to the changes they make. Consider upgrading to SP3. In the meantime, here is a build that should work on SP2. @davidz, Do you really mean you're on SP3? Because in my SP3 machine (VM), 2025.12.06.064237 works fine: [debug] Command-line config: ['-v'] [debug] User config "C:\Documents and Settings\Nico\Application Data\yt-dlp\config.txt": ['--rm-cache-dir', '--console-title', '--add-metadata', '--embed-thumbnail', '--convert-thumbnails', 'jpg', '--js-runtimes', 'quickjs', '--ppa', 'ffmpeg:-metadata synopsis=""', '-o', '~/Bureaublad/%(title)s.%(ext)s', '-S', 'res:1080,vcodec:avc,acodec:m4a', '--sponsorblock-remove', 'all', '-N', '6'] [debug] Encodings: locale cp1252, fs utf-8, pref cp1252, out cp1252 (No VT), error cp1252 (No VT), screen cp1252 (No VT) [debug] yt-dlp version nicolaasjan/yt-dlp@2025.12.06.064237 (winXP_x86_exe*) [debug] Python 3.11.4 (CPython x86 32bit) - Windows-XP-5.1.2600-SP3 (OpenSSL 3.5.2 5 Aug 2025) [debug] exe versions: ffmpeg N-121824-g775b102182-WINXP (fdk,setts), ffprobe N-121824-g775b102182-WINXP, phantomjs 1.9.8 [debug] Optional libraries: Cryptodome-3.23.0, brotli-1.2.0, certifi-2025.11.12, mutagen-1.47.0, requests-2.32.5, sqlite3-3.50.4, urllib3-2.6.0, websockets-15.0.1, yt_dlp_ejs-0.3.1 [debug] JS runtimes: quickjs-2025-09-13 [debug] Proxy map: {} [debug] Request Handlers: urllib, requests, websockets [debug] Plugin directories: none [debug] Loaded 1853 extractors Removing cache dir C:\Documents and Settings\Nico/.cache\yt-dlp ..

Thank you. Sadly, I think the blue is uglier than the green, but .... it is what it is.

Yes, I confirm: version yt-dlp_x86_winXP.exe (2025.12.06.064237) does not work on Windows XP SP3! Version 2025.11.25.144622 worked fine!

Microsoft added the blue color to this progress bar with dark mode. I saw this in the Insider builds, it seems they added it in the latest CU. MS is gradually removing the ugly green.

Yes. I have two systems with native NVMe support in CSM and only one can boot - HP notebook on Core gen8 with InsydeH2O UEFI BIOS. But to do so I pushed to write my own DDO as in real mode this BIOS has bug which failed any Int 13h read or write on request with more than 8 sectors. No one bootloader can boot with such restriction and MS bootloader BOOTMGR that WRITES into file system under some circumstances can corrupt this file system even. Int 13h on Core gen10 on mobo with AMI UEFI BIOS does not work at all in Virtual 8086 Mode. And this is "must have" feature to boot any system that relates on this mode in boot time/work time icluding Windows 9x, Safe Mode of Windows 9x and DOS in protected mode with EMM386 or somthing like this. This problem is not new, RLoew faced with those buggy BIOSes with his AHCI driver too as the root of problem is the same - PCI Bus Master Controllers including ATA, AHCI and NVMe have identical program model of the I/O request: SG List pointing to the I/O buffers. There is solutions (double buffering) which can struggle with I/O buffers in the "wrong" memory but no one solution can solve the problem of SG List in the "wrong" memory as no one software except the driver itself "knows" about this list. So to solve the problem you have to replace buggy code of Int 13h handler in form of 1. new CSM DXE module, 2. DDO that supports NVMe or 3. driver in form of .SYS or .TSR