NotHereToPlayGames
Content Type
Profiles
Forums
Events
Everything posted by NotHereToPlayGames
-
Nearly all of the bad-eyesight folks that I know all "swear by" anything-and-everything "dark mode". Why not try a "dark theme"? ie, something like this works in Supermium in XP+POS x86 -- https://chromewebstore.google.com/detail/dark-theme-for-google-chr/annfbnbieaamhaimclajlajpijgkdblo Normal Supermium: Supermium + above-link'd Dark Theme:
-
Firefox 52 no longer working on XP
NotHereToPlayGames replied to Dave-H's topic in Browsers working on Older NT-Family OSes
This is confusingly "not normal". I've never needed to use SAFE MODE to perform a NORMAL uninstall. I myself have never used Malwarebytes, so no clue what it/they consider to be "normal". I tend to think of things this way, "Can My Parents Do It?" ie, Malwarebytes would be STUPID to think somebody like my PARENTS would know how to get into SAFE MODE in order to perform an UNINSTALL. -
Firefox 52 no longer working on XP
NotHereToPlayGames replied to Dave-H's topic in Browsers working on Older NT-Family OSes
So @Dave-H, are you running an "extended kernel" ??? -
Firefox 52 no longer working on XP
NotHereToPlayGames replied to Dave-H's topic in Browsers working on Older NT-Family OSes
If I had to fathom a guess, you have used Revo to uninstall a program or two. I used to "swear by" Revo. Until using it to uninstall AVG/Avast (don't remember which, to be honest) forced a reformat/reinstall to get XP running properly again. Granted, that was DECADES ago, but the bitter and sour taste is still present. Technically, it was THAT experience that pushed me into VMs for "testing". -
Firefox 52 no longer working on XP
NotHereToPlayGames replied to Dave-H's topic in Browsers working on Older NT-Family OSes
Cannot replicate. Firefox 52.9.1.6822 is working for me in XP+POS (32-bit) with *NO* extended kernel (not a fan of them, technically not a fan of POSReady but been using it experimentally). This is from inside a VM. My era-correct real-hardware for an XP+POS deployment is still undergoing experimentation.
-
Firefox 52 no longer working on XP
NotHereToPlayGames replied to Dave-H's topic in Browsers working on Older NT-Family OSes
Available here - https://archive.org/download/firefox52.9.1esr (x86 and x64, I only screencap'd x64 below)
-
And that (D3D9!) was all it took to return my water sewer bill to an infinite unsolveable Cloudflare captcha loop! Even as high as Chrome v144. D3D9 flag is working in Chrome v143. No video stutters in v143 *when using* D3D9. What a d@mn F'in Nightmare all of this Cloudflare sh#t is evolving into !!!
-
Solved. v141 updated a flag "behind my back" that was set in v140. Returning the #use-angle to D3D9 setting which was set in v140 but v141 updated to "D3D11 WARP" solved the video stuttering.
-
So I've now had TWO consecutive "forced updates" that both did the same exact thing on my end. That result being that Cloudflare captchas would loop endlessly and never be able to be "solved". The "are you human" checkbox would show a checkmark after solving the puzzle (only for a split second), but it would only take you to another puzzle. Endlessly. The first time was last November. The solution was a "forced update" from running Chrome v136 and manually updating to Chrome v140 (v138 technically solved, but v140 solved a different issue). The same exact thing happened yesterday. Cloudflare captchas would appear to solve but all they would do is take you to another puzzle. Manually updating from v140 to v141 solved the endless captcha loops (but presented video stutter issues that v140 did not have!). In both cases, the first sign of something happening was that Google Search would present Cloudflare captchas EACH AND EVERY TIME you visited Google Search. They would "solve" but you were presented with it EACH AND EVERY TIME you visited Google Search! In both cases, my water sewage bill would present the unsolveable endless loop! This happened EXACTLY in this manner in November. And again yesterday. Simply can not be a "coincidence". The Cloudflare captcha server-side algorithms being updated to use new coding is behind this. They (the algorithms) are getting smarter and smarter at detecting "old browsers".
-
And without veering too far into OT Land, the install of v23 on XP, which technically was only a stub to download and install v22, that stub downloaded four or five PNG files in addition to the EXE installer. Only the PNG files/connections were logged in HTTPSProxy, not the EXE. I find this interesting because AstroSkipper's installation (one of two partitions) is missing the wallpaper images (which I have not looked into but I have to wonder if they are PNGs). ie, the PNGs came from a server that needed to pass certificate chains but the EXE did not (ie, the offline/stub did originate from an HTTP address, not an HTTPS). ie, Panda's installation communications have http connections to pull in an EXE but have https connections to pull in PNGs. I would claim that Panda is doing that because it makes it VERY EASY to log every IP Address that requested the EXE. Server logs for the website (https) and PNGs (https) would be a MILE LONG. Server logs for the EXE would only fill one 8-1/2 x 11 per day or week.
-
I have. Before browser "forks" came along, browser "shells" were common (Sleipnir, MyIE2, Maxthon, SlimBrowser, GreenBrowser). They all used the IE "engine" and "iexplore.exe" could be prevented from launch or network access by way of firewall rules but the "shell" would still have access through IE's "proxy". The earlier versions of Panda are basically acting as a "shell" to the Internet Explorer (and/or Edge) "engine". The question that this begs is can Panda be activated on systems where firewall rules wholly and completely block IE/Edge (not only the browser but the "engine" also)? ie, did the activation throw a firewall nag? or did it just "connect" because there was already a firewall rule "allowing" IE/Edge?
-
Agreed. The earlier versions of Panda seem to use INTERNET EXPLORER's proxy settings (which you proxified when setting the proxy to run "system-wide").
-
Okay, that explains it. I *never* use a REAL email address for these types of things. *NEVER* v23 would CONNECT (through HTTPSProxy) but then fail account creation saying the email account was unreachable. I tried EIGHT different "temporary email" services, Panda could not "reach" any of them. ie, has them all blacklisted, not uncommon [MSFN accounts can also not be created with temp emails, something that *ticks me off* but "is what it is"]). v21 would not even try to connect to the "temporary email" services [direct, no proxy] (which is inline with your statements). Just the way I do things, Panda will *NOT* get my email address. But I could create a "throwaway" Gmail and activate that way if I opt to keep Panda.
-
I can't get it to ACTIVATE on 100% Native XP+POS. The ACTIVATION may be where HTTPSProxy becomes a must.
-
I can report that Panda Dome 21 does indeed install on a 100% Native XP+POSReady2009 (ie, *no* HTTPSProxy, *no* ProxHTTPSProxy, *no* Proxomitron, *no* Cert Updates of any kind, IE never even launched until the Panda installer launched it!). And it also offered the OFFLINE installation checkbox (which I selected during install). This is a completely updated XP+POS, immediately after install of OS (plus all OS updates/hotfixes) *only*. Completely virgin XP+POS. It did not get a different version of Panda that needed uninstalled first in order to install v21.
-
Technically, THEY ALREADY HAVE. "We" are only able to get it installed by using programs that are not part of XP, how many of even us MSFN Geeks truly consider that route to be "supporting" XP? And the "exception error" that I was getting in LTSB 2016 indicates to me that they don't support "Win10", but rather only "new Win10".
-
Yes. Not in LTSB 2016, but yes in 24H2. In 2016, it "installed" but attempts to open the GUI resulted in an "exception error". At what version of 10 did the "exception error" get fixed is unknown. I've already deleted the VM clones. I could reclone/reinstall if screencaps are required. Basically, I know enough at this point that my "real hardware" XP will *not* be getting Panda Dome (it may not get ANY antivirus, to be perfectly honest, it's just for out in the garage).
-
The same exact v23 *offline* installer when ran in Win10 *ALLOWS* for an OFFLINE installation. In XP, the *Offline installation* checkbox is disabled so you are forced to use the offline installer as a "stub" that downloads v22! XP: 10:
-
one moment, ran out of space to allow copy-and-paste screencaps... bad news, that means all previous screencaps will be deleted (my time is too valuable unto myself to use any image hosting services, sorry, just 'fact')...
-
The same exact v23 *offline* installer when ran in Win10 *ALLOWS* for an OFFLINE installation. In XP, the *Offline installation* checkbox is disabled so you are forced to use the offline installer as a "stub" that downloads v22! XP: 10:
-
Also, as another "teaching lesson", monitoring your TEMP folder is generally a MUST during ANY "install". It's also a great way to get (and archive) the "real" installation file(s) even if using a tiny "stub" that downloads the "real" installation files. In general, as long as you do NOT close the "stub" or pull from TEMP folder "while" it is running, then you can copy the "real" installation files from TEMP before the "stub" deletes them.
-
I'll test in a Win10 VM. It really is the *BEST* way to TEST. You can try all the "uninstaller" programs you want, you will find that installing/uninstalling "frequently" has a tendency to "F Things Up". Keep that baseline VM and only install into clones, DELETE the clone when done testing. This approach is the GUARANTEED *ONLY* approach to ***NEVER*** F anything up!
-
Same here. The "original" v23 offline installer (from Softpedia) is denied installation due to you canNOT install ANY of these **OFFLINE**. You MUST be connected and those "communications" will not allow archived installers to install OFFLINE. So basically even OFFLINE installers are being used as "stubs" to download installation files. Pretty clever, actually. The 120MB install .exe is placed in your TEMP folder and THAT is what you are really installing, NOT the .exe that pulled in that TEMP .exe. Also, if you MONITOR your proxy traffic, the PNG files are being used as some sort of method to detect what installer is being executed. Again, pretty clever.
-
Everything within the SOFTPEDIA download appears to be MUCH more TRUSTED as **REAL** v23.
-
According to Major Geeks, v23 should be dated mid-December of last year. (Major Geeks does not offer the OFFLINE installer.) Softpedia also indicates v23 should be dated mid-December of last year. I personally would not "trust" the files from FIVE DAYS AGO. If they came from an httpS source, I wouldn't be so skeptic. No offense, but I will **NOT** be installing that http-sourced file! It is just not the way I historically do things, don't see the need to change now.
