All Activity

Thanks, it help.

@cmalex Thanks again for your efforts to keep Python alive on vintage operating systems! Using your latest Python 3.9 environment, I successfully updated the included yt-dlp via pip to the Nightly build: pip install -U --pre "yt-dlp[default]" Now I get the warning: `yt-dlp -v` output: [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', '--ppa', 'ffmpeg:-metadata synopsis=""', '-o', '~/Bureaublad/%(title)s.%(ext)s', '-S', 'res:720,vcodec:h264,acodec:mp4a', '--sponsorblock-remove', 'all'] Deprecated Feature: Support for Python version 3.9 has been deprecated. Please update to Python 3.10 or above [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 nightly@2025.07.31.233123 from yt-dlp/yt-dlp-nightly-builds [71f30921a] (pip) [debug] Python 3.9.13 (CPython x86 32bit) - Windows-XP-5.1.2600-SP3 (OpenSSL 1.1.1i 8 Dec 2020) [debug] exe versions: ffmpeg N-116828-g6aafe61-Reino (fdk,setts), ffprobe N-116828-g6aafe61-Reino, phantomjs 1.9.8 [debug] Optional libraries: Cryptodome-3.23.0, brotli-1.1.0, certifi-2025.07.14, mutagen-1.47.0, requests-2.32.4, sqlite3-3.37.2, urllib3-2.5.0, websockets-15.0.1 [debug] Proxy map: {} [debug] Request Handlers: urllib, requests, websockets [debug] Plugin directories: none [debug] Loaded 1858 extractors Removing cache dir C:\Documents and Settings\Nico/.cache\yt-dlp .. Python 3.9 support will be fully dropped in October 2025 (#13861). See also #13858. Is it feasible for you to port Python 3.10 or even 3.11 to Windows XP? I'm sure the community here would be very grateful if you succeeded.

@Dave-H, please clear up, is it fine to publicly refer to a group of people as id*ots, namely Microsoft testers, if they are not MSFN members?

you can try setting referer.trimmingPolicy = 2 to see if it helps.

You are very welcome to ask, of course, we always greet active members with joy. But the sad fact is no one here can get you 100 percent guarantee. People who caught fakes are simply left, and no Extended Kernels developers present. Besides, like I wrote, Windows 7 userbase here is so thin. almost non-existent! No one to test it.

Greetings. >"ModuleNotFoundError: No module named 'PyInstaller.__main__'; 'PyInstaller' is not a package [end of output]" There is some issues with python*._pth files with paths for searching modules. Please try to add it or remove it ;-) Best regards.

The "Phishing URL Blocklist" broke AVSForum.com today. I don't know why but suddenly it's blocking all CSS URLs with an ampersand (&), which made a complete mess of AVSForum.com. Weird. Turned it off in the UBO Legacy dashboard and AVSForum is good again.

The change to browser behavior makes some sense: The Referer header was always an information leak, so the change improves privacy when following links (the target doesn't know where you came from). But if you're right, CloudFlare is abusing that change to block older browsers. Hopefully either MCP or @roytam1 can develop a fix soon.

i do not know python but if its like a normal compiler it searches for a main() or winmain(), the next error talks something about __main__ looking these 2 lines might be of interests it seems to be some kind of call "PyInstaller.__main__" a import useally is a function that a modules exports (such as a dll (or dllmain()) or in case of executable winmain) combined it says in "PyInstaller" + "__main__" was not found or pyinstaller was not reconized as "package" File "C:\Users\Admin\Documents\GitHub\xl-converter\misc\pyinstaller\PyInstaller.py", line 15, in <module> from PyInstaller.__main__ import run "ModuleNotFoundError: No module named 'PyInstaller.__main__'; 'PyInstaller' is not a package [end of output]" one way i could think of this is happening is that winver in the peheader is set to 6 or higher (6 are vista and 10) in this case a executable caller (such as createprocess) cant open the module - also from consideration the answer from compilers can sometimes not be very precise, it also could be a small type error/syntax error near that area aka PyInstaller at spot __main__ however i do not know the syntax in python

Thanks for the link. Wish it was more than one year though.

Oh, I am sorry. Yes, you are right. The file "Windows XP No SSE2 Patch Rollup.zip" is in the directory "POSReady 2009" of the Windows XP post SP3 update pack. --- The analysis of the newest version (5.1.2600.7334) of the file "win32k.sys" from the Windows XP update is now complete. The file "code.htm" has been updated. There are no big surprises in this version. It's basicly just another buggy version which needs to be fixed. The code is more or less the same as in Windows 2000 or any other Windows version. --- A bug has been found in the version "5.00.2196.0001-V3" of the file "win32k.sys" for Windows 2000. That is why the version "5.00.2196.0001-V4" has been added to the file "code.htm". Even though only a single machine instruction has been changed, it will still go through some testing before the update "WINDOWS2000-OTSKB000001-V4-X86-INTL.exe" will be released to the general public. However, the help file has already been updated. --- things to do: Windows 2000 update: Write the version "5.00.2196.0001-V4" of the file "win32k.sys". Then update "code.htm". add the update "Windows 2000/OTSKB000001-V4" to the help file write the update test it release it Windows XP update: Analysis of the version "5.1.2600.7334" of the file "win32k.sys". Then update "code.htm". Write the version "5.1.2601.0001" of the file "win32k.sys". Then update "code.htm". add the update "Windows XP/OTSKB000001-V1" to the help file write the update test it release it Windows Server 2003 update: Analysis of the version "5.2.3790.6946" of the file "win32k.sys". Then update "code.htm". Write the version "5.2.3791.0001" of the file "win32k.sys". Then update "code.htm". add the update "Windows Server 2003/OTSKB000001-V1" to the help file write the update test it release it Windows Embedded POSReady 2009 update: Analysis of the version "5.1.2600.7684" of the file "win32k.sys". Then update "code.htm". Write the version "5.1.2602.0001" of the file "win32k.sys". Then update "code.htm". add the update "Windows Embedded POSReady 2009/OTSKB000001-V1" to the help file write the update test it release it

then why update to it ?

First, we need a reliable source for this Personally, I think that in the case of dotexe, the probability that it's a scam is initially low. Acc. has been with us since 2018, has many repos, and is actively working on several updates according to GitHub, although the functionality should be able to be safely tested via a VM. An impersonator wouldn't actively develop further and probably wouldn't have the ability to do so at all, but is only looking for quick money via donations or malware. I tried it with Roblox Studio via a VM. It didn't work before with the last VxKex version 1.1.2.1428. It works with the latest VxKex dotexe version 20250704. The latest version, Google Chrome/Chromium 138.x, should also work with it now. I think an impersonator wouldn't develop the program that far. But maybe I'm wrong. Just my 2 cents.

Generally said, I think that Windows Vista and 7 need better Extended Kernel's. Don't get me wrong, I'm thankful for the Windows Vista Extended Kernel and VxKex for Windows 7, however there are still plenty of Apps that cannot be run on these two Operating Systems. I hope we will get newer versions soon, as even Windows XP (with OneCore API) can handle newer applications better than Windows Vista and Windows 7

Greetings. https://mega.nz/folder/itlRGKyB#8XNJOvlebW8ghCjaiJrk0w https://mega.nz/file/PhMAEZ7L#8PoBTs7sTt2e7wb3tRotEZhTv9TildrgZTt_lD_kvGI This is archives of all that i'd used to compile wheels undef WinXP. I`d build it at Visual studio 2017 with installed v140_xp toolset For building wheels i have used original MinGW https://osdn.net/projects/mingw/ under WinXP MinGW_all.7z - mingw compilers. Root folder was D:\ Python39NoSSe2.7z - full Python 3.9 with headers, libs and defs. Root folder was C:\ tcl.7z - compiled TCL/TK openssl-3.1.0-win32-dev-xpmod-sse.7z, openssl-3.1.0-win32-xpmod-sse.7z - are development and binary OpenSSL from https://rwijnsma.home.xs4all.nl/files/openssl/ cryptography-3.4.8.7z - lastest cryptography for XP (without RUST) Best regards

Iam not sure, that's why I'm asking here I thought maybe someone here knows him and works with him and can verify the authenticity. At first glance, it certainly doesn't look like a fake. The GitHub account is from 2018 and has 45 Repositories. He also have a Account here made in 2022. https://msfn.org/board/profile/435258-dotexe1337/

The answer was actually from Copilot AI.

Some forum threads suggest it may have been fixed in 6.43 or 6.44. Since I am not using Mikrotik wifi hardware, I honestly can't tell if it ever got fixed. What I can say, is that my androids get bandwidth much better than 20Mbit/s or even 50Mbit/s and there is no special issue around long files on androids (or for that matter anywhere else). Mine shipped with 6.43, which I promply updated to then-current 6.48.3 that I am still using. My D-Link wifi plus a nameless chinese AP/repeater both work just fine with this and I never felt the need to change it. You can do a "backup" and/or "export", download a copy of the files to your PC for safekeeping, (and possibly re-upload if it gets erased in the update), update, then "restore" or "import" afterwards. The former is a binary formatted file. (I do not know what format it is, 7-Zip and everything else I tried is unable to read it.) The latter is a text based set of commands (you can read this with notepad or similar if you are curious) that will work as if you had typed them yourself in the terminal. When I updated mine, it worked pretty smoothly with no real issues. The only thing was a confusion on my part, that it needed some time to be left sitting after the update before it was ready to accept further input. I had assumed it was ready almost instantly, but it really needed more time, perhaps allowing 10-30 minutes would have been better. Sadly most manufacturers avoid releasing any documentation about the vendor partitions, and there is risk of screwing up the works if anything is done incorrectly here.

This is PM handling of ;INT 33 - MS MOUSE v6.0+ - SET LANGUAGE FOR MESSAGES ; AX = 0022h ; BX = language V version accepts 8 [standard] languages, F - 10 (some additional 2 lanuages and IDK what they are). It's strange but the variable where this value saved is referenced from other places in code - but there is only 8 languages processed. No. It is workaround against buggy hardware - some PS/2 5-Button Mice. In addition to standard unlocking sequence of Set Rate 200, 200, 80 it executes (when Registry "Enable Q318307" key is set to 1) nonstandard sequence of Set Rate 200, 200, 60 before standard sequence. But problem still exists - VMOUSE.VXD from Q318307 has version 4.10.2225 (for windows 98SE for exаmple) and previous version from Q254660 is 4.10.2223. So there is no such thing as VMOUSE.VXD 4.10.2224 and that is the real misterious.

SoftGPU now works on real hardware, not just virtual machines, since it now includes support for any VESA VBE 2.0 compatible GPU and can now be considered a successor to VBEMP with some sort of 2d/3d acceleration, albeit purely software based. I've tested the newest version (v0.8.2025.53 special edition available for donators) on my ThinkPad X230 and DOS windows work quite well (tested only text applications) and windows are not as laggy as with VBEMP. In 3DMark2001 SE I got... 241 points Would be nice to have more tests done by others on real hardware. Download it here: https://github.com/JHRobotics/softgpu/releases/tag/v0.8.2025.53 No need for ISO, ZIP works just fine.

The script worked very good on Windows 8! Thanks, @Monroe

@roytam1 I tested the GetSystemTimes change in the kernelxp wrapper, and then it worked.

Firefox 45.9.34 and K-Meleon 76.5.5 worked on Windows XP RTM with kernelxp.dll wrappers unofficially. The thing is for K-Meleon 76.5.5 on XP RTM, you'll get a BSOD. To fix this, remove the manifests on the main K-Meleon executable, and then it works. I also tested New Moon 27 on Windows XP RTM with kernelxp.dll wrappers unofficially, and then it worked too. Note: Firefox-based browsers are compiled with Visual C++ 2013 runtimes are the last to run unofficially on Windows XP RTM (with kernelxp.dll wrappers) correctly. Firefox-based browsers are compiled with Visual C++ 2015-2019 runtimes would unofficially require at least Windows XP SP1 (with kernelxp.dll wrappers) for any stability.

It seems kind of unusual that this is happening ! Something between Windows PE part of Windows installation and when Windows Install is done. I have no idea what it is! John

Welcome! How do you know dotexe1337 is dotexe1337? Is he verified? It's been already told about impostors.