Bug with celestia builds from svn and github

[HB]

Since recently the activities around Celestia is growing, I'm also want to catch up with that. So, I'm busy to setup my Celestia Developing environment again.
My latest build was a while ago. Version 1.6.1. rev 5229.

I rebuild that one to see of the VC++ 2008 is still working. Also I've build the Github version 1.7.0 revision 5233.
Later on I did the same with VC++ 2010. All without any problem, I thought.

I'm using Bullguard 2016 Internet Protection for security.
As soon as I right click on an object, a planet, and ask for info from the 8/9 planets website than Bullguard detect that as a dangerous program. Mostly I can recover that by sending a reply to the virus scanner as a false positive. But sometimes Celestia crashes. Buildguard might be very touchy with that. But the weird thing is that the download package celestia-win32-1.6.1.exe do not give any problem.
The executables of the homemade build and the downloaded one, differ in size. So, I wonder with what kind of version is the package build? And are some libraries left out? With what kind of VC++ compiler setting is celestia-win32-1.6.1.exe actually build?

Winows7 32bit Enterprise.

[Alexell]

HB, I am using VS2008. The size of the compiled exe file of the original revision 5229 is slightly more than 3 MB (can not remember exactly).
Size exe file from the repository GitHub - 3.31Mb

Added after 1 minute 41 seconds:
And please do not forget to change the configuration to "Release"

Added after 1 minute 44 seconds:
I mean just only executable celestia.exe

[HB]

Alexell,

Thanks for your reply.

The size of the release builds of SVN Celestia rev 5229 is 2.997 Kb. The Github revision 5233 is 3.391Kb in size. Both build in release mode with VC++ 2008.

Celestia.exe of the celestia-win32-1.6.1 package is only 2.778Kb in size. So large differences. Maybe something is missing in there.
The icon of your Github release is much larger than the original one together with all the other extra button bitmaps may explain the difference in size of a Github or SVN build.

By the way, the resource.h file of the SVN 5229 revision contain still as version 1.6.0. while that SVN release is announced as version 1.6.1.

[Alexell]

HB, Judging by the exe file size that you specified, all right. My icon is larger than the standard, included to several libraries that have not been used previously, add icons to the menu. Hence, the increased size of the final executable file.

[HB]

Alexell,

So the size difference is explainable for Github Celestia. But not that Celestia builds from both the Github and the SVN sources will crash while Celestia.exe from the celestia-win32-1.6.1 package is not.

[Alexell]

HB, I do not understand what you're talking about crash? Celestia from GitHub compiles and works fine.

[selden]

If the binaries you produce are not bit-for-bit identical with those on GitHub, then there are things in your build environment (settings, libraries, compiler versions etc) which are not the same. All of those differences need to be identified and understood. Some are irrelevant, but the differences which cause crashes are very important.

Of course, there are many things which can cause an executable to crash on one system and not on another. Sometimes it's differences in the software (e.g. the use of different build libraries) , sometimes it's differences in the runtime environment (e.g. bugs in graphics drivers). With Celestia, you also have to be concerned about "the phase of the moon". When working with something other than an astronomical visualization program, that expression is often used to describe incidents which have no obvious cause. With Celestia, though, it's very relevant. The same viewpoint at different times might show different objects and invoke different routines, some of which might contain serious bugs.

[HB]

Selden,
If I start up the default internet browser before Celestia, than there no problem at all. But when Celestia has to start up the browser from within the program then it would be seen by Bullguard as an suspicious program. If I do not reply to Bullguard that it is a false positive, it will close the program and place it into quarantine.

I'm aware that the size differences may depend on the environment, the settings and so on, but that's not where I'm worry about so much.
However, the difference in size of the rev 5229 SVN build and the executable size of the celestia-win32-1.6.1 package tells me in a first glance that something is left out in that package or has been build something different than with an ordinary VC++ compiler.
So far, I've tried every possible way to build the executable with with VC++ 2008/2010 express editions. All with the same bad result.
It becomes for me more likely that it is related to those VC++ compilers because some old builds from before 2011, but build with VC++ 2008, give the same problem.

What I try to figure out is why my home builds can't coop with Bullguard anti-virus while the executable from the celestia-win32-1.6.1 package doesn't give any problem.

For this kind of investigation I'd like to have is as much as possible information of how the executable of celestia-win32-1.6.1 package is build.

Added after 1 hour 30 minutes:
Alexell,

The SVN/Github builds I've made with VC++ 2008 / 2010 can't coop properly with Bullguard Anti-virus when Celestia has to open a Internet browser.
It classifies Celestia as a suspicious program and put it in quarantine unless I tell Bullguard that it was a false positive. This is not happening with the executable of celestia-win32-1.6.1 package. It is of coarse a kind of personal situation, maybe I'm the only user in the world who's using Celestia in combination with Bullguard Anti-Virus.
So whatever you call this behaviour, a glitch, a malfunction, a bug or even a crash, it should not happen. Surely because a Celestia release can work without such a problem.

I didn't check yet what happen when I set Bullguard to a lower detection level if that is possible. But if it can, than I wonder why I've bought such an expensive Anti-virus program.
For the time being a proper workaround is that you start up the internet browser minimized in the taskbar before you start Celestia. But that's not normal.

[John Van Vliet]

default internet browser before Celestia

that would be what ???
edge ?

microsoft is known to be a royal pain in the ass in this area

most software just calls "browser" and the default set in the OS is used

visual studio hardcodes this to INTERNET EXPLORER and not "browser "
or they were the last time i was using visual studio


as to AV
BOTH mozilla and Google web browser developers have come out publically to state that the componey MS bought up for "windows defender" is the ONLY one you need and the ONLY one that plays NICE
( and that is really odd normally it is the other way around )

use the win 10 default auto installed AV

[HB]

John,
That's what I mean: the default browser is the one what has been set in Windows and what will be opened by Celestia at the moment that you want to go to the Nine Planets to grasp information.

It might be true what the developers of Google and Mozilla are saying about windows defender, but I use Bullguard and that AV-program has discovered a difference in the behaviour of Celestia. I just want to know why.

I use Windows 7 enterprise. So the auto installed AV version of Win10 is not an option for the moment.

[Janus]

To HB

The first thing windows AV programs do now is check to see if the EXE/DLL has a cert/is signed.
Almost any program without a cert that launches an external program can trigger an alert.

I have had to drop AV on almost all of my machines because of this issue.
What happens is the AV first runs a copy of the program in a sandbox for several seconds to see what it does.
It then closes that copy down and analyses the results, before running the program for real.
If it lacks a cert and automatically launches an external program, pop alert.
If the program then behaves differently while being run, like launching something else, it pops an alert.
Sometimes it treats a new window of a program as a launch, other times it does not.
Sadly, there is no way for you the end user to control that.

Because of the brain dead decision to integrate the default web browser into windows, windows has some unique vulnerabilities.
If you compromise the OS, IE is as well.
If you compromise IE, in most circumstances, the OS is as well.
The single biggest reason for this is many parts of the UI are actually activeX components.
Not web as in microsoft.com, but web as in actually rendered by the same activex DLLs as IE itself uses.
The same applies to web content on the desktop.
On windows, using a jpg/jpeg file for your desktop background, it enables activeX and web content as well, which translates the graphics format.
If you use a bmp file instead, it foes not.

So on windows AV vendors started watching for malware behavior in addition simple virus scans.
The ability to simply scan what is run instead of profiling a programs behavior has been removed by AV vendors.

As much as I hate to give credit, defender is as brain dead and simple of an AV scanner as you can find anymore, which is at least simpler.
These days AV programs monitor the firewall, memory allocation and many more processes, integrating themselves into everything.
The result is inconsistent behavior, and slow computers.
Short of becoming your own cert authority, adding yourself to the windows cert store, and signing everything, there is nothing any end user can do.

The further M$ distorts W10 into a cloud front end, the less control end users will have, until they have none.
Just as home computers destroyed the mainframe terminal markets decades ago, M$ is trying to destroy the home computer market by making them all slaves/terminals to the cloud, for a modest monthly fee.
The benefits are login anywhere, on any machine, the downside is trusting M$ with literally everything you do, and no longer really owning your own computer or data.

As for myself, I use clamAV, which is open source.
I have some custom stuff setup to automatically scan what I download with it.

About the closest you are going to get to sane behavior is to exempt celestia's directory from your AV, assuming it lets you.

Good luck.


Janus.

[John Van Vliet]

in visual studio check to see what is being HARDCODED
it is likely " Internet explorer " and not what YOU set as default " firefox " or "seamonkey" or "opera" or"safari" or the popular Google Chrome / Chromium

Visual studio has a debugger
run the dbg then at the segfault put a break point and run through it to see exactly where it crashes

i am betting at the IE call

[Fenerit]

Just a thought. The installation of the "celestia-win32-1.6.1" package makes an entry item named "Celestia" within the registry while your compiled .exe makes instead an entry item named "Celestia Development Team" at execution. These entries stores some settings for the relevant versions. Maybe the AV is sensitive to that: say, it learnt "celestia" .exe upon "celestia" registry and dislike "celestia" .exe upon "Celestia Development Team" registry. Perhaps you should try to clean up both entries (don't panic, its safe, at least on Xp) along with AV references, logs, settings or whatelse specific and then to load just the compiled .exe to see what happens at browser loading...

[Alexell]

Fenerit, I agree.

[HB]

To Janus, JVV and Fenerit,

Well Janus, it is a good story. It shine's another light on AV issues. All the AV programs around the world are designed for one thing only: keep the cybercriminals far away from your computer. Those guys using all possible ways to get to the kernel of your computer. That why you have so many flavours of AV-software.
I have a Personal Computer and I want to keep it that way. So I agree with your horror scenario regarding the clouds. All those cloud providers want to make money. Another disadvantage is that it is more easy for Big Brother to see what you're doing.

To John,
I have the windows Internet Browser as the default with a minimum of plug-ins. Because it start up fast. Google Chrome I use as secondary browser. It starts up much slower than IE but is remarkable faster when browsing the internet.
I try it all: disabling IE and use Chrome as default, uninstall Chrome with of coarse IE as default and have both installed with one of them as default browser.
That phenomena with Celestia remains under all circumstances.
Whether or not IE is hardcoded, Celestia sent out a url like this:

if (url.empty())
{
string name = sel.body()->getName();
for (unsigned int i = 0; i < name.size(); i++)
name[i] = tolower(name[i]);

url = string("http://www.nineplanets.org/") + name + ".html";
}
So only your favourite browser should be activated.

To Fenerit,
Thanks for your suggestion. It was a reasonable good explanation, so worth to take a closer look into the registry. Unfortunately only MRU lists and Caches contains the name Celestia and of coarse by the extensions cel and celx.

[Fenerit]

Both are under HKEY_CURRENT_USER/Software and within "Celestia" there is indeed nothing; within "Celestia Development Team" is duplicated the key "Celestia" as subkey, which acts like root for others keys.

[John Van Vliet]

the hard coding is not do to the celestia code

it is done by visualstudio at the time of compile
or at least used to be a few years ago
you are using VS 2008 so that is more than just a few years old

run a debug trace

[HB]

I still wait on an answer or explanation to the different behaviour of the executable of celestia-win32-1.6.1 package and the ones I've build myself with VC++ 2008/2010 express editions.
Especially the question about the way the executable of celestia-win32-1.6.1 package is build and with what?

So, please is there still someone out there who's able to give me some clues?