Oolite Bulletins

hiran wrote: ↑Sat Feb 21, 2026 8:46 pm

But it could answer the next question I was going to shoot: Where would I find the developer version's debug.oxp?

hiran wrote: ↑Sat Feb 21, 2026 8:46 pm

mcarans wrote: ↑Sat Feb 21, 2026 8:38 pm

The extract worked for me. Make sure you issue 2 commands - extract then cat:

Ok, that explains. This way I get the full appimage extracted - it takes more than 200 MB disk space just to find the version number. I hope we can improve on that.

1 > unsquashfs -o $(./Oolite_1.93.0.7774-260215-82f9ce6-x86_64.appimage --appimage-offset) -cat ./Oolite_1.93.0.7774-260215-82f9ce6-x86_64.appimage /usr/bin/Resources/manifest.plist
{
        title = "Oolite core";
        identifier = "org.oolite.oolite";

        version = "1.93";
        required_oolite_version = "1.93";

        license = "GPL 2+ / CC-BY-NC-SA 3.0 - see LICENSE.md for details";
        author = "Giles Williams, Jens Ayton and contributors";
        information_url = "https://oolite.space/";
}

another_commander wrote: ↑Sat Feb 21, 2026 8:51 pm

hiran wrote: ↑Sat Feb 21, 2026 8:46 pm

But it could answer the next question I was going to shoot: Where would I find the developer version's debug.oxp?

It is at https://github.com/OoliteProject/oolite ... /Debug.oxp

hiran wrote: ↑Sat Feb 21, 2026 9:51 pm

How can i differentiate a debug build of appimage(Oolite) from non-debug build of appimage(Oolite)?

another_commander wrote: ↑Sun Feb 22, 2026 12:18 pm

hiran wrote: ↑Sat Feb 21, 2026 9:51 pm

How can i differentiate a debug build of appimage(Oolite) from non-debug build of appimage(Oolite)?

One way to do it could be to check the hash of the main executable and compare it to the corresponding known hashes.

For example, get the SHA1 of the known debug executable and compare it to the calculated SHA1 of the executable you are investigating.

hiran wrote: ↑Sun Feb 22, 2026 12:34 pm

What is the problem with a simple command line option "-version" that prints the exact version string and exits?
I would have added that command line flag long ago if only I knew where Oolite internally stores/fetches it's version number.

mcarans wrote: ↑Sun Feb 22, 2026 7:31 pm

In the post build, we could generate a version file. Already in the generated build folder, there is a file version.mk that looks like this:

Code: Select all

VERSION=1.92.1
VER_MAJ=1
VER_MIN=92
VER_REV=1
VER_DATE=260222
VER_GITREV=7792
VER_GITHASH=db22c95
VER=1.92.1.7792-260222-db22c95
BUILDTIME=2026.02.22 18:14

It is created by ShellScripts/common/get_version.sh which could be augmented to capture the type of build.

We could capture whether it's release-deployment (DEPLOYMENT_RELEASE_CONFIGURATION=yes), release or release-snapshot (SNAPSHOT_BUILD=yes) and output an extra line like:

Code: Select all

BUILD_TYPE=release-deployment

Would that work?

hiran wrote: ↑Sun Feb 22, 2026 8:01 pm

mcarans wrote: ↑Sun Feb 22, 2026 7:31 pm

In the post build, we could generate a version file. Already in the generated build folder, there is a file version.mk that looks like this:

Code: Select all

VERSION=1.92.1
VER_MAJ=1
VER_MIN=92
VER_REV=1
VER_DATE=260222
VER_GITREV=7792
VER_GITHASH=db22c95
VER=1.92.1.7792-260222-db22c95
BUILDTIME=2026.02.22 18:14

It is created by ShellScripts/common/get_version.sh which could be augmented to capture the type of build.

We could capture whether it's release-deployment (DEPLOYMENT_RELEASE_CONFIGURATION=yes), release or release-snapshot (SNAPSHOT_BUILD=yes) and output an extra line like:

Code: Select all

BUILD_TYPE=release-deployment

Would that work?

- You mentioned that the Linux packages (Appimage, Flatpak) would run a shell script. Can that one be made to print the build type and version number (VER)? It would prevent having to extract the packages at runtime.
- For classic builds that get distributed in whatever means it will help to have the full version number in manifest.plist. Maybe the build type can be added to the plist as well.

Both the above points will make OoliteStarter tremendously simpler and more maintainable while not requiring any information to be printed by Oolite itself.

Remains one thing: AFAIK the debug build needs the debug oxp to do whatever. The presence of the debug oxp was my test for a debug build in the past. Now that this OXP is no longer contained, does the debug build still work with the debug console?

another_commander wrote: ↑Sun Feb 22, 2026 4:47 pm

No it doesn't work like that unfortunately. Everything environment related gets set up via SDL's main before our own main function starts.

The -version parameter I have implemented is all done before any official SDL initialization, but still the redirect occurs.

Google Gemini wrote:

It’s a classic "gotcha" for developers using SDL (Simple DirectMedia Layer), especially on Windows. If you’ve ever wondered why your printf statements or std::cout logs suddenly vanished into the void, you’ve felt the sting of SDL’s legacy behavior.

Here is the breakdown of why this happens and how it works.

1. The Historical "Why" (Windows Win32)

The primary reason is historical and platform-specific. On Windows, a standard GUI application (subsystem:windows) does not have a console attached to it by default.

In the early days of SDL, if a developer used printf, the output would simply disappear because there was no terminal to catch it. To be helpful, SDL’s creators decided to redirect stdout and stderr to local files—stdout.txt and stderr.txt—so developers could actually read their logs after the program closed.

2. How SDL Performs the Redirect

When you include SDL.h, it often pulls in a header that redefines your main function to SDL_main. During the initialization process (specifically inside the SDL_main entry point logic), SDL performs a stream redirection.

Mathematically, you can think of it as a file descriptor mapping:

Standard: fd(1)→Console STDOUT

SDL Redirect: fd(1)→stdout.txt

3. The Modern Context

In SDL2 and SDL3, this behavior is much less aggressive than it was in the original SDL 1.2.

SDL 1.2: Almost always forced the creation of .txt files on Windows.

SDL 2.0+: Generally respects the environment. If you run your app from a console or compile it as a console application, it usually leaves your streams alone. However, if it detects it's in a pure "Windows App" mode, it may still trigger the redirection to ensure errors are captured somewhere.

How to Prevent It

If you want to keep your output in the terminal and stop SDL from hijacking your streams, you have a few options:

Use SDL_Log: Instead of printf, use SDL's built-in logging system. It is designed to be cross-platform and handles the routing to the appropriate debug console or terminal automatically.

Define NO_STDIO_REDIRECT: If you are building from source or using specific wrappers, defining this macro before including SDL headers can sometimes disable the behavior.

Link as a Console App: In Visual Studio, change your Linker settings:

System -> Subsystem -> Console (/SUBSYSTEM:CONSOLE)

This forces Windows to provide a terminal, which usually keeps SDL from feeling the need to redirect to a file.

another_commander wrote: ↑Mon Feb 23, 2026 7:14 pm

I have managed to pass the full Oolite version to the generated manifest.plist file in Resources. This is what that manifest file looks like now:

Code: Select all

{
	title = "Oolite core";
	identifier = "org.oolite.oolite";
	
	version = "1.93";
	required_oolite_version = "1.93";
	version_full = "1.93.0.7775-260223-e400ac6";    // <------ this is the newly inserted line
	
	license = "GPL 2+ / CC-BY-NC-SA 3.0 - see LICENSE.md for details";
	author = "Giles Williams, Jens Ayton and contributors";
	information_url = "https://oolite.space/";
}

@hiran, is that acceptable for your purposes? I think it's the best solution we've got so far. The full version string now appears both in the help text and in this manifest so it should be possible to both read it on-screen and extract it for further processing from external utilities.

> ./Oolite_test_1.92.1.7794-260223-0e2a2d2-x86_64.AppImage packageinfo
OOLITE_VERSION=1.92.1.7794-260223-0e2a2d2
BUILDTIME=2026.02.23 20:24
DEPLOYMENT=no

another_commander wrote: ↑Mon Feb 23, 2026 7:14 pm

I have managed to pass the full Oolite version to the generated manifest.plist file in Resources. This is what that manifest file looks like now:

Code: Select all

{
	title = "Oolite core";
	identifier = "org.oolite.oolite";
	
	version = "1.93";
	required_oolite_version = "1.93";
	version_full = "1.93.0.7775-260223-e400ac6";    // <------ this is the newly inserted line
	
	license = "GPL 2+ / CC-BY-NC-SA 3.0 - see LICENSE.md for details";
	author = "Giles Williams, Jens Ayton and contributors";
	information_url = "https://oolite.space/";
}

@hiran, is that acceptable for your purposes? I think it's the best shot we've got so far. The full version string now appears both in the help text and in this manifest so it should be possible to both read it on-screen and extract it for further processing from external utilities.