(solved) windows msys ucrt64 build, no window appears

Software
,
1

Hi there,

A quick question to check if this is a known issue and/or has a known workaround. Forgive me if there is a topic about it somewhere already (a quick glance showed nothing but I didn’t search hard…).

I just upgraded my desktop Windows10 machine. I often build Darktable and Rawtherapee myself, so I have a msys folder on both my laptops and my desktop machine.

I recently (finally) moved away from mingw64 to ucrt64. So in MSYS2, I queried all packages that are from mingw64 and removed them. Then I started form the Darktable build instructions to fetch all packages.

For rawtherapee I sort of did the same, but I exchanged the mingw64 packages with ucrt64 ones.

On my Windows11 main laptop, both Darktable and Rawtherapee build and work fine this way.

Now I did the same on my (much older MSYS2 install) desktop. Darktable and Rawtherapee build fine, but in both cases, no main window appears when starting!

It doesn’t crash, it doesn’t exist. I DO get the first-time-startup dialog window with release notes in Rawtherapee (and database upgrades for Darktable, I didn’t clear setting sthere). But after that, the process just sits there. In the Windows taskbar, I see the Rawtherapee main window in the thumbnail of the process, but nothing appears (and I can’t move / minimize / restore it).

Is this a known issue for some? I already cleared out all the settings from appdata / localappdata to start fresh.

I start it (like always) from the build/release directory (so git_root/build/release/rawtherapee.exe).

Darktable I normally run the installer that is build, but in this case I try to start from git_Root/build/bin/darktable.exe.

2

I completely uninstalled and reinstalled from scratch MSYS2.
Darktable seems to run now.

But Rawtherapee still has a hidden main-window :(.

3

Side-question: what compelled you to switch from mingw64 to ucrt64? Been staring at my win66 rawproc build with that in mind, not a fan of such fundamental change unless there’s significant benefit or detriment avoidance…

4

Suggested by the dev team …

5

They just do it, don’t say why…

6

Not sure what prompted the shift… I do recall some discussion just not what the context was and an as a non coder I have no idea…

7

IIRC when building with UCRT the executable should (is guaranteed?) run on any version of windows (7+)…

1 Like
8

I kept mingw64 because it worked. But officially Darktable switched over to ucrt64, so thought I had to switch over sometime.

Also, i believe / hope it will give better interop with other compilers down the road. And it’s the runtime of choice for win10/win11 which i see as the active windows versions.

And i had issues where the mingw builds would not show terminal output except when in the msys terminal, which was getting annoying .

I did not investigate it that deep, but quick searching for Microsoft related docs gives me this : Upgrade your code to the Universal CRT | Microsoft Learn

So what i gather from this , is that Microsoft moved a lot our of the visual studio runtime library , and made a more ‘universal’ c-runtime that covers all the regular stdio / posix-emulation layer and all.

This is the stuff tools like cygwin and mingw did themselves . Now there is a library that is used by vstudio 2015/2017/never/msys/more?

So DLLs and libraries are now hopefully more interchangable between those compilers .
They weren’t really before.

If I made something with visual studio, i could link and use a dll made with mingw64 , bur i had to make sure no pointers and stuff crosses c-runtime boundaries.

For instance , if mingw64-glib opened a file for me and returned the file pointer , i couldn’t close that file pointer myself from visual studio. The pointer was created by mingw64 runtime and is incompatible with visual studio runtime.

I THINK that’s now no longer the case , if everything is linked against the UCRT.

Again, more interop between libraries built with different compilers.

I hope this a) makes sense b) is actually correct. I’m not sure.

1 Like
9

I think I fixed it. Bit embarrassing, but here it goes.

I switches GPUs. So my monitor configuration got reset.

I have monitor #1 to the left of me , and my main monitor in front of me. The main monitor is marked as ‘main’, but it has become #2 now.

The monitor on my left was turned off…

Fill in the blanks :).

(Rawtherapee opened at position 0,0 which was on the left non-main monitor which was turned off.)

I don’t know why i couldn’t move it , or RT (gdk) decided to use my non-main monitor, but that is all stuff i sort of had before with gtk-on-windows.

Anyway, sorted. Turn on monitor , drag window over , then monitor off again :).

2 Likes
10

FYI, MSys2 themselves dropped support for Windows 7 and made UCRT default around the end of last year:

dt is just keeping up.

2 Likes