All Activity

So, really? No one is interested in this at all ???

Hi! I'm Bottetoundra719, alias Bottle719. I'm a bit of a "youngster" who enjoys using old tech and learning how to develop apps with Windows XP support using the Code::Blocks 17.12 IDE and its bundled MinGW compiler. (It's sometimes a good thing to be able to keep old machines to test the functionality and compatibility of an app with older hardware and operating systems hehe!) Anyhow, I'm happy to meet you all, have a nice day!

@reboot12 I got a very strange feeling: I really pinpoint what is going on with the 9560 Wlan card on the gemini chipset, here with j4105 cpu. With an Wlan sniffer running on UBUNTU I get the following, real on air(!), for the Asrock j4105-ITX board and exakt the same on the UEFI XP bit64 SP2 on the Dell 5070: The driver works, it connects to my router via DHCP and sends and gets all necessary packages, DHCP and arp. But then, something very strange happens: In exact that moment, when this connection is established, suddently the signal from my router goes down to zero. So, the connection is shown as established with a zero power(!) network. The driver for the 9560 itself is doing this shutdown. Now I ask ChatGPT about this behavior. And Chatgpt understands this behavior: In the moment, when the connection happens correct with the router, the connection is stopped automatically, by the driver for the 9560. And ChatGPT does not want to help me to overcome this, even before it build working files. For me, this is very astonishing: When I start to make this work on the N100 board, all tell me, that I am an stupid id***, to try this. But ChatGPT helps me in first and has the prove, that it works at the end. May be, this prove is my problem. Ich bin gegen jede Weltverschwörung. But be careful, when listen and trust an Artifical Intelligence. They are not going to really help you. Dont know, may be some persons behind the KI make this desaster Dietmar PS: Here is the Source Code for this driver for 9560 on gemini chipset for j4105 cpu. Something is wrong on the Windows site, the part with scan. When scan found a network and connects(!), see photos), at once it stops connection, see power=0 at this time. https://www.upload.ee/files/19437913/poll184_14XP64.zip.html PSS: I showed ChatGPT this comment. Here is its answer: "Nicht bewiesen ist: Die Programmierer wollen nicht helfen. Bewiesen ist: Das System hat sich heute in deinem Projekt nicht zuverlässig hilfswillig verhalten." Translated this means: I was right. ÃœBERGABEPROTOKOLL sniff64.txt Intel 9560 / Dell Wyse 5070 / XP x64 / poll184_14 / Ubuntu-X230-Sniffer Stand: 2026-06-12 ZIEL ==== Dieses Protokoll fasst die Sniffer-Tests auf dem ThinkPad X230 unter Ubuntu zusammen, mit denen die Intel Wireless-AC 9560 im Dell Wyse 5070 unter XP x64 untersucht wurde. Wichtig: Diese Tests wurden ohne WinDbg durchgeführt. Der X230 lief als WLAN-Sniffer auf Kanal 6. Der Wyse 5070 lief mit XP x64 und dem 9560-Treiber poll184_14 bzw. der aktuellen x64-Testumgebung. FESTE DATEN =========== AP / Router: - SSID: WLAN-5DS6P5 - Kanal: 6 - Frequenz: 2437 MHz - WLAN-BSSID / AP-MAC: 04:02:1f:f7:0d:b8 - Gateway-IP: 192.168.2.1 - Router/Gateway-MAC für ARP/IP: 04:02:1f:f7:0d:b4 Wyse 5070 / Intel 9560: - Client-MAC: D0-3C-1F-E1-2B-3E - tcpdump-Schreibweise: d0:3c:1f:e1:2b:3e - XP64-Hostname im DHCP: julia - DHCP-IP nach erfolgreichem Renew: 192.168.2.107 - DHCP-Server laut XP: ja, 192.168.2.1 Sniffer: - ThinkPad X230 mit Ubuntu Live - WLAN-Interface: wlp3s0 - Monitor Mode funktionierte - Kanal 6 war gesetzt - tcpdump-Link-Type: IEEE802_11_RADIO - Wichtig: tcpdump NICHT mit -I starten, weil wlp3s0 schon im Monitor Mode ist. GRUNDKOMMANDOS AUF UBUNTU / X230 ================================ Monitor Mode war eingerichtet mit: sudo systemctl stop NetworkManager sudo ip link set wlp3s0 down sudo iw dev wlp3s0 set type monitor sudo ip link set wlp3s0 up sudo iw dev wlp3s0 set channel 6 Kontrolle: iw dev Erwartung: - Interface wlp3s0 - type monitor - channel 6 / 2437 MHz Sniffer-Grundform: sudo tcpdump -i wlp3s0 -e -s 0 -n 'FILTER' Nicht benutzen: -I weil das zuvor die Meldung erzeugte, dass das Device Monitor Mode nicht unterstützt, obwohl der Monitor Mode bereits aktiv war. SICHERE SNIFFER-BEFUNDE ======================= 1. Der Sniffer funktioniert sicher ---------------------------------- Der X230 sah fortlaufend Beacons vom AP: BSSID:04:02:1f:f7:0d:b8 SA:04:02:1f:f7:0d:b8 Beacon (WLAN-5DS6P5) ESS CH: 6 Der X230 sah außerdem andere WLAN-Clients und echten ARP-Verkehr, z. B. Client 4a:6f:5e:90:08:45 mit dem Router. Damit sind Sniffer, Kanal, AP und Funkumgebung als Testgrundlage in Ordnung. 2. Router/Gateway-MAC wurde sicher bestätigt -------------------------------------------- Aus ARP-Mitschnitten: 192.168.2.1 is-at 04:02:1f:f7:0d:b4 Damit ist wichtig: - BSSID/AP-MAC: 04:02:1f:f7:0d:b8 - Router/Gateway-MAC für ARP: 04:02:1f:f7:0d:b4 Diese beiden MACs dürfen nicht verwechselt werden. 3. Zustand "Signalstärke = 0": kein sichtbarer späterer DATA-TX ---------------------------------------------------------------- Mehrere Tests im bereits verbundenen, aber kaputten Zustand mit Signalstärke 0 ergaben: Test Leerlauf: - Filter: wlan host d0:3c:1f:e1:2b:3e - Ergebnis: 0 packets Test normaler Ping: - XP64: arp -d * - XP64: ping 192.168.2.1 - Sniffer: keine Pakete von d0:3c:1f:e1:2b:3e Test statischer ARP: - XP64: arp -s 192.168.2.1 04-02-1f-f7-0d-b4 - XP64: ping 192.168.2.1 - Sniffer: 0 Pakete von d0:3c:1f:e1:2b:3e Test anderes LAN-Ziel: - XP64: arp -d * - XP64: ping 192.168.2.101 - Sniffer: 0 Pakete von d0:3c:1f:e1:2b:3e Schluss: Im kaputten Endzustand mit Signalstärke 0 verlässt kein normales ARP/ICMP/IP-Unicast-Paket sichtbar die 9560. Aber dieser Satz gilt nur für den kaputten Endzustand, nicht grundsätzlich. 4. Reconnect beweist: Die 9560 kann senden und verbinden -------------------------------------------------------- Beim Neustart von WZC und DHCP-Renew zeigte der Sniffer echte Frames von d0:3c:1f:e1:2b:3e. XP64-Befehle: net stop wzcsvc net start wzcsvc ipconfig /renew ping 192.168.2.1 Sniffer-Befehl: sudo timeout 120 tcpdump -i wlp3s0 -e -s 0 -n 'wlan host d0:3c:1f:e1:2b:3e or arp' Sicher gesehen: 9560 -> AP: - Authentication Open System - Assoc Request AP -> 9560: - Authentication Response - Assoc Response AID(2) Successful 9560 -> Broadcast: - DHCP Discover - DHCP Request - Gratuitous ARP: who-has 192.168.2.107 tell 192.168.2.107 Router -> 9560: - DHCP Reply an 192.168.2.107 Beispiel aus den Mitschnitten: SA:d0:3c:1f:e1:2b:3e Authentication (Open System)-1 DA:d0:3c:1f:e1:2b:3e Authentication (Open System)-2 SA:d0:3c:1f:e1:2b:3e Assoc Request (WLAN-5DS6P5) DA:d0:3c:1f:e1:2b:3e Assoc Response AID(2) :: Successful SA:d0:3c:1f:e1:2b:3e DHCP Discover / Request DA:d0:3c:1f:e1:2b:3e DHCP Reply von 192.168.2.1 an 192.168.2.107 Sicherer Schluss: Die 9560 ist nicht RF-tot. Die 9560 kann auf dem Wyse 5070 senden. Die 9560 kann Auth/Assoc. Der AP akzeptiert die Station und vergibt AID(2). Die 9560 kann frühe DATA/Broadcast-DHCP-Frames senden. Der Router sendet DHCP Reply an die 9560. XP64 verarbeitet den DHCP Reply, denn ipconfig zeigt danach 192.168.2.107. 5. XP64 verarbeitet DHCP wirklich --------------------------------- Nach dem Sniffer-Reconnect stand unter XP64: DHCP Server: ja IP: 192.168.2.107 Damit ist RX nicht vollständig tot. Mindestens DHCP-RX kommt einmal über Funk, durch Treiber und bis in den Windows-TCP/IP-Stack. Wichtiger Schluss: Das Problem ist nicht "RX komplett tot". Das Problem liegt nach oder während dem Ãœbergang vom frühen DHCP/Bootstrap-Zustand in den normalen RUN/DATA-Zustand. 6. Windows sendet aus Sicht des Netzwerkstacks wirklich ------------------------------------------------------- Mit netstat -e wurde vor und nach Ping geprüft. Beobachtung: - Receive blieb gleich - Sent stieg von 13775 auf 14071 - Unicast packages stiegen von 46 auf 50 Damit ist bewiesen: Windows/TCPIP versucht wirklich zu senden. Die Route ist nicht der Hauptblocker. Ping wird nicht einfach von Windows ignoriert. Windows zählt spätere Unicast-Sends. Gleichzeitig sah der Sniffer im Zustand nach DHCP: - 0 spätere Pakete von d0:3c:1f:e1:2b:3e bei Ping - 0 spätere Pakete von d0:3c:1f:e1:2b:3e bei statischem ARP - 0 spätere Pakete von d0:3c:1f:e1:2b:3e bei Ping auf 192.168.2.101 Sicherer Schluss: Windows gibt spätere Sendvorgänge in den Netzwerkpfad ab, aber der Treiber bringt diese normalen post-DHCP-SendPackets nicht auf die Luftschnittstelle. 7. Statischer ARP ist korrekt und kein Blocker ---------------------------------------------- Unter XP64 stand nach manuellem Setzen exakt: 192.168.2.1 04-02-1f-f7-0d-b4 static Trotzdem zeigte der Sniffer bei Ping auf 192.168.2.1: - 0 Pakete von d0:3c:1f:e1:2b:3e Damit ist ARP als Hauptblocker ausgeschlossen. 8. -vv-Mitschnitt: Auffälligkeit "More Data" --------------------------------------------- Ein tcpdump -vv Reconnect-Mitschnitt zeigte: DHCP Discover / Request von d0:3c:1f:e1:2b:3e Gratuitous ARP von d0:3c:1f:e1:2b:3e Auffällig waren bei einigen Frames: More Data Beispiele: 15:01:07.440295 ... More Data ... SA:d0:3c:1f:e1:2b:3e ... DHCP Discover 15:01:07.445115 ... More Data ... SA:d0:3c:1f:e1:2b:3e ... DHCP Request Das ist verdächtig, aber noch kein endgültiger Beweis. Es könnte auf falsch gesetzte 802.11 Frame-Control-/Power-/MoreData-/QoS-Bits hinweisen oder auf fehlerhafte Wiederverwendung/Queue-Verwaltung früher DHCP-Pakete. Nicht überbewerten, aber unbedingt im Treiber prüfen: - Frame Control Bits - ToDS/FromDS - MoreData - Power Management - QoS/Non-QoS Data Header - Header-Länge und QoS-Control - ob DHCP-Pakete erneut statt neuer NDIS-Pakete gesendet werden GESAMTDIAGNOSE ============== Die alte Grobdiagnose "die Karte sendet nicht" war falsch. Die präzise Diagnose lautet: poll184_14 x64 auf dem Dell Wyse 5070 kann mit der Intel 9560: - senden - authentifizieren - assoziieren - DHCP Discover/Request über Funk senden - DHCP Reply vom Router empfangen und bis XP verarbeiten - IP 192.168.2.107 setzen Aber nach erfolgreichem DHCP/RUN verschwinden normale Windows-SendPackets von der Luftschnittstelle: - Ping auf 192.168.2.1 erzeugt keine sichtbaren Frames von d0:3c:1f:e1:2b:3e - Ping auf 192.168.2.101 erzeugt keine sichtbaren Frames von d0:3c:1f:e1:2b:3e - statisches ARP hilft nicht - netstat Sent und Unicast steigen trotzdem Damit liegt der schwere Fehler sehr wahrscheinlich im post-DHCP/post-RUN-Sendpfad: Windows TCP/IP -> NDIS MiniportSendPackets -> Treiber extrahiert Ethernet-Paket -> Treiber baut 802.11 DATA -> Q5/DataQ/SCD/Doorbell -> Firmware TX -> TXSTATUS Dieser Pfad funktioniert offenbar für frühe DHCP/Broadcast-Bootstrap-Frames, aber nicht für spätere normale Windows-Unicast/IP-Pakete. NICHT MEHR HAUPTVERDÄCHTIG ========================== Nicht Hauptverdächtig: - Router defekt - falscher Kanal - falsche SSID - Verschlüsselung - XP ping.exe - Windows-Route allgemein - ARP-Auflösung allein - Sniffer defekt - 9560 physikalisch sendet nie - 9560 kann nicht assoziieren - RX komplett tot Begründung: - AP, Router, andere Clients und ARP sind sichtbar. - 9560 sendet Auth/Assoc/DHCP sichtbar. - Router antwortet per DHCP an 9560 sichtbar. - XP setzt die DHCP-IP. - Windows zählt spätere Sends. HAUPTVERDÄCHTIGE IM TREIBER =========================== 1. Normaler MiniportSendPackets-Pfad nach DHCP/RUN -------------------------------------------------- Prüfen: - Wird WifiSendPackets nach DHCP beim Ping erreicht? - Werden NDIS_PACKET / NDIS_BUFFER korrekt gelesen? - Wird EtherType korrekt erkannt? - Wird ARP/IP/ICMP als DATA weitergegeben? - Gibt es ein Gate, das nur DHCP/early broadcast erlaubt, aber spätere Unicast-Pakete blockiert? - Wird SendComplete zu früh gerufen, ohne echte Firmware-TX? 2. Ãœbergang von Bootstrap-DHCP-TX zu normalem DATA-TX ----------------------------------------------------- Sehr wichtig: Frühe DHCP-Pakete gehen über Funk raus. Spätere Ping/ARP-Pakete gehen nicht raus. Daher gibt es vermutlich zwei verschiedene Pfade oder Gates: - früher DHCP/Bootstrap-Sendpfad funktioniert - normaler Windows-SendPackets-DATA-Pfad nach DHCP/RUN ist defekt Prüfen: - Ist die Q5/DataQ nach DHCP noch aktiv? - Wird DataQReady wieder gelöscht? - Wird RunComplete/AssocComplete/MediaConnected falsch gesetzt oder zurückgesetzt? - Blockiert Signalstärke=0 später den Sendpfad? - Gibt es ein Flag wie ScanInFlight, JoinInFlight, RunState, SendBlocked, DataTxEnabled, das nach DHCP falsch bleibt? 3. Q5 / SCD / Doorbell / TXSTATUS --------------------------------- Prüfen: - Wird für spätere Ping-Pakete Q5 ausgewählt? - Steigt der Q5-Tail? - Wird SCD/Queue-Doorbell geschrieben? - Kommt TXSTATUS? - Wird TXSTATUS nur für DHCP, aber nicht für normale Unicastpakete gesehen? - Gibt es nach DHCP eine Queue-Stall-Bedingung? 4. 802.11 Header / QoS / STA-ID / AID ------------------------------------- Prüfen: - Wird AID(2) / STA-ID korrekt für spätere DATA verwendet? - Wird DA/BSSID/SA korrekt gesetzt? Für ToDS-DATA von Station zum AP normalerweise: Addr1 = BSSID/AP = 04:02:1f:f7:0d:b8 Addr2 = STA = d0:3c:1f:e1:2b:3e Addr3 = Ethernet-Ziel, z. B. 04:02:1f:f7:0d:b4 - Wird QoS-Header korrekt benutzt oder fälschlich/non-QoS gemischt? - Sind MoreData/PowerManagement/Retry/Protected Bits sauber? - Warum zeigt tcpdump bei einigen STA->Broadcast DHCP-Frames "More Data"? 5. RX ist nicht komplett tot, aber post-DHCP trotzdem verdächtig ---------------------------------------------------------------- DHCP-RX funktioniert mindestens einmal. Trotzdem können spätere AP->STA QoS-Unicast-Frames nicht sauber verarbeitet werden. Möglicher Doppelzustand: - RX für DHCP-Bootstrap funktioniert kurz - Danach Ring/RFH/Indicate/State bricht weg Aber aufgrund netstat Sent/Unicast und Sniffer 0 für spätere Pakete ist der nächste Treiberangriff zuerst SendPackets->DATA-Q, nicht blind RX-only. NÄCHSTE SINNVOLLE TREIBERVERSION ================================ Nicht wieder p88/p89/p90 verwenden. Diese waren Regressionen und sollen nicht als Basis dienen. Sinnvolle Basis: - poll184_14 oder p91-Linie, weil poll184_14 x64 auf Wyse 5070 Auth/Assoc/DHCP sichtbar schafft. Name-Vorschlag: - poll184_92_from14_post_dhcp_senddiag oder - poll184_92_from14_sendpackets_q5_diag Ziel: Keine große neue RX-Reparatur zuerst. Zuerst Diagnose/Reparatur im post-DHCP-Sendpfad. Die neue Version muss für jedes spätere Ping-Paket sichtbar machen: 1. Wird WifiSendPackets erreicht? 2. Wie viele NDIS_PACKETs kommen an? 3. EtherType? - ARP 0x0806 - IP 0x0800 - ICMP innerhalb IP 4. Ziel-MAC? - Router 04-02-1f-f7-0d-b4 - Broadcast 5. Wird das Paket an den echten 802.11-DATA-Submit übergeben? 6. Wird ein 802.11 DATA Header gebaut? 7. Welche Queue? - Q5 oder andere DataQ 8. Wird Q5 tail erhöht? 9. Wird Doorbell geschrieben? 10. Kommt TXSTATUS? 11. Wird NdisMSendComplete erst nach echter Ãœbergabe/TXSTATUS oder zu früh gerufen? 12. Gibt es Gates, die nach DHCP blockieren? Minimal sinnvolle Debug-Zähler: - SendPacketsEnter - SendPacketsPacketCount - SendEtherTypeArp - SendEtherTypeIp - SendIpProtoIcmp - DataSubmitEnter - DataSubmitDropReason - DataQReady - DataQId - DataTailBefore - DataTailAfter - DoorbellWrites - TxStatusCount - SendCompleteCount - MediaConnectStatus - AssocComplete - RunComplete - Signal/RSSI/BSSID-State Wenn kein WinDbg auf XP64 möglich ist, sollten diese Zähler idealerweise sichtbar werden über: - sehr sparsame DbgPrints für DebugView oder - privaten OID-Dump oder - vorhandene OID/Vendor-Description-Diagnose WICHTIGE TESTKOMMANDOS FÃœR NÄCHSTEN CHAT ======================================== Sniffer Reconnect: sudo timeout 120 tcpdump -i wlp3s0 -e -s 0 -n 'wlan host d0:3c:1f:e1:2b:3e or arp' Sniffer nur 9560: sudo timeout 90 tcpdump -i wlp3s0 -e -s 0 -n 'wlan host d0:3c:1f:e1:2b:3e' Sniffer verbose: sudo timeout 90 tcpdump -vv -i wlp3s0 -e -s 0 -n 'wlan host d0:3c:1f:e1:2b:3e' XP64 Reconnect: net stop wzcsvc net start wzcsvc ipconfig /renew ping 192.168.2.1 XP64 IP prüfen: ipconfig XP64 ARP prüfen: arp -a XP64 statisches ARP: arp -s 192.168.2.1 04-02-1f-f7-0d-b4 XP64 statisches ARP löschen: arp -d 192.168.2.1 XP64 Sendzähler: netstat -e ping 192.168.2.1 netstat -e KURZER KERNSATZ =============== poll184_14 x64 auf dem Dell Wyse 5070 mit Intel 9560 kann Auth/Assoc/DHCP über Funk und XP bekommt 192.168.2.107, aber nach DHCP/RUN werden normale Windows-SendPackets zwar von netstat als Sent/Unicast gezählt, erscheinen jedoch nicht als ARP/ICMP/IP-Unicast-Frames von d0:3c:1f:e1:2b:3e auf der Luftschnittstelle. ARP, Router, Sniffer und Windows-Route sind damit nicht die Hauptursache. Der nächste Angriff muss den post-DHCP MiniportSendPackets -> 802.11-DATA -> Q5/SCD/Doorbell/TXSTATUS-Pfad untersuchen.

Views counter not counting caused by PHP upgrade. Waiting on patch.

More specifically, 25 years. @TSNH That will not occur as it is practically impossible. This was thoroughly investigated long ago.

You have no idea how large of a project it is to migrate a 20 year old forum full of custom code to a different forum software.

For some reason StartAllBack fails to hook the system context menu in Explorer and also the UWP apps system context menu completely stopped working due to UAC being enabled...

we talk a little away from each others, the "fix it" part was for notheretoplaygames not for K4sum1 and we have like 100 % the same meaning: "2) We-the-consumer can just slip back to a previous version - IT AIN'T GONNA HURT YOU ONE D@MN BIT TO USE A PREVIOUS VERSION." i totally agree on that one, but what notheretoplaygames also says is that he has to much of upgrades he says always something like "that upgrades go a little to fast" but here is where i tryed to point out you can fix this version trick - i dont have to repeat what i wrote about that, its a version trick in short again also you only missing the part with version 8 - thats the last one from the "common trick list" - there are certainly more - but having these would be ok for now and it does indeed work against that "fast upgrade problem" the other part regarding the user agent - if r3dfox has a problem with the new versions - yes the user agent is a solution that work against that - it might not fix it totally - but it would be a step into the right direction that same thing also goes for supermium - what is even the problem to searching for the value that is being added to not_a_brand with "version 8" ? thats the only thing you missing, its only 1 thing

Thanks for your reply and hints, @jumper! Yesteday, I checked all prefs related to memory management and performance. And there are a lot. After investigating them, I adjusted my settings, and now New Moon 28 behaves better than before. When starting the browser under same condition as before, the palemoon.exe process decreases its RAM usage from 184 MB to 139 MB. And after surfing some sites and closing their tabs, my automatic memory minimization in the background is now able to release more memory than before. But of course, that doesn’t solve the fundamental problem with browsers that run in single-process mode. But it’s a significant improvement nonetheless. My user.js is now totally optimised for my old P4 processor. Regarding your suggestion, I don't think setting browser.cache.memory to false is a good idea. My IDE hard disk is too slow for that. Although my RAM is SD-RAM, it is much faster.

Well, two things here. 1) There really is zero reason for r3d to fix what HE DID NOT BREAK. 2) We-the-consumer can just slip back to a previous version - IT AIN'T GONNA HURT YOU ONE D@MN BIT TO USE A PREVIOUS VERSION. This is where the Browser Universe is just a bunch of whining babies, it really is the biggest STUPIDITY on the planet that browsers are updated so d@mn fast and no matter how fast it is, there are always folks that want it FASTER. FASTER is WHY we have issues like this. Because the ecosystem is all about pushing updates out fast, fast, fast. INSTEAD OF TRULY TESTING THOSE UPDATES BEFORE SENDING THEM OUT INTO THE UNIVERSE. And we end up with an ecosystem that is "happy" because they get FAST updates instead of GOOD updates. Send out VULNERABILITIES all day long, nobody really cares, "because they fix them fast". No, what we have is that they CREATED those vulnerabilities and sent them out to a population DEMANDING faster update cycles. PUBLIC GOT WHAT THEY WANTED.

fact is some of them are doing this, and they will do this in the future why you just cant fix it ? what stands against that ? you leave up an option you certainly can fix - so to say i also understand it its a one time fix, its not like you have to bring out 150 versions of it ancient or not they are doing this but that i already said and the other thing both firefox and chrome have these - why we can not compare them in that matter ? what they are trying is a version check - while they offer zero new functionality a solution for this idiocy is to fix exactly that - a changeable version then they no longer can point out that bullXrap instead they have to rely on a new functionality - what they often dont do its like with a d3d9 vs d3d10 question - there is barly any improvment either video or 3dmodels and what they would do they would make a check for d3d10.2 and say - ha see now this dont work anymore for what purpose ?

I would try lowering the browser.cache.memory settings or disabling it altogether. Extensions CacheToggle and CacheSwitch can flush the memory cache out to disk.

If it makes any difference, the "missing-titlebar-bug", https://github.com/Eclipse-Community/r3dfox/issues/177 https://github.com/e3kskoy7wqk/Firefox-for-windows-7/issues/147 , is caused by a change between v151.0a1-v4 (last GOOD build of the 151 branch) and v151.0.2 (first BAD build of the 151 branch); so, not that big of a "regression window" to dissect ...

I disagree. For one, the user agent is ANCIENT TECHNOLOGY that is DYING, DYING, DYING. And for two, we should never lump Firefox forks (r3dfox, this thread) and Chromium forks (Supermium) into that sort of direct comparison. No offense, but web sites that still do use the ANCIENT TECHNOLOGY of the DYING user agent isn't exactly (pro and con) up to par with the latest "googleims" and therefore stuck with Site A relying on a faked OLD user agent, Site B relying on a faked RECENT user agent, Site C relying on something totally in the middle, and therefore those OLD SCHOOL web sites can never use a ONE-FOR-ALL user agent, you will always have to rely on the "user agent override" settings in about:config.

I'm seriously wondering what the significance is, ie, the "viral" aspect is, of that number THREE. e3k-blah... r3dfox... probably just overthinking it, but that 3 just feels like some "viral meme" that I'm just not "hip enough" to know.

hmm when you either stuck, dont want to make more of releases, coming to an end, versions dont go high quickly then it might be time for the same thing as in the supermium then it would be time for a user agent changer, build in

So I just shouldn't work on r3dfox is what you're saying? I like adhd hop between projects and r3dfox is taking a backseat currently, I don't even know if I want to release a v152 yet. I don't feel like diagnosing this when I didn't touch the code myself, I would have to trace and debug and it's a lot of work and effort for something I myself don't use. I do wish the feature worked, but I just don't feel like diving into it. This also does not affect ESR 140.

I know these forks are free, and it's their time, but if you're going to commit, then commit. Don't deliver because, "I don't feel like it". The browser artist known as e3k-blah (I friggin love that), is not going to further compile any ESR 140x builds. I appreciate these builds, but either deliver consistently, or don't.

Yes, when I check what and how, I will add the eMMC driver to my guide on MDL

The new version is very difficult to use. It wastes space, adds unnecessary features, and doesn't allow you to turn them off. old version new version

Yeah, I kind of assumed upstream as "e3k-blah" is also affected.

ty notheretoplaygames (picture 1) in the first 2 pictures i can see 2 different things at the first upper picture the "file edit view history bookmarks tools help" looks like a menu having that at the spot of the "window title" (picture 2) then "file edit view history bookmarks tools help" has gone downwards its no longer at the part of the "window title" instead at the window title now it has "Customize r3dfox -- eclipse r3dfox" and below it shows "file edit view history bookmarks tools help" it very much look to a menu (picture 3) in your second post you are showing v151 where the windows title is not showing "Customize r3dfox -- eclipse r3dfox" instead it shows what it shows in (picture 1) the menu "file edit view history bookmarks tools help" is at the window title in the second post (picture 4) does not show a differens so we can discard this one that also refers to a common problem devlopers often have (also supermium) often something is coming in like "this dont work - then like nothing else - no pictures - not where it happens - not how it happens - not even what the problem is - and often the most important: how it is to reconstruct to happening" - but rather you need to reconstruct the error - so you can see what the problem is

Oh it's that problem. I didn't understand the wording. It's an upstream issue for all Windows versions and I don't feel like diagnosing it.

Clover on legacy through CSMWrap (on UEFI Class 3, ASUS x509FA). I will try this when I have time.

Q.E.D. However, whether this is an rd3fox issue or an upstream issue is "not my problem", no clue if it upstream, no clue if it only r3dfox, don't care, neither is my default browser. edit: those are in Win10. so if this isn't doing this in Win7 or Vista, I cite again as "not my problem", but then we are faced with NO LONGER calling this "Vista+" but saying "don't use on 10 [or 11?]".