Leaderboard

Oh..my, sometimes only the dirtiest hack give you success.. I sit like a drunk duck in polling (Windows timer 15.6 ms) for the i219 lan Driver under XP SP3. IRQ registration never succeeded → so RX got serviced only on the timer. So.. I changed the IRQ-registration via this crazy hack 1) Now I try 3 candidate interrupt pairs: - a->IrqVector / a->IrqLevel NdisMQueryAdapterResources, mostly (?!) works but not for me and XP. - a->IrqSysVector / a->IrqSysLevel - a->IrqBusVector / a->IrqBusLevel What this hack is doing: - On modern boards with IOAPIC routing, XP/NDIS can expose interrupt information in multiple.. “views” (resource list, system-translated, bus-related). - If you pick only one pair (the “clean” way), NdisMRegisterInterrupt may fail or the IRQ never fires, and you fall back to timer-driven polling, means a ping of 15 ms. Hack: During MiniportInitialize, take the (Vector,Level) pairs XP already reports, and try registering them in the above order. The first pair that NdisMRegisterInterrupt accepts, becomes the selected IRQ configuration. Only ONE pair is used in the end(!). 2) I normalized BOTH vector and level when XP/IOAPIC gives “translated” values: Here with my values on Asrock z370 k6 board (from my working setup: Vector = 97, Level/IRQ-line = 5) On my compi, the “real” pair is: - vec = 97 decimal = 0x61 - lvl = 5 decimal = 0x05 Now the XP/IOAPIC “translated” case looks like this (same information, just encoded): - raw vec = 0x361 (this is in 0x300..0x3FF) - raw lvl = 0x305 (this is in 0x300..0x3FF) Normalization rule: - if value in 0x300..0x3FF => value = value - 0x300 Do the math (HEX): - vec: 0x361 - 0x300 = 0x061 => 0x61 = 97 decimal - lvl: 0x305 - 0x300 = 0x005 => 0x05 = 5 decimal So after this normalization you end up exactly at your usable XP pair: - vec = 0x61 (97) - lvl = 0x05 (5) If XP already reports normal values (not translated), nothing changes: - raw vec = 0x61 => not in 0x300..0x3FF => keep 0x61 - raw lvl = 0x05 => not in 0x300..0x3FF => keep 0x05 Before, sometimes I had a good vector but a still-translated level, so NdisMRegisterInterrupt failed and I stayed in polling forever, ping always 15 ms, but via IRQ to my router at 192.168.2.1 ping time should be <1 ms. 3) Now I force the XP-safe interrupt mode - shared = TRUE - mode = NdisInterruptLevelSensitive Why this works - This matches how INTx behind IOAPIC behaves in practice on modern chipsets (like crazy). - “Edge” / “not shared” settings are a common reason for missed / never-fired interrupts on XP. Dietmar PS: Because I have no idea, how to test the quality of my driver i219 for XP SP3, I would be very happy, if a user here can do this for me or gives me Tutorial, how to do this by myself. PPS: Here is this my version of the i219 lan driver, running under XP SP3. Now it is the fastest lan, that I ever had. https://files.catbox.moe/rmxl63.zip

Oh..I spend soso many hours to overcome the crazy ULP etc. on this crazy lan chip i219 Dev_15B8. Now for the very first time I come to 100 MB/s, before it was ALWAYS only 10 MB/s because of crazy energy saving.. Here is this driver i219 for XP SP3 Dietmar https://files.catbox.moe/ye06bv.zip Tutorial (MSFN): Getting 100 Mb/s (Fast Ethernet) link on Intel i219 (DEV_15B8) under Windows XP SP3 — the ULP/LPLU “crazy register” fix Problem we hit On i219 (PCH-integrated PHY), Windows XP does not handle Intel’s modern low-power PHY/MAC features correctly. The PHY can stay in (or partially return to) low-power states after reset / link events, which can break auto-negotiation and leave you stuck at 10 Mb/s or with unstable negotiation. What finally made 100 Mb/s work (our “fixed6” build) We had to do two things together: 1) Force a clean exit from ULP/DPG and “sticky” low-power configuration 2) Disable LPLU and restart auto-negotiation with a clean 100FD advertisement ──────────────────────────────────────────────────────────────────────────── 1) ULP / DPG: force the PHY fully “awake” (exit Ultra Low Power) Key idea: ULP settings can be sticky and survive resets. When leaving ULP, hardware may have disabled K1 automatically; you must re-enable it explicitly. Registers involved (names from Linux e1000e): - E1000_H2ME (0x05B50) + bits START_DPG / EXIT_DPG / ULP (Host↔ME handshake) - FWSM flags like ULP_CFG_DONE and EXFWSM_DPG_EXIT_DONE (status/handshake) - PHY reg I218_ULP_CONFIG1 (page 779, reg 16) with bits: STICKY_ULP, INBAND_EXIT, RESET_TO_SMBUS, WOL_HOST, etc. - PHY reg HV_PM_CTRL (page 770, reg 17): HV_PM_CTRL_K1_ENABLE - PHY reg CV_SMB_CTRL (page 769, reg 23): clear FORCE_SMBUS if set - MAC regs: CTRL_EXT (unforce SMBus), FEXTNVM7 (DISABLE_SMB_PERST handling) Minimal “XP-friendly” sequence (conceptual checklist): - Ensure you are allowed to touch PHY regs (lock/semaphore in your driver as needed). - If the platform uses ME/DPG: request DPG exit and/or wait for DPG_EXIT_DONE / ULP_CFG_DONE style indications. - Unforce SMBus mode: - PHY: clear CV_SMB_CTRL_FORCE_SMBUS - MAC: clear CTRL_EXT_FORCE_SMBUS - Re-enable K1 on exit: - PHY: set HV_PM_CTRL_K1_ENABLE - Clear all “ULP enabled configuration” bits in I218_ULP_CONFIG1: - clear at least: IND, STICKY_ULP, RESET_TO_SMBUS, WOL_HOST, INBAND_EXIT, EN_ULP_LANPHYPC, DIS_CLR_STICKY_ON_PERST, DISABLE_SMB_PERST - Commit those PHY changes: - set I218_ULP_CONFIG1_START once after writing - (Optional but recommended for XP testing) ensure DPG is not forced: - set DPGFR to a “not forced” state (typically clearing force bits / leaving default) Why this matters for 100 Mb/s: If the PHY is still partially in ULP / SMBus-forced mode, auto-negotiation can behave “wrong” (bad timing, wrong advertised set, negotiation never completes correctly), especially with XP’s older network stack and power handling. ──────────────────────────────────────────────────────────────────────────── 2) LPLU: disable Low Power Link Up and restart Auto-Negotiation Key idea: LPLU is meant to save power during Dx states. Under XP, it can interfere with negotiation and speed switching. We disabled it and forced a clean auto-neg restart. Registers involved (names from Linux e1000e): - PHY reg HV_OEM_BITS (page 768, reg 25): - HV_OEM_BITS_LPLU (Low Power Link Up) - HV_OEM_BITS_GBE_DIS (Gigabit disable — useful when forcing 10/100 only) - HV_OEM_BITS_RESTART_AN (Restart auto-negotiation) - MAC reg PHY_CTRL (CSR offset 0x00F10) contains LPLU/GBE control bits mirrored into OEM bits on some PCH designs. What we did in practice: - Make sure LPLU is OFF: - clear HV_OEM_BITS_LPLU - clear any LPLU-related bits in PHY_CTRL (PCH-integrated PHY control) - Advertise only what you want (100FD in our case): - Disable/clear 1000Base-T advertisement (and/or set HV_OEM_BITS_GBE_DIS) - Set 10/100 advertisement so that 100 Full Duplex is included (or only 100FD if you want strict) - Restart auto-neg: - set HV_OEM_BITS_RESTART_AN (or trigger autoneg restart via standard PHY control) - Wait for link-up, then read speed/duplex. Practical note (important): Some PCH designs won’t fully apply LPLU changes unless you also do an explicit auto-neg restart. That restart is what finally made the PHY “re-decide” with the corrected (non-low-power) configuration. ──────────────────────────────────────────────────────────────────────────── 3) What to post as the “takeaway” for other XP users If your i219 under XP is stuck at 10 Mb/s or negotiation behaves strangely, try this order: 1) Exit ULP cleanly (clear sticky ULP, unforce SMBus, commit with START, re-enable K1) 2) Disable LPLU 3) Force/limit advertisement (e.g., 10/100 only, or 100FD) 4) Restart auto-neg That combination was the first time we got a stable 100 Mb/s link on DEV_15B8 with XP SP3. ──────────────────────────────────────────────────────────────────────────── Complete Sources (links you can cite on MSFN) 1) Linux kernel e1000e (PCH/i217/i218/i219) — ULP disable flow + K1 re-enable + clearing I218_ULP_CONFIG1: https://codebrowser.dev/linux/linux/drivers/net/ethernet/intel/e1000e/ich8lan.c.html 2) Linux kernel e1000e — ULP/LPLU/ME/DPG related defines (I218_ULP_CONFIG1 bits, HV_OEM_BITS, HV_PM_CTRL_K1_ENABLE, H2ME bits): https://codebrowser.dev/linux/linux/drivers/net/ethernet/intel/e1000e/ich8lan.h.html 3) Linux kernel e1000e — MAC register offsets used here (PHY_CTRL 0x00F10, DPGFR 0x00FAC, CTRL_EXT, FEXTNVM7, etc.): https://codebrowser.dev/linux/linux/drivers/net/ethernet/intel/e1000e/regs.h.html 4) (For historical macro values referenced in some trees) E1000_PHY_CTRL_D0A_LPLU / E1000_PHY_CTRL_NOND0A_LPLU definitions (older e1000 header docs): https://docs.huihoo.com/doxygen/linux/kernel/3.7/e1000_2e1000__hw_8h_source.html

I was not able to enter Quora and of course RateYourMusic (but I don't even try with New Moon for other reasons). But the captcha then got better and let me through again, without me changing anything. It was something temporary. The script is really tough and normally takes several seconds on Core 2 Duo.

All Done Now! https://chipp.in/software/windows/mozilla-ends-support-for-firefox-on-windows-7-and-8-8-1/

The specific website(s) should probably be cited. Not "all" Cloudflare captchas are "the same". Even in MODERN Chrome/Chromium (not most-recent, but only 2 or 3 versions behind !!!) you can encounter Cloudflare ENDLESS LOOPS on website A but websites B thru Z all work perfectly fine. The Cloudflare on website A loops endlessly, UNSOLVABLE. But the Cloudflare on websites B thru Z all work perfectly fine.

Please, verify if this is Win98 or Win98SE; it does make a difference. With Win98(Gold/FE[First Edition]) Nusb v3.6 is not compatible (try Nusb v3.2 instead). For Win98SE, Nusb v3.6 is fine. For sweetlow's driver, on Win98(Gold/FE) you would need to use the NOWMI version of file "usbhub20.sys"; found in the NOWMI included folder. For Win98SE, you can use the one provided in the root directory of the zip file (same directory as USB2.inf); It is the same file as in the WMI folder. The one in the VIA folder is a fall back, if using a VIA chipsets; when the others do not work. To install sweetlow's driver (it's been awhile) you might need to delete the USB2.inf file (from Windows/INF), remove your USB drivers from Device Manager, and then (when re-detecting and installing the new drivers) point to sweetlow's USB2.INF file; ensuring you use the correct usbhub20.sys file (replace the root file with the correct one, if needed). If files cannot not be found during installation, that are also not in the sweetlow's driver folder, they are probably located in Windows/System or Windows/System32/Drivers folders. You can check by guiding the installation manager to those folders, using the browse option. Alternatively, you could just try copying sweetlow's driver files over the currently installed ones (found in Windows/System32/Drivers). Maybe, back up the old files first (good practice, when playing with things). After copying the files over, reboot.

... Well, why? 1. 32-bit apps run perfectly fine on a 64-bit OS 2. Do you expect a huge performance boost if you ran a 64-bit variant of yt-dlp ? Well, this app isn't, say, a browser with a voracious RAM appetite; I've been using it on a 32-bit OS myself for close to a decade, never ran into memory issues... 3. The one practical advantage of running it under 64-bit, the ability to install the curl_cffi optional dependency (necessary to circumvent CloudFlare's antibot/AI filters on many popular services) is nullified under WinXP, because the lib it uses internally (curl-impersonate) requires at least Win7(8?) x64 ... In any case, this is probably a "no-can-do", because @nicolaasjan relies on a third-party CPython-3.11-win32 implementation to compile his 32-bit WinXP-compatible builds; specifically, this was a py3.11.4 "assembly" kindly offered by our Ukrainian member cmalex , which uses several DLL wrappers from OCA/Wine/ReactOS and it was provided solely as a 32-bit variant (which should cover probably 95% of XP users ) ... Regards.

Oh no, I was just interested in your opinion. You always have opinions about everything. Thank you for not ignoring!

I offered MMX, SSE, SSE2 optimized opengl32, for machines like this. The softgpu only offers mmx (win95), with the other supplied opengl option requiring features not available on these older CPUs. But, the performance wasn't wonderful. There is a better option, and I'm sure some at MSFN have heard of it before. TitaniumGL doubles the performance of older Mesa OpenGL releases [6.5.4-7] (asm optimized for MMX, SSE, and SSE2). This is also true, if not more true, when using the SoftGPU provided opengl. TitaniumGL is meant to provide a conversion of opengl to direct3d, on machine that have hardware acceleration. But, when no hardware accel exists, it falls back on its own software rendering. I've tested its software rending, and it does double the performance. It can also be paired with Wine3d, like the Mesa opengl, included with softgpu. In the TitaniumGL download, it includes supporting files for Modern Windows, Win9x, and ReactOS. The modern release does not work with Win9x (even with KernelEx). The Win9x version works great. The ReactOS version works in Win9x, with KernelEx (maybe without it, as well), with a potential minuscule increase in performance (not verified, and hardly detectable; if real). Be sure to get the modern release of TitaniumGL, as the older ones floating around are half the performance. Also, be warned, don't get too excited. While the performance is doubled, that might not mean much in a less powerful machine. My Pentium-M 1.2Ghz machine still did not achieve real playable results with "Unreal Tournament GOTY Edition". At windowed 400x300, it really came close (Titanium -> Wine3d [haven't to tested opengl patches for UT]). But PSCXR went from unusable to usable windowed @640x480 (better @600x440) with graphics performance settings enabled, on the opengl plugin. For those using multiple core supporting versions of windows, the software (and hardware) renderer supports using these other cores. I assume, for hardware accelerated systems, the extra cores are utilized to increase performance of the opengl > direct3d translations. It has been noted, on machines with weaker GPUs, that the software renderer can outperform hardware "opengl (maybe not with wine3d)" acceleration (providing enough cores are available [support for 32 cores]). Again, it would be nice if a hack could achieve access to other cores, on bare metal Win9x installs. SIMD95 might improve performance, on CPUs that provide AVX (SSE/AVX for Win95) however it is intended for Virtual Machines. Not an excellent update, but I thought it worth mentioning. A nicely capable Core Solo (bare metal Win9x install) would probably provide a low expectation, but usable, software rendering experience. This might pair well the the emerging potential for HDA audio support (un-accelerated [emulated], like AC97).

New build of Serpent/UXP for XP! Test binary: Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20260214-3219d2d-uxp-d72f3921f8-xpmod.7z Win64 https://o.rthost.win/basilisk/basilisk52-g4.8.win64-git-20260214-3219d2d-uxp-d72f3921f8-xpmod.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/custom IA32 Win32 https://o.rthost.win/basilisk/basilisk52-g4.8.win32-git-20260214-3219d2d-uxp-d72f3921f8-xpmod-ia32.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/ia32 NM28XP build: Win32 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20260214-d849524bd-uxp-d72f3921f8-xpmod.7z Win32 IA32 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20260214-d849524bd-uxp-d72f3921f8-xpmod-ia32.7z Win32 SSE https://o.rthost.win/palemoon/palemoon-28.10.7a1.win32-git-20260214-d849524bd-uxp-d72f3921f8-xpmod-sse.7z Win64 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20260214-d849524bd-uxp-d72f3921f8-xpmod.7z Win7+ x64 AVX2 https://o.rthost.win/palemoon/palemoon-28.10.7a1.win64-git-20260214-d849524bd-uxp-d72f3921f8-w7plus-avx2.7z Official UXP changes picked since my last build: - No issue - Enable performance observers by default in the platform. (432378b376) - Issue #2928 - Re-order imgLoader::RemoveFromCache (17338528b7) - Issue #2928 - Always refresh dirty queue. (15e076130d) - Issue #2928 - Avoid searching the image cache queue for an entry after we just popped it off the queue. (21f4ab5e02) - Issue #2928 - Improve imgLoader cache queue handling. (c5cc980506) - Issue #2928 - Add extra checks to nsExpirationTracker. (e99ed75382) - Issue #2932 - Ensure that imgRequestProxy::CancelAndForgetObserver removes itself from the cache validator (1078e45dd3) - Issue #2551 - Initial attempt at toSorted implementation (b8f6996928) - Issue #2551 - Ensure toSorted is 100% spec compliant per multiple tests (89e4711761) - Issue #2551 - Add toSorted test and do some final tweaks to toSorted to be compliant (68a5ed17c3) - Issue #2551 - comment toSorted implementation (6e0414ddb4) - No Issue - Remove redundant OS check for toolkit/fonts (4f821a5abb) - Issue #2909 - Base implementation of media interaction features. (5d989634a1) - Issue #2909 - Fix build issues when targeting Windows 7. (e801145319) - Issue #2229 - Initial implementation of top level await functionality (2e88bbe575) - Issue #2229 - add better comments on top level await code (903f228fa0) - Issue #2229 - Add comment regarding JIT to top level await code (d29f47f950) - Issue #2229 - Add top level await tests (112460fa84) - Issue #2229 Followup - Handle re-entrant module instantiation/evaluation during async module loads (6c67c6f665) - Issue #2229 - Fix debug builds when visiting pages that utilize top-level await (13a4a75cd0) - Issue #2229 - Fix assertions in top-level await on x86_64 (113300ac3f) No official Pale-Moon changes picked since my last build. No official Basilisk changes picked since my last build. My changes picked since my last build: - js-random: 32bit: reduce a push-pop pair (b69cdf1cd1) - widget: align AR_STATE with one in nsLookAndFeel (55c8858ba7) Update Notice: - You may delete file named icudt*.dat and icu63.dll inside program folder when updating from old releases. * Notice: From now on, UXP rev will point to `custom` branch of my UXP repo instead of MCP UXP repo, while "official UXP changes" shows only `tracking` branch changes.

10-40 MB/s sounds slow to me. But I had to learn something new... From here: https://www.techcalc.org/blog/mbps-vs-mbps-download-speed-explained My wireless fluctuates between 46 and 66 MB/s. So yeah, 10 on a wired is a definite sad face.

Hi George, thanks for the driver. It installed successfully.