Leaderboard

https://weather.com/weather/today/l/20398:4:US Here the above URL with the latest NM28 - from Germany:

Of course it is! They are different sessions, different cookies. I'm failing to understand the obsession. I'm done here, I really do not need the obsession.

You're right. I take it back what I said earlier. I have actually changed the build_openssl3() function locally to automate the process of creating the shared- as well as the static-release. And in the process I forgot to strip both dlls. The filesizes are now identical to what you ended up with. I re-uploaded 'openssl-3.6.1-win32-shared-dev-xpmod-sse.7z'.

Do note that the OpenSSL-3.x.x DLLs are actually integral parts of every CPython for Windows higher than py3.10 (CPython-3.10.x, by default, uses OpenSSL-1.1.1.x), so they're not necessarily linked to just "YouTube downloaders" ; any other python application/script requiring py3.11+ may use those... libeay32.dll+ssleay32.dll are part of very old/insecure OpenSSL versions, the last branch that used them was the 1.0.2.x one; the 1.1.x.x branches used DLLs named libcrypto-1_1.dll and libssl-1_1.dll; BTW, TLSv1.3 support was first introduced with the OpenSSL-1.1.1.x series; so, your "legacy applications" can only use up to TLSv1.2 when connecting to the web...

Sure ; it loads fine: yt-dlp_x86 -v => [debug] Command-line config: ['-v'] [debug] Encodings: locale cp1253, fs utf-8, pref cp1253, out cp1253 (No VT), error cp1253 (No VT), screen cp1253 (No VT) [debug] yt-dlp version nicolaasjan/yt-dlp@2026.02.01.063416 (win7_x86_exe*) [debug] Python 3.14.2 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 3.6.1 27 Jan 2026) [debug] exe versions: none [debug] Optional libraries: Cryptodome-3.23.0, brotli-1.2.0, certifi-2026.01.04, mutagen-1.47.0, requests-2.32.5, sqlite3-3.50.4, urllib3-2.6.3, websockets-16.0, yt_dlp_ejs-0.4.0 [debug] JS runtimes: none [debug] Proxy map: {} [debug] Request Handlers: urllib, requests, websockets [debug] Plugin directories: none [debug] Loaded 1856 extractors Usage: yt-dlp_x86 [OPTIONS] URL [URL...] yt-dlp_x86: error: You must provide at least one URL. Type yt-dlp --help to see a list of all options. and: yt-dlp_x86 -vF "jxm5zcK27qo" --js-runtime quickjs [debug] Command-line config: ['-vF', 'jxm5zcK27qo', '--js-runtime', 'quickjs'] [debug] Encodings: locale cp1253, fs utf-8, pref cp1253, out utf-8 (No VT), error utf-8 (No VT), screen utf-8 (No VT) [debug] yt-dlp version nicolaasjan/yt-dlp@2026.02.01.063416 (win7_x86_exe*) [debug] Python 3.14.2 (CPython AMD64 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 3.6.1 27 Jan 2026) [debug] exe versions: ffmpeg 5.0 (fdk,setts) [debug] Optional libraries: Cryptodome-3.23.0, brotli-1.2.0, certifi-2026.01.04, mutagen-1.47.0, requests-2.32.5, sqlite3-3.50.4, urllib3-2.6.3, websockets-16.0, yt_dlp_ejs-0.4.0 [debug] JS runtimes: quickjs-ng-0.11.0 [debug] Proxy map: {} [debug] Request Handlers: urllib, requests, websockets [debug] Plugin directories: none [debug] Loaded 1856 extractors [debug] [youtube] [pot] PO Token Providers: none [debug] [youtube] [pot] PO Token Cache Providers: memory [debug] [youtube] [pot] PO Token Cache Spec Providers: webpo [debug] [youtube] [jsc] JS Challenge Providers: bun (unavailable), deno (unavailable), node (unavailable), quickjs [youtube] Extracting URL: jxm5zcK27qo [youtube] jxm5zcK27qo: Downloading webpage [debug] [youtube] Forcing "main" player JS variant for player 3510b6ff original url = /s/player/3510b6ff/player_es6.vflset/en_US/base.js [youtube] jxm5zcK27qo: Downloading android vr player API JSON [debug] [youtube] jxm5zcK27qo: android_vr player response playability status: UNPLAYABLE [youtube] jxm5zcK27qo: Downloading web embedded client config [debug] [youtube] jxm5zcK27qo: Detected experiment to bind GVS PO Token to video ID for web_embedded client [youtube] jxm5zcK27qo: Downloading player 3510b6ff-main [youtube] jxm5zcK27qo: Downloading web embedded player API JSON [youtube] jxm5zcK27qo: Downloading web safari player API JSON [debug] [youtube] jxm5zcK27qo: Detected a 6s ad skippable after 5s for web_safari [youtube] [jsc:quickjs] Solving JS challenges using quickjs [debug] [youtube] [jsc:quickjs] Using challenge solver lib script v0.4.0 (source: python package, variant: minified) [debug] [youtube] [jsc:quickjs] Using challenge solver core script v0.4.0 (source: python package, variant: minified) WARNING: [youtube] [jsc:quickjs] QuickJS-NG is missing some optimizations making this very slow. Consider using upstream QuickJS instead. [debug] [youtube] [jsc:quickjs] Running QuickJS: '<redacted>\yt-dlp\Builds\Nightly\nicolaasjan\py3.14\2026.02.01.63416\PyInst-6.18\qjs.EXE' --script 'C:\Users\<redacted>\AppData\Local\Temp\tmpfsvkg2za.js' [youtube] jxm5zcK27qo: Downloading m3u8 information [debug] Sort order given by extractor: quality, res, fps, hdr:12, source, vcodec, channels, acodec, lang, proto [debug] Formats sorted by: hasvid, ie_pref, quality, res, fps, hdr:12(7), source, vcodec, channels, acodec, lang, proto, size, br, asr, vext, aext, hasaud, id [info] Available formats for jxm5zcK27qo: ID EXT RESOLUTION FPS CH | FILESIZE TBR PROTO | VCODEC VBR ACODEC ABR ASR MORE INFO ---------------------------------------------------------------------------------------------------------------------------- sb3 mhtml 48x27 0 | mhtml | images storyboard sb2 mhtml 80x45 0 | mhtml | images storyboard sb1 mhtml 160x90 0 | mhtml | images storyboard sb0 mhtml 320x180 0 | mhtml | images storyboard 249 webm audio only 2 | 44.09MiB 51k https | audio only opus 51k 48k [en] low, WEB-E, webm_dash 250 webm audio only 2 | 57.96MiB 67k https | audio only opus 67k 48k [en] low, WEB-E, webm_dash 140 m4a audio only 2 | 112.28MiB 129k https | audio only mp4a.40.2 129k 44k [en] medium, WEB-E, m4a_dash 251 webm audio only 2 | 113.71MiB 131k https | audio only opus 131k 48k [en] medium, WEB-E, webm_dash 91 mp4 256x144 24 | ~153.75MiB 177k m3u8 | avc1.4D400C mp4a.40.5 [en] WEB-S 160 mp4 256x144 24 | 58.06MiB 67k https | avc1.4d400c 67k video only 144p, WEB-E, mp4_dash 278 webm 256x144 24 | 63.73MiB 73k https | vp9 73k video only 144p, WEB-E, webm_dash 394 mp4 256x144 24 | 61.83MiB 71k https | av01.0.00M.08 71k video only 144p, WEB-E, mp4_dash 92 mp4 426x240 24 | ~276.63MiB 319k m3u8 | avc1.4D4015 mp4a.40.5 [en] WEB-S 133 mp4 426x240 24 | 111.89MiB 129k https | avc1.4d4015 129k video only 240p, WEB-E, mp4_dash 242 webm 426x240 24 | 120.41MiB 139k https | vp9 139k video only 240p, WEB-E, webm_dash 395 mp4 426x240 24 | 101.99MiB 118k https | av01.0.00M.08 118k video only 240p, WEB-E, mp4_dash 93 mp4 640x360 24 | ~697.64MiB 804k m3u8 | avc1.4D401E mp4a.40.2 [en] WEB-S 134 mp4 640x360 24 | 196.77MiB 227k https | avc1.4d401e 227k video only 360p, WEB-E, mp4_dash 18 mp4 640x360 24 2 | ≈308.67MiB 356k https | avc1.42001E mp4a.40.2 44k [en] 360p, WEB-E 243 webm 640x360 24 | 247.24MiB 285k https | vp9 285k video only 360p, WEB-E, webm_dash 396 mp4 640x360 24 | 182.68MiB 211k https | av01.0.01M.08 211k video only 360p, WEB-E, mp4_dash 94 mp4 854x480 24 | ~919.27MiB 1060k m3u8 | avc1.4D401E mp4a.40.2 [en] WEB-S 135 mp4 854x480 24 | 357.67MiB 412k https | avc1.4d401e 412k video only 480p, WEB-E, mp4_dash 244 webm 854x480 24 | 327.75MiB 378k https | vp9 378k video only 480p, WEB-E, webm_dash 397 mp4 854x480 24 | 262.34MiB 303k https | av01.0.04M.08 303k video only 480p, WEB-E, mp4_dash 95 mp4 1280x720 24 | ~ 1.17GiB 1387k m3u8 | avc1.4D401F mp4a.40.2 [en] WEB-S 136 mp4 1280x720 24 | 621.36MiB 717k https | avc1.4d401f 717k video only 720p, WEB-E, mp4_dash 247 webm 1280x720 24 | 538.63MiB 621k https | vp9 621k video only 720p, WEB-E, webm_dash 398 mp4 1280x720 24 | 425.20MiB 490k https | av01.0.05M.08 490k video only 720p, WEB-E, mp4_dash 96 mp4 1920x1080 24 | ~ 3.12GiB 3685k m3u8 | avc1.640028 mp4a.40.2 [en] WEB-S 137 mp4 1920x1080 24 | 1.34GiB 1577k https | avc1.640028 1577k video only 1080p, WEB-E, mp4_dash 248 webm 1920x1080 24 | 830.37MiB 958k https | vp9 958k video only 1080p, WEB-E, webm_dash 399 mp4 1920x1080 24 | 641.86MiB 740k https | av01.0.08M.08 740k video only 1080p, WEB-E, mp4_dash Do note, though, that "my Vista" system (SP2 32-bit) is fully updated till Vista SP2's EoL, with very little WS2008 updates and no ESU ones ; but the Win10 UCRT update (a Vista SP2 one) is indeed installed here ...

All revisions (ALPHA/I386/MIPS/PPC) of Windows NT 4.0 and Windows NT 3.51 has issue with maximum possible total video mode count limit and it is around 296 modes. Any mode provided by driver above 296 will be cutted down. It is not depended on driver issue, this bug is inside Windows NT system itself. Windows 2000 and later does not have such issue. Here it is a binary patch for Windows NT 4.0 (I386, any SP/edition, language) for SYSTEM32\WIN32K.SYS : Change 0x68 0xB8 0x00 0xFF 0x00 0x00 0x6A to 0x68 0xB8 0x00 0xFF 0x03 0x00 0x6A Change 0x68 0xB8 0x00 0xFF 0x00 0x00 0xFF to 0x68 0xB8 0x00 0xFF 0x03 0x00 0xFF Recalculate checksum, f.e. EDITBIN.EXE WIN32K.SYS /RELEASE Here it is a binary patch for Windows NT 3.51 (I386, any SP/edition, language) for SYSTEM32\WINSRV.DLL : Change 0x68 0xB8 0x00 0xFF 0x00 0x00 0xA1 to 0x68 0xB8 0x00 0xFF 0x03 0x00 0xA1 Change 0x68 0xB8 0x00 0xFF 0x00 0x00 0xFF to 0x68 0xB8 0x00 0xFF 0x03 0x00 0xFF Recalculate checksum, f.e. EDITBIN.EXE WINSRV.DLL /RELEASE This will increase total limit to 1190 modes. Below are results in screenshots, before and after.

@VistaLover I have uploaded an updated Vista+ compatible PyInstaller here. Could you test if the yt-dlp built with it works well on your Vista system?

With version 3.6.0 new functionality has been added (3.6.1 is mainly a security release):

Your post is being viewed as having an AGENDA and as a PERSONAL ATTACK. Some form of GOTCHA GAME. Moderators, please take note.

Redirect link and tracking link are two different matters. The garbage you see after = is a unique tracking stamp. Most likely contains your IP, PC specs obtained via GetOEMCP ans so on. https://learn.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getoemcp

The tracker will be different with each browsing session. Google is tracking your searches, not your browser. I never said that the tracker will be "identical". It is generated BY GOOGLE each and every first visit per COOKIE. Delete the cookie and you get a new "tracker". First cookie: Delete first cookie, let Google set second cookie:

Respectfully, this doesn't add up at all with my findings, which should be possible to reproduce by others (and why would I publicly post untruths in the first place? ) ... I'm always talking about the 3.6.1 (32-bit) DLLs contained in the following archive: https://rwijnsma.home.xs4all.nl/files/openssl/openssl-3.6.1-win32-shared-dev-xpmod-sse.7z As I've posted previously in this thread, I keep a 2017-era copy of MABS (media-autobuild-suite) and if the DLLs had indeed been stripped, then submitting them to a "second" strip-treatment wouldn't result in filesize reduction; however, as I've posted already, I noticed that: Proof from an actual mintty window: OTOH, your static openssl.exe (32-bit) binary contained inside archive https://rwijnsma.home.xs4all.nl/files/openssl/openssl-3.6.1-win32-static-dev-xpmod-sse.7z is indeed a "stripped" binary, because: Regards.

Additionally, and predictably, if you set Supermium to use New Moon's default User Agent, then Supermium is sent the tracking link version of the search results. Again, all server-side. The browsers are rendering what they are sent by the server.

This thread is technically about Supermium (which is not being sent tracking links BY THE SERVER), your question is more about New Moon (which is being sent tracking links BY THE SERVER). Again, this is all SERVER-SIDE. The browser doing the rendering is rendering exactly what is being sent to that browser BY THE SERVER. And New Moon is being SINGLED OUT. Chrome/Chromium/Supermium/Catsxp/r3dfox - all of these are not being sent tracking links BY THE SERVER. It's all in the USER AGENT (in this case). New Moon without a useragent override (note: you have to hover over a search result link to see the tracking URL, it is not always shown in the address bar): New Moon with a useragent override:

I investigated this myself and the reason appears to be that @Reino's DLLs haven't been "stripped" post successful compilation : https://en.wikipedia.org/wiki/Strip_(Unix) In an MSYS2 environment, $ strip libssl-3.dll will reduce the filesize from 1.22 MiB to just 890 KiB, while $ strip libcrypto-3.dll will reduce the filesize from 5.20 MiB to just 3.88 MiB Finally, as a general observation, different compilers will produce binaries with different filesizes, even when the source code is always the same; and, of course, using different compilation flags between two different compiler invocations will also produce binaries with (slightly?) different filesizes, even when the compiler and source remain unchanged... The DLLs obtained from slproweb were compiled using a "CL" compiler (MSVC C/C++), as you can see by running: openssl version -a => OpenSSL 3.6.1 27 Jan 2026 (Library: OpenSSL 3.6.1 27 Jan 2026) built on: Wed Jan 28 15:01:03 2026 UTC platform: VC-WIN32 options: bn(64,32) compiler: cl /Z7 /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 -DL_ENDIAN -DOPENSSL_PIC -D"OPENSSL_BUILDING_OPENSSL" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"NDEBUG" -D_USE_32BIT_TIME_T -D_WINSOCK_DEPRECATED_NO_WARNINGS -D_WIN32_WINNT=0x0501 OPENSSLDIR: "C:\Program Files (x86)\Common Files\SSL" ENGINESDIR: "C:\Program Files (x86)\OpenSSL\lib\engines-3" MODULESDIR: "C:\Program Files (x86)\OpenSSL\lib\ossl-modules" Seeding source: os-specific CPUINFO: OPENSSL_ia32cap=0x0000e39defebffff:0x0000000000000000:0x0000000000000000:0x0000000000000000:0x0000000000000000 These two are also linked to vcruntime140.dll (external MSVC dependency, thus this further reduces the DLLs's filesize). My educated guess is that Reino's DLLs were compiled with some flavour of MinGW/MSYS2 (as can be deduced from the linked GH issue ), and that compiler is known to produce larger binaries than MS's Visual Studio (but I could be wrong somewhere, without knowing all the finer details ) ...

Ok, item 1. to 6. checked and done. Very good. Important is item 7. I found this on a web site due to error code 0x80072F8F: Therefore we have to compare the Windows Firewall settings too. https://imgur.com/a/OEfex0j

@Dave-H Due to the fact we have to check what else you have missed check following items: Tls 1.2.reg was applied successfully. Important is reg key [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp] "DefaultSecureProtocols"=dword:00000a80 Check if still correct patched wuaueng.dll version exists in both folder system32 and system32\dllcache. If you have SFC enabled Windows is able to swap it by an other one. In my system SFC is disabled. Be absolutely sure you have taken the suitable config.ini for HTTPSProxy. I have provided two of them, one for HTTPSProxy and one for ProxHTTPSProxy. Check Trusted Zone if only the three provided urls related to Microsoft exist. That's very important. I've already mentioned this several times but no statement from you. Check your Internet Zone too, maybe lower restrictions i.e. lower security level. I've already mentioned this several times but no statement from you. Clear SSL State and Personal information once again. I've already mentioned it above. Did you try to access MU by disabling MalwareBytes and firewall completely? I've already mentioned this but no statement from you. I do this list for you to be sure you haven't missed one of them. When you reply to this do it in the way item 1 checked and so on. So I know what is done and what has to be done. If none of necessary steps was missed you would be able to access MU without any problems. So what the hell is missing? Check it!

I open https://msfn.org/board/messenger/ , paste your profile link and it says "profile/424412-win32/ cannot receive messages".. Perhaps you have to write me first and I will reply.

Your messages are closed . I'm not sure if I can write it in the open , perhaps it will be considered that I want to push that Chinese player , no ?

Yes , exactly the same less amount (in Vista) with Nvidia HD audio almost everywhere. I only need DTS HD MA , I don't care about the other though. By the way , when I install Nvidia driver on Vista , it only adds simple "DTS-Audio" to supported formats (device properties) , while on Win7 it adds plenty of formats . It is intentional , I mean what prevents it to add more formats , it "sees" my HD capable devices (videocard and receiver) , so should be no problem , yet Nvidia doesn't want us to listen HD audio on Vista. I'm looking for a simple solution to unlock it. P.S. Much loved MPC-HC , apparently, hates Vista. When I manually choose and force playback of 5.1 HD tracks , it just plays them as poor quality 2.0 audio and blocks direct bypass completely ! So much for the popular player . I'm not sure what they have against Vista.

Yeah , but how come this is not a problem for that Chinese player ? It plays HD tracks flawlesly , DTS HD MA , TrueHD and the such . I might even say the sound quality is far more superior than with most of the popular ones (commercial and "open" source) . All I want to say , I can live with this "glitchy" player as it (obviously) doesn't need anything to be replaced . I can tell how I trick it . 1 - Open the player (don't close) at this point it can play compressed DTS and AC3 only , 2 - Go to >playback devices< and choose >test supported formats< , play Dolby Digital test file , when Windows asks "did you hear the sound from your receiver?" answer yes and press ok . That's it - you can play ALL HD formats now , but only with this specific player . Somehow it hooks to it , while it is opened . So Vista is fully capable of playing HD formats without replaciing anything . I blame the Nvidia driver and/or some settings created by it. Which are easely bypassed by the Chinese player.

Your observation is absolutely right , Vista audio drivers sound much better than the drivers that were meant for 7 , but not to the point of full satisfaction , not even close. In fact, Asus D2 Vista driver can be used without signature enforcement on 7 , but yet again , the audio is not punchy . It still sounds sandy and flat . Did you notice that Vista's audio drivers use DX10 when running on 7 ? Perhaps this is the reason they somewhat sound better. P.S. I had noticed many issues with 7 (like literally trembling opened windows , to the point where I can't even close them and the whole explorer just hangs up) Sorry . I'm not gonna argue about the other Win7 issues , like taskbar , if you choose to use Win7 (or whatever) - it's your choice . Yet again , in this topic we discuss our pleasant experience with Vista , not 7 or the such.

I'm sorry , I do not agree . I use Windows starting from Win 93 , and I do not agree . In my opinion the best are Win 2000 (for it's time) and Vista. Always hated XP . XP is like oversaturated and bloated Win 2000. Win 7 is somewhat like Vista after unsuccessful plastic surgery and filled with toxins after that (I guess explains why it is slower).