NotHereToPlayGames

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.

ps - by "I can run the original 2044 perfectly fine", are you also running 2044 with all of its "extra" .dll's and .dat's? Because I can "trace" with any disassembler and see the "errors" when exts.dat or sesafe.dll or seapp.dll or 360bdoctor.exe are being "hunted for" during launch. But same goes for all previous builds, all Humming Owl builds, and all Russian Repack builds. Aside from cloudurls.dat, only the files have been removed in all previous builds and that was always sufficient in the past.

Would you be willing to run different phases of the build instead of what was uploaded? ie, run "original" 2044's 360chrome.exe and chrome.dll then see what they do as I perform 10% of their updates, 20% of their updates, et cetera?

Unless I'm mistaken, you've had something similar in every version excluding your own 1030 (if I have you mistaken for another user, then apologies of course). Are you running your own "loader" instead of the one bundled "as-is"? Are you running any "real-time" virus program creating false positive with exception rules for your other browsers? FYI - the upside-down exclamation marks are removed from my skin, as is any "dark mode". So I would need you to PM me whatever skin/theme you are using to attempt any degree of a solution.

@rereser - I assume that when you are trying to get a bold font that you are using the Use system font size setting n conjunction with the XP theme settings?

Back burner low priority for me. I do intentionally hide the skin/theme button on my GUI. What's the point in removing Chinese telemetry if the GUI has a button taking you to a Chinese theme page? I've been meaning to do a Win10 theme one of these days. I still use the XP skin even when I'm on Win10.

I'll see if I can track it down. 2044 is technically the only version that didn't have a "Russian Repack" base. 2044 went straight from Chinese to English whereas other versions technically went from Chinese to Russian and then to English.

Let's not give up too soon. Perhaps you have to "apply" the theme, launch then exit 360Chrome, then revert and apply again. Have to make the theme changes and apply them when 360Chrome is not running. My default is Tahoma 8 regular - It's definitely changing to Arial Black 12 bold for me, then changing back to Tahoma 8 regular -

Cool. And correction - it appears 360Chrome only uses XP's Message Box theme settings (for font, bold/italic, and size but not for color).

I'm not quite sure I follow. Can you provide a screencap to illustrate?

I have that extension display:none hardcoded and it will always revert. I've technically always done it that way but I used to set the hardcode after uploading the "public version" without the display:none. @verta / @rereser -- The best I can determine is that build 1030, build 2022, build 2036, and build 2044 all are correct as far as the font setting BUT it SOMETIMES requires a "reset" when migrating between computers. To "reset" your theme's preferred font settings such as bold arial black, change a setting in your theme, revert it back, then APPLY all while 360Chrome is closed. Now open 360Chrome and you should see your bold arial black. Unsure what verta is using but the same applies, change a setting, revert it back, then APPLY all while 360Chrome is closed. It is the Message Box font that 360Chrome uses throughout its GUI. Some portions also use Menu but I haven't tracked down which portions of the GUI use which or if one overrides the other.

The arial black system font is very likely the same issue that verta is having. Not sure if I'll get to another update this weekend or not. The extensions page - I do that intentionally on my copy, I can revert it for the public copy. To me, it is unneeded rarely used clutter that I only bring into view when I do need it. To bring into view, access the Inspect panel, activate the elements tab, search for "action-links" until you get to a <div class="action-links">, highlight that line, then uncheck the "display: none" in the styles section.

Do you only have the default 62 fonts that come with XP or do you have additional or reduced set? http://thundercloud.net/infoave/premium/tips/xpfonts.htm

My letter M does not get smushed, even with your theme. However, your theme does highlight a very minor difference in letter C and letter P that should be enough for me to track down why this is happening. If my letter M looked like your smushed M, I would have abandoned 360Chrome a long time ago, lol.