Branch development VS & QT & 64-bit

[Janus]

Ok, a couple of weeks ago a VS2010 branch of celestia was created on github by alexell.
I grabbed it and started tinkering.

First I updated the sln setup to VS2010.
Fixed a few glitches there, and got it to compile.
During this, I ran into issues with the supplied libs.
Once I identified them, I grabbed there sourcecodes, and recompiled them using VS2010 so I could statically like them all.
This worked with everything except libintl, probably something simple a real C/C++ programmer could fix easily, but i am not one.
I redid the windows\lib & windows/dll trees with x86 & x64 both.

After fixing a few random glitches, I had it compiling and trying to run.
Traced constant crashes to fmod, so I commented all of the sound stuff out.
Now it not only compiles, but runs as well.
Got it compiling and running on VS2010/12/13 in 32-bit mode.
I was also able to set MFC and other libs to static to it does not require the VS redists.
{Do not forget to change toolsets, or it will make a mess all over itself.}

Shifted to QT, which is not my favorite, not my favorite by far, but usable, though bloaty..
Updated QT from 4.x, to 5.0.
That was a fail, glitches remain with it, and they moved on rather than try to fix in place.
Stepped up to >5.4 as per advice from toofri on celestialmatters, which was good advice.
Apparently >5.0<5.4 has some "issues" that will not be fixed, just don't go there..

Eventually got QT5.4 working, there are notes inlined for those that care, or I can make another post explaining them if needed.
At that point I had QT5.4 w/VS2010/12/13.
Soon enough it was QT5.4/5.6 w/VS2010/12/13.
Regression testing eats time like there is no tomorrow though.
Eventually got QT5.8 as well.
{Note here, QT does not support static linking of MFC or VS libs if not statically linked itself. This is a limitation of QT, so the QT versions will require the VS redists to be installed.}

Then I had VS2010/12/13 w/QT5.4/5.6/5.8 all in 32-bit.
I sent a message to Alexell and put that up for him to look at and update his VS2010 fork using it as a base.
That was about two weeks ago.
My messages remain in my outbox.

Since then I have been trying to get 64-bit working in VS, which is every bit the PITA it sounds like.
VS2010 and 64-bit stopped when I realized I was spending more time troubleshooting VS, than why the project was crashing.
VS2012 and 64-bit compiled just fine, then crashed on DSODB:load quite oddly.
Having time to kill since my last job was turned into a two hour spelling mistake caused by UTF vs Unicode vs assmbly language, not two weeks of tracing link logs and VMs stepping through binaries, I amused myself.
Stepping through to the VS2012 code, I discovered that it has some 'Issues' when it comes to string:: and new and some others, but only in 64-bit.
The final outcome is that VS2012 does not stably produce 64-bit programs in a multiplatform or standard way.
Using VS2012 would require non portable changes to the code, so I kicked it to the curb.

That brought me up to VS2013, whose UI is garbage, whatever happened to 3D effects, what kind of moron thought having everything the same color with no borders made a good UI anyway, the same sort of braindead moron who thinks ribbon interfaces should be forced on us?
Sorry, rant mode off, but I hate the modern looks like a sketch pad interface style.{Win3.x was more usable and easier to navigate.}
Anyway, I got 64-bit compiling, and then running using VS2013.

Once there, I turned to QT once again.
My first observation here is simple, documentation for QT is broken.
It feels by design, but I do not believe it is, I believe it simply people seeing the world through blinders.
I can detail what I found if anyone cares, or they can study the .pro file.

The result is I now have 64-bit working in VS2013, and QT 5.4/5.6/5.8 w/VS2013.
I have not fully tested any of these, only enough to know they run and over all appear to work.
QT 5.8 lacks the icons on the tool bar, but that is the only real issue I noticed in my five minutes of testing on each of them.

I do not have VS2015 to test with, only the buildtools, and I am not sure if I ever will.
Its telemetry would have to be disabled/removed before I could consider that.

So my question is thus.
Does anyone here care about 64-bit?
Do I put the code up on my site for others, or just wait to hear from Alexell?


Janus.

Edit:Fixed some spelling glitches.

[john71]

I think you should make it available for everyone.

[John Van Vliet]

i have no idea if my fork of qt5 builds on win10
dose a 7 year old VS 2010 even run on win10 ? ( a win7 program on 10 ??? )

now on linux i do have a ton of warnings but only one major bug -- SO FAR -- .
crashes when refreshing the celestia browser on a star system NOT sol

and a old one i have not fixed in the bookmarks ( crash when removing the very last bookmark in the list )
this was a issue even in qt4

[Janus]

i have no idea if my fork of qt5 builds on win10
does a 7 year old VS 2010 even run on win10 ? ( a win7 program on 10 ??? )

now on linux i do have a ton of warnings but only one major bug -- SO FAR -- .
crashes when refreshing the celestia browser on a star system NOT sol

and a old one i have not fixed in the bookmarks ( crash when removing the very last bookmark in the list )
this was a issue even in qt4

I have no idea what so ever what will or will not run on W10.
I am not letting that advertising virus anywhere on any system I am responsible for.
The only W10 installations I have dealt with were in vbox, on a standalone system.

For me, everything from W8 on is not windows, it is a mislabeled malfunctioning appliance front end.
Even the scattered desktops of Linux {Gnome[even 3], KDE, Mate, Cinnamon, LXDE} that drive me nuts are better than it is, and more organized.
As of W10, it is also a security issue, no OS that reports back home can be called secure.
A leak is a leak, and it leaks by design.

I do not understand what you mean by refreshing a star?

I have also never used bookmarks, I was unaware of the function since it is not something I would use in Celestia, so I never looked.

Being blunt for a moment, I honestly do not understand why people like the QT interface, I find it awkward myself.
That and programming limitations in it have left me feeling like developing a wxwidgets or foxtoolkit gui for it.
Of course doing that development is beyond my skill level right now, but I do learn.

As I have said, I am not a real C/C++ programmer, all I do is match and use patterns when stuck using them.
Though I can use Javascript, Lua, PHP, some shell scripting, etc.
I prefer assembly, authentic basics[NOT VB!!, VB is not basic], pascal, ladder, some cobol if needed, fortan if I must, etc.
Python & Perl just confuse me, though I have managed to modify a couple of Perl scripts.

I tried to update the included LUA, but ran into deprecation issues I was unable to deal with.
I also lack the knowledge to update Eigen, which is needed.
All matrix math is a blank spot to me, I just can't do it, it makes no sense at all, to me anyway.

So, do I wait to hear from Alexell, or put it up now.
Are enough people interested to make it worth it?


Janus.

[selden]

I think you have to work hard to write a Win7 x64 program that doesn't run under Win10. Even Celestia v1.6.1 works fine.

I think the major attraction of QT is that it can provide a uniform GUI across multiple operating systems. Celestia v1.6.1 has several different GUIs. Two major GUI philosophies are whether a particular application should have the same GUI everywhere or if all applications on a particular OS should have the same type of GUI.

Personally, I see no reason not to make your (temporary) branch of Celestia x64 publicly available. The more people who test it, the more bugs can be found and perhaps fixed by the time it gets merged into the "official" version.

[Janus]

I think you have to work hard to write a Win7 x64 program that doesn't run under Win10. Even Celestia v1.6.1 works fine.

I think the major attraction of QT is that it can provide a uniform GUI across multiple operating systems. Celestia v1.6.1 has several different GUIs. Two major GUI philosophies are whether a particular application should have the same GUI everywhere or if all applications on a particular OS should have the same type of GUI.

Personally, I see no reason not to make your (temporary) branch of Celestia x64 publicly available. The more people who test it, the more bugs can be found and perhaps fixed by the time it gets merged into the "official" version.

I have nothing against it working with W10, I simply do not care.

I personally do not care about having 'the same' GUI, only one that is easy to navigate.
Which is part of why I detest so much of modern windows UI esthetics.
Some of us actually use the '3D' borders and such that they are so ardently removing.

Since 3 of 3 so far say put it up, it is up.

http://celestia.simulatorlabbs.com/Downloads/

Forgive the crudity of the site, I am not a web programmer, and eye candy drives me nuts anyway.
I like things as simple as they can be, it makes it easier to just work, which is my philosophy.
Simple though, is in the eye of the beholder, and far more importantly, in the context.

Since this is temporary, I have simply separated things by date.
Today's directory contains the VS2013 & QT5.4/5.6/5.8 source.
When using with VS2013, you will also need to install 'vc2013_mbcsmfc.exe' which is multibyte support for MFC, available on my site, or from microsoft.

https://www.microsoft.com/en-us/download/details.aspx?id=40770

Without it, VS2013 will only do unicode, which is a mess given where Celestia is right now.
If using VS2015, you must select MFC classes during install.
I have no clue whether or how this effects express/community or not.
Since I will not be using a version that requires an M$ account, I will likely never know either.

I have no opinion on the UTF-8 vs Unicode debate, as long as I can declare and use a string, the background is just noise.

If this fork is maintained rather than merged, then I will make something better.
Though a wonderful program, it has foibles I would prefer were different or gone.
I have been considering making my own fork available that has screen edge offsets so I can use Celestia in presentations.
While the program works fine on computer screens, on TVs or projectors, it loses text at the edges.

Well, for better, or for worse, go have fun folks.
If you have suggestions, solutions, ideas, please post them here.
That way they can be asked and answered, and help everyone.

This is in progress, it is not complete.
The QT5.8 version lacks some gui icons, and I have no clue why.
Nor have I used the windeployqt tool.

It will take me a couple of hours, but I will be adding directories with VS2013, QT5.4, QT5.6 & QT5.8, all in 64-bit.
The QT versions will need the VS2013 redists, which are on my site, or can be gotten from M$.

If you download and compile them, please drop a note so we can all see how many people really have an interest now that 64-bit is available on something other than the latest VS version, which not everyone will have or want.


Janus.

[selden]

Are you providing the Celestia binaries there, or just the source code?

I don't seem to see any Celestia binaries, but maybe I'm looking in the wrong places.

I also don't know what the "part" files are for. Including everything in the same zip archive would be much less confusing.

[Janus]

So far, just the sourcecode.

I have not yet gotten the binaries generated for upload.
I am having trouble getting the pdb file absolute paths to not be included in the binaries.
Once I solve that, I will be uploading them.

The par2 files are for data verification and recovery.
They are a standard part of exchanging data with customers with what I do.
The nice things for me is they are content and encryption neutral.
They verify the data, with no regard to what the data is, and they work the same on all platforms.

You use quickpar or multipar to read/use them on windows.
You take an archive(s) of a data set, and generate par2 files.
Then use the base par2 to verify the files.
If there are errors, you then use the Volxxx files for repair rather than downloading the entire thing again.
Quite useful when working on bandwidth limited connections.

If you are exchanging multiGB data sets, it is easier to grab a few repair files, rather the whole thing, especially when the download is an overnight event.
Five minutes beats five hours every time.


Janus.

[selden]

Ok. Being unfamiliar with that software I was reading "par" as "part".

[Janus]

Okay.

To anyone who cares.

I have placed four additional directories in downloads.
They are:

Celestia_VS2013
Celestia_QT54
Celestia_QT56
Celestia_QT58

Each is a stand alone directory of Celestia for windows in 64-bit, with everything legacy that is not needed, removed.

VS2013 contains Celestia-x64 & Libintl.dll files, it has everything else statically linked.
QT54 has Celestia_QT, Libintl.dll & QT Support dlls.
QT56 has Celestia_QT, Libintl.dll & QT Support dlls.
QT58 has Celestia_QT, Libintl.dll & QT Support dlls.

They are all compiled with the archived sourcecode in 170912.
Compilers are VS2013 & QTcreator w/QT5.4*/5.6/5.8 64-bit libraries. *{QT5.4_VS2013_Opengl_64Bit}
VS2013 has multibyte character support libraries added, {vc_mbcsmfc.exe} an additional install.

I hope this helps bring Celestia forward, and I hope people enjoy.


Janus.

[selden]

What do you consider the primary differences among those versions of Celestia so far as a user is concerned?

I don't mean in the sense just that they're using different versions of the support libraries, but is the user experience much different?

Is there any particular reason why one would choose one version over another?

To put it another way, I'm wondering if there's any reason not to decide "We'll use this compiler and this set of libraries until it's time for the next major update."

[Janus]

I do not have a list of differences between the QT versions.
All I am doing is trying to provide choices.
Whether or not it works in VS2015 is not something I have thought about, or considered, nor shall I until and unless I do.

People have things that are important to them.
The wider the range of choices, the more people can be included.
Of course there is the problem of being to inclusive, because then nothing will ever get done.

However, in my case, what I see so far, and my view is limited to what I have seen on the forum.
Many just want to use the latest version of everything.

I am more of a do not change it or update until there is a reason person.
A newer version is not a reason.
A feature that meets a need or saves work, those are reasons.
Higher version numbers are not.

In my own individual case, I have both needs, and limitations.
To my knowledge, I will never run VS2017, ever.
I will also never run the community version of VS, for the simple reason that I do not have, nor shall I ever have, any M$ accounts what so ever.
I may run VS2015, once I am sure enough of securing it, to go get it.
I prefer VS2010 to VS2012, and that to VS2013.
However, I have a compelling reason to use VS2013 over the others, stable 64-bit, so I am.
Yet I regret and hate the loss of navigability and intuitiveness in each generation.
Each one is harder for me to use.

I know I will never run Win8 or later, the UI is complete trash to me, an unusable disaster area.
Others get along with it, and they are most welcome to it.
In my eyes though, they are not windows, just appliance front ends designed to isolate you from the hardware that you own.
I think and work at the hardware level, and anything that gets between me and it, I dislike.

I am happy to contribute the 64-bit code I have worked on.
I hope others find a use for it.


Janus.

[selden]

I understand. M$'s tactics are far from acceptable.

I suppose an alternative might be to migrate to a non-M$ compiler like MinGW.

Someone managed to build Celestia under Cygwin, but I don't think that's really a viable alternative.

[Janus]

Okay, progress.

I have managed to get Libintl to statically link in, goodbye libintl.dll, you will not be missed.
I am replacing libjpg with libjpeg turbo, which compiles and links much cleaner, and so far at least, works.
Jpeg textures are working again, but I have testing to finish before I declare victory.

If this all proves out with regression testing, I will update the binaries and put up a new archive of the sourcecode over the weekend.
Eventually I will have to make a real webpage to keep track of all this, unless someone has heard from Alexell.

I also managed to get Celestia to compile, though not link, using QT Creator, QT5.8 & Mingw 5.30 that comes with QT Creator.
Does anyone know how to make lib files using Mingw from the command line, or using codeblocks?
I tried eclipse since there are LOT! of guides out there for using it, but no thank you, does not get along with me, or my system.
Before anyone starts yelling, I have java walled off in my system, not allowed to do anything until I unblock it.
Same basic reason I will not be using VScode, I detest node, and I keep my stuff to locked down for it to work.
Hence the command line or Codeblocks question.

Also, does anyone know if Mingw has any dll requirements like cygwin does?
I am trying to keep everything statically linked to reduce file clutter.


Janus.

[selden]

I'm not sure what you're asking about when you write "how to make lib files". The MinGW development environment uses the same conventions as linux and Unix for static and shared libraries (i.e. .a and .so filetypes respectively). An example contrasting the building of static and shared (aka dynamic) libraries is at https://www.codeproject.com/Articles/84461/MinGW-Static-and-Dynamic-Libraries

If all of a library's source code is in a single file, a single compilation (i.e. a single invocation of gcc) will produce a static binary library file which has a .o filetype. If you want to combine multiple .o files into a single .a file, you'd use the utility ar (short for archiver: .a stands for archive). An example is at https://stackoverflow.com/questions/10774937/statically-linking-libraries-in-mingw

FWIW, so far as I'm concerned, Java is just another programming language. The problems introduced by its use within browsers in most cases are irrelevant to its use when developing programs which only run locally on a computer.

The use of integrated code development environments like Eclipse, NetBeans or Visual Studio is completely up to the software developer(s). I've never bothered using any of them for my personal projects. Those projects tend to be relatively small, though. IDEs are just another layer of confusion for me, hiding what's actually going on. I don't even write Makefiles: I prefer to use bash scripts.

Added after 13 minutes 56 seconds:
So far as runtime DLLs are concerned, you do somehow have to have access to libraries which provide access to the Windows operating system's I/O support including its support for graphics. Cygwin's DLLs do that as well as providing support for translating linux (Unix) I/O conventions to Windows.

The MinGW FAQ discusses some of this. See https://www.cs.colorado.edu/~main/cs1300/doc/mingwfaq.html

In many cases, those I/O libraries aren't part of MinGW. For example, a description of how to access Qt's graphics I/O libraries under MinGW is at https://wiki.qt.io/MinGW-64-bit

[Janus]

@selden

Thank you for the codeproject link.
It actually shows the steps and what to expect, which is what I have been looking for.
I need to see the steps in motion in order to actually learn and retain it.
Baby steps do not insult me, and page after page of dry specs do me no good.

'Hello world' has been my number one learning tool and guide my entire life.
Yet there is a dearth of guides that say 'When you do this/these steps, expect this/these result(s).', that are not pictures of wizards in a gui.

Compare and contrast with examples that move or flow, that is how I learn and retain.
Or I could say that flow analysis is my education.
A diagram of a clock's parts does me almost no good, but watching one in operation tells me about its shapes, then I can fill in the consts and ratios from the documentation so I can build one in my mind to use as a reference.
Hard to get by in a world based on memorization when you don't.

One of the things I want to lean eventually, is makefiles.
I had hoped that cmake would be better, but it is just as confusing as make files, so that waits.
Perhaps someone will write a makefiles for dummies, or if I manage to learn first, perhaps I will.

I understand what dlls are, but I like to avoid them.
If mingw needs a support dll like cygwin does, then I want to statically link its functions in, instead of using the dll.

For the libintl/gettext, libjpeg turbo, libpng/zlib & lua libaraies I compiled, VS had a setting to produce static libs instead of dlls.
What I am looking for is the mingw version of that, which I am hoping the codeproject link will lead me to.


Janus.