At first, I’m going to introduce myself. I’m a non developer musician that likes a lot the IT world. I used Ardour since the last 6 years. I’m also involved in other project, a OS, called ReactOS, that want to run Windows software and hardware.
Comming to the point, I tested Ardour under this “alternative OS” but it hangs just at the startup first window appear. And also do the successive versions of the software (tested from 5.12 to 6.9) at the same exact point.
I tried to experiment with it and I found that the probably cause of this issue is the libgdk-win32-2.0.0.dll. If I substitute this file with the one with the same name available in the GNOME GTK bundle from the repo (and also intl.dll), the program is able to start.
I have two things for ask for:
I only want to have the source of this file (libgdk-win32-2.0.0.dll from Ardour, that I guess is touched or fitted to be lighter or good for Ardour) and if you consider a little instructions of a little croscompile under linux to Windows target. I know the quoted versions are not the last of Ardour, and maybe you really don’t care the ROS project, but I’m very interested on find the aim of the bug.
libgdk comes with gtk+, however building gtk/gdk depends on a whole lot of other dependencies, notably glib, pango, cairo, which in turn depend on yet others…
What is the actual issue with the binary from ardour.org, how does it manifest?
The behaviour of the issue is that the Welcome (first start) windows hangs with the cursor charging and never works again. Happens also with the gtk-demo.exe if I try to run it in the same Bin folder that have Ardour.
When I change the both libs intl.dll and the libgdk-win32-2.0.0.dll from the original GTK+ bundle in the bin folder, Ardour runs normally (then I encounter other asserts, that can be workarounded with a partial mix of libraries).
I want to have the source to focus in what of the windows libraries are wrong in ReactOS. I suspect it can be one of the Win32ss, may be gdi32, user32, win32k, but for finding the guilty module I have to learn how to compile Ardour code to get only the quoted files or, if not possible, the whole bin folder to indicate prints for the ReactOS debugger to point the wrong function or class.
Like Robin said, you can’t build libgdk without first needing to build a whole bunch of other libraries. And another drawback is that Ardour uses version 2 of libgdk which is quite old now.
Have you tried the Hexchat app to see if that exhibits the same problem? There’s an old version of it here, whose libraries are about the same age as Ardour’s-
Hexchat app works under ReactOS (I have to workaround a bit the installer because the isskin.dll wine bug installing the MFC and vb6 that Rapps have) , but the IDE works without it - even in the 2.9.5 after XP, activating the ROS compatibility mode as Windows 7).
Ardour doesn’t.
I don’t mind if I have to compile the whole GTK+, cairo or the whole Ardour, to get the full bin folder that allows me to debug it.
About the 64 bits question: ReactOS strong support is still 32 bits, the 64 bits is a very, really inmature alpha that can’t do what a OS should be able to do. And I focus on this because I think it’s more interesting.
No: ReactOS is pure NT.
However it share some libraries that are based on Wine’s, which are called the winesynced, later the time are the fewer. Moreover, the first that reported the quoted bug was Wine, and I get the solution from them.
Maybe try swapping out the gdk-win library from Ardour and substitute the one from HexChat. If that still crashes, you could then try building the HexChat support stack from that link I gave you. Which compiler are you using?
The Ardour files in Hex cause to Hex to fail in the exactly same point as Ardour or gtk-demo did.
The Hex 2 quoted before (intl and libgdk) files in Ardour shows a error message: gdk_windows_get_cursor in libgdk-win32-2.0-0.dll, and if I substitute all the bins, the error is in g_bytes_compare in libglib-2.0-0.dll.
I think that Ardour and Hexchat don’t share all the whole libraries at all…
Neither Ardour have the intl.dll file.
I created a little video to describe the issue (100% CPU use, windows/cursos hangs), and the workaround: Ardour issue ReactOS - YouTube
I’m using GCC, but I can use whatever you propose me (if my computer lends me).
Your initial suggestion was probably the best then - i.e. see if the devs here can help you cross-compile from Linux. But that might be a long job - and of course, there’s no guarantee that your build would exhibit the same problem
IIRC Ardour can be launched from a Windows Command Prompt - so maybe try launching it like that and see if it shows any Debug text when the program crashes.
Because it is critical to understand this for this topic (For people that are not the OP)…
ReactOS is a clean room implementation of the NT stack. It is a completely open source OS, but is not based on any *nix, it is a reverse engineer effort to implement the MS libraries to allow windows programs to run natively on it. So it is it’s own operating system really.
Hopefully that clears that part up slightly.
Sadly this also means that noone compiles for it at this time that I am aware of. I believe the windows builds are cross compiled on Linux for distribution, but maybe Robin or Paul can pop in and explaint hat one better (I don’t mess with compilation on Windows right now).
I’m not a gcc developer so I can’t help much but what are you hoping to achieve? It sounds like you’re hoping that if you compile from source, you’ll be able to reproduce the crash and then debug it. But there’s a good chance that your build won’t reproduce the crash so it might end up a lot of wasted effort…
