NotHereToPlayGames

Ah, thanks. I was actually kind of suspecting that this was due to an unsupported OS / Service Pack basically being "played off as" some sort of "security risk" for those of us running SUPPORTED OFFICIAL Operating Systems. Future references to this "trojan scan" shall be ignored, of course. Thank you, @we3fan. edit: "official" versus "supported, since neither XP or Vista are technically "supported" operating systems

For what it is worth, I am staying on 2036 thus far. My fingers are crossed for better assistance with the Vista x64 "scan" report before I can in good conscience bring 2044 to here at work. Our Global IT is not that smart and our department forces them to change their "rules" constantly, but I can't really tell the department that I "need" 360Chrome for "work-related" tasks, lol.

Regardless, I cannot replicate and I cannot fix what I cannot replicate. Moving on... No need to hijack over something we've already discussed.

I preferred 1030 over everything else. While working on 2036, I accidentally corrupted my 1030 when I was byte-comparing the two builds. I'd have to redo my 1030 from scratch and haven't revisted as of yet.

Not to "sound like a broken record" ( https://www.merriam-webster.com/dictionary/like%20a%20broken%20record ), I need the name of the real-time "protection" that reports the CLAIMED trojan scan. Only the Vista Group is making this claim, I have installed Vista x86 and I get no trojan scan suggestion. NONE. ZIP. And that "zip" as in ZERO, not "zip" as in file compression. I even provided a screencap. Until whatever is giving that "scan suggestion" is revealed in its entirety, how in Hades is anyone expected to replicate? If I cannot replicate, I cannot fix, it's kind of that simple.

I thought somebody here posted an English Translation of some of the version "fixes". Can't find them at the moment. For the most part, there's not really anything to "gain" between one version and the next. I'd still be on 13.0 build 2206 if it weren't for MSFN Members requesting something newer. I briefly reverted to 13.0 build 2170 and would still be on it if it weren't for MSFN Members requesting something newer. I'd still be on 13.5 build 1030 if it weren't for MSFN Members requesting something newer. I'd still be on 13.5 build 2022 if it weren't for MSFN Members requesting something newer. I'd still be on 13.5 build 2036 if it weren't for MSFN Members requesting something newer. I personally feel that every one of those "upgrades" never really gained me anything, never once have I ever witnessed a web site that one could "do" than another could "not". They're all v86. Nothing more. Nothing less. v86 technically still performs EVERYTHING that I throw at it. And I really do mean EVERYTHING. It remains my DEFAULT even on my Win10 computers. Sure, there has been a few .css oddities here and there - always fixable through built-in Dev Tools. But I myself do not subscribe to the notion of a "permanent fix" for a once-in-a-lifetime web site I find myself on that I will never ever be on again in four lifetimes let alone one.

That sounds to me like an error/bug in 2036 (and perhaps even older versions) and that 2044 is doing what it is supposed to do. ie, setting the system font to arial black regular creating a BOLD font in 2036 instead of a REGULAR font as "requested" by they system font == error/bug. Looks like it basically took upstream all the way up to 2044 to finally FIX that error/bug. Why import an error/bug from an older version into a newer version? More importantly, why can you not have the system setting on bold if that is the GUI outcome you are wanting? Tahoma 8 regular: Tahoma 8 bold: Arial Black 8 regular: Arial Black 8 bold:

If you want to get really complex, you can "log in" to websites without ever enabling cookies, you just need to grab the "contents" of the cookie and use them over and over again, from any computer. The power of Proxomitron.

Have you tried HyperSnap ? I still use Snagit but you will need to use older versions than even my old version. According to a few searches, Snagit 8.1.0 was the last version for Win98.

Search-engine search for "winpenpack chrome". Perhaps the "loader" used for X-Chromium will work for you? I actually use that "loader" for my Ungoogled Chromium at work so I could test tomorrow.

Perhaps use the entire path instead of using %UserProfile% ?

I have not tried this, but Chrome's original (ie, non-loader) command line argument to place the profile in the Application Data folder of the user profile was --profile-directory=Default

Absolutely. Added to my to-do list. There is at least one more telemetry leak (0 bytes, no connection, but I still want it gone 100%), but will likely be next weekend before I do another update.

Interim r2 update. https://www.dropbox.com/scl/fi/yh2qingwvf1u0jdez25cg/r2-interim-release.zip?rlkey=qfu2zn7u1bm6gfvequ0k2o9jf&dl=1 chrome.dll >> removed additional telemetry items en-us.pak >> corrected unicode error (two "spaces" being displayed as a "square") resources.pak >> will need to extract/replace regular or ungoogled depending on preference -- restores Extensions page "action links" still to-do - 2036 versus 2044 "bold" GUI font on some OSs "ProcHack" detection on some malware/antivirus scanners

I have scanned both 2036 and 2044 using Malwarebytes Premium Trial and found no threats. 67 files in 2036 plus 70 files in 2044 = 137 scanned items. Zero threats detected, zero detections ignored.

A non-political be safe, fellow MSFNer.

This is a legit concern, to be perfectly honest. It is also a very highly discussed false positive on several real-time protection forums (I found it on Kaspersky, Symantec, TrendMicro, and BitDefender discussion boards). Apparently, even Windows' own Task Manager is also one of these false positives. That said, being false positive or not, this would prevent me from running build 2044 at work. I have been running build 2036 at work for quite some time, so I have to assume it does not have this false positive or Global IT would have sent me a "nastygram" asking if this program is "work-related".

Agreed! I've started to view that and similar as "naysaying". Oh well. I have a need for 360Chrome, it continues to work for me. Onward and upward.

Vista x64 won't install anyway and I'm not about to install it outside of a VirtualBox VM. I run an older version of VirtualBox and have no need to upgrade and will not be installing Vista x64 on real hardware. There comes a point where we have to regard reports as "naysaying" versus "productive". I don't think any of the Vista Group really truly runs 360Chrome outside of just a "surface curiosity" anyway. We already basically "hijacked" the thread for a real-time protection that is simply not part of x86 Vista out-of-the-box and no evidence provided by the x64 Vista Group on just what caused the error. Almost looks like an "agenda" to me. Again, I'm willing to fix if I am provided with the means to recreate. As is, I've demonstrated my release to work in Vista x86. I may try x64 again tomorrow, if I'm bored. If I am provided with what caused the error, I am willing to seek a fix. Other than that, the userbase is too small as is to spend more time on this. Let's face it, those of us (myself included!) that use 360Chrome on a daily basis as our everyday default web browser, are not going to be steered away from it by an "error" that we ourselves cannot reproduce.

I'm downloading Vista x64 as we speak. I'm 100% confident before even installing it that my release will run in it also. I really need more details on what real-time "protection" is throwing this warning. But at the same time, if it's only the Vista Group that doesn't really use my releases nearly as much as several other MSFN Members, then I have to feel this discussion is kind of just "wasted time".

I already knew you would. I'm still waiting for the 3rd member of the Vista Group to also show up. If we truly want this fixed, I need to know what real-time protection is telling you this because I have no issues in 32bit Vista as my screencap above shows. I went out of my way to download and install Vista. Not much more I can do here without knowing what real-time protection is providing this error.

I have zero issues in running in Vista. This is not an extended kernel Vista and I doubt I will be able to test any extended kernel (they have their place, they're just not for me, both "sides" are perfectly valid). Please indicate what real-time protection you are using that reported that error because it is a valid discussion to either a) "pass" that real-time protection by improving my release, or b) prove the report is a false-positive and leave the release as-is.

It could be that all of the descriptions, product names, and product short names need to MATCH for Vista but XP and 10 just don't care about them not matching.

<sarcasm> Didn't you read? </sarcasm> It's all right there in the third post of this thread -- https://msfn.org/board/topic/185049-arcticfoxienotheretoplaygames-360chrome-v1352044-rebuild-1/?do=findComment&comment=1252587 It is the "crash reporting" that is edited out of the .exe and also the Chinese text. I wonder if it is the removal of the "crash reporting" or the removal of the Chinese file description, product name, or product short name? -- I could provide different versions of the .exe if you are truly interested in testing. I do not get the errors and you are the only one that does - doesn't make it invalid, of course, and we can fix it.

Of course I read it. Comments like "didn't you read" are condescending. Moving on... I kind of have to leave it at this. If the aswer to the above is "no", then we're kind of done here, don't you think? If the answer is "yes", then thanks in advance.