MuseScore 3 on Windows 32-bit is not available

• Jan 10, 2019 - 13:26
Reported version
P1 - High
S1 - Blocker

See detailed explanation of problem on forum discussion No Windows 32-bit nightlies?


A 32bit build with Qt 5.9 and MinGW would not have the performance issue the MSVC one has, but would also (just like the MSVC 32bit build with Qt 5.9) be lacking features, like WebEngine, used for the online part of the start center.
There is a 32bit build available in the forum, which also runs on Windows XP, using an even older Qt version (7.5), restricted even further, like disabled plugins (which is not really much of an issue currently, with 3.0 plugins being broken currently anyway).

In reply to by Jojo-Schmitz

As I never ever used the missing features you just listed, that 32 bit version would be ok with me. The question is: where in the forum can I find it? Could you please provide a direct link to the exact page or, even better, to the actual file I have to download for installation on old 32bit XP based platforms?

In reply to by Jojo-Schmitz

I dropped a thank-you-so-much message to ABL and I tried the 32bit version on a very slow Windows 7 Starter machine. I had some problem at the very start, now it looks all ok, in spite of the missing features. Tomorrow I'll try this version of MuseScore on a much faster XP machine.

@Aldo's issues:
My comment to one of them (missing ibgcc_s_dw2-1.dll):, seems BUILD_64 had not been set to off? If so I wonder why it worked at all for Aldo after having found that dll on the internet and copied it? Maybe the other problems (certain operations crashed MuseScore) are related to that, like the build would also not have used the -Wl,--large-address-aware compiler/linker options?

In reply to by Jojo-Schmitz

Well, I'm not sure I can point you to the exact launch step that made the program crash, so I give you two screenshots that do that for me. They are related to an italian version of Windows 7 Starter, Service Pack 1, and the language MuseScore is using is italian as well, but I'm sure you can get the point.

I didn't try MuseScore 3 on my XP machine yet. Sorry.

Attachment Size
missing_dll.png 16.93 KB
crash #2.png 63.58 KB

I'm not sure if we should continue here the discussion or in another thread.
I'm posting here since I think that in a general MSVC build of MuseScore this problem could appear.
I found that "libgcc_s_dw2-1.dll" is needed by the bundled libeay32.dll and ssleay32.dll, which both come from the previous version MinGW compilation.
The 64bit version does not depend on MinGW libraries, that's why up to now there were no problems, I think.
The crash happens with the Start Center; maybe it is calling a function inside one of those dlls for the web connection.
You could try to download the zip file from here:
(they are suggested also in the official OpenSSL wiki )
and overwrite libeay32.dll and ssleay32.dll in MuseScore bin folder with those from that archive. libgcc_s_dw2-1.dll should no more be needed and hopefully the Start Center (Finestra di avvio) will work.

[ and I'm Italian, too ;-) so no problem in understanding those messages ]

Might have been my mistake, back when we detected that MuseScore could not save online due to lacking these libs (which by that time I took from Qt IIRC), (hopefully) meanwhile fixed by an updated, can you please check?

In reply to by ABL

@ABL - Yes, and No.
Yes --
with the new copies of libeay32.dll and ssleay32.dll, libgcc_s_dw2-1.dll is not needed anymore (good news).

No --
the Start Center (Finestra di avvio) doesn't work and still makes MS crash at launch.

P.S. I never used the Start Center before (I'm used to disabling it from the preferences window). Maybe someone else could find it useful, though - who knows?

In reply to by ABL

I tested your version of MuseScore on an XP service 3 platform (with the two dll's you suggested as a replacement for the old ones). My test regarded most of the features I have been using on a regular basis since version 2.3.2 and I used the new program for as long as a couple of hours without incurring a single a hiccup -- all looked ok. And (surprise!) even the start center worked smoothly at each launch in XP.
I dare to say that you made a backward compatible stable version of MuseScore 3.0 available, going back (at least) to 32bit XP and lacking just the minor features you already listed. Wouldn't it be a good idea to make it an official version of the new release, maybe disabling or removing at their very root the offending features?

I don't think a fully supported official MuseScore 3 for a full a unsupported operating system like Windows XP ans Vista is really needed, but having an unsupported one available for download would be ok, just like the non-SSE and 64bit versions of MuseScore 2.x. And as soon as plugins are made working in 3.0 again it is not just loosing a minor feature. Also not having WebEngine and so no view of online scores on in the startcenter, while maybe a minor feature for you, is a major issue for the MuseScore company, which generates revenue thru that ;-)

In reply to by Jojo-Schmitz

I can see your point.

An unofficial (but working) version is 100% ok, of course. My personal idea of "supported" is "working with no major problems". I don't need anything more than that, really, and I feel like saying a loud "thanks!" again to ABL (and to all the developers team), as I can enjoy MuseScore for free since a long, long time ago.

W.r.t. calling the 32-bit version "unsupported", I would canvas for removing it. We will do our best to support it as long as possible. If our upstream stack throws us a hurdle we cannot surmount, then we stop supporting it and explain the reason for doing so. E.g. Qt 5.12 will continue to support 32-bit for the full life cycle of 3 years. There are other upstream that could bail on us. An "unsupported" label probably gives us more freedom to pull the plug when that happens, however it undermines this variant and the effort that went into it by putting the "sword of uncertainty" over it.

Supported vs. unsupported is more a matter of where it comes from, how it got build.
The 64bit version is build on AppVeyor in a completly open process, the 32bit version got created manually, although in this case by a staff member, so we could declare it supported. In the past the 2.x 64bit version, the noSSE version and the PortableApp came from the community (and all Linux distribution ones too) and that was the reason for tagging them being unsupported, and for valid reasons.