MinGW builds vs VC++ builds: anybody to summarize the key differences?

[Maksym Kozub]

Sorry if this sounds like a strange and/or stupid question, but still. I have used Avidemux for simple editing (splitting, joining, etc.) in various situations. I remember installing and using different versions in the last five years or so. Sometimes I installed MinGW builds, while for some versions I installed VC++ builds. I do not remember the reasons, but I think that in some versions some features were only present in one of the two builds.
Now I am going to install Avidemux again on my new laptop, using the binary installer for Windows, and I would appreciate any brief summary of the differences (feature-wise, stability-wise, etc.) in the latest stable version (i.e., 2.8.0) between the MinGW (i.e. gcc) build and the VC++ one.

[eumagga0x2a]

MinGW builds provide no VapourSynth (required Python is not available in MXE) and no NativeAvisynth demuxers, VC++ builds don't have fluxSmooth and telecide video filters.

Versions of various libraries differ between the both build environments.

That's it, I think. Of course, the installers are different (qtif for VC++, NSIS for MinGW), but this is secondary.

[Maksym Kozub]

MinGW builds provide no VapourSynth (required Python is not available in MXE) and no NativeAvisynth demuxers, VC++ builds don't have fluxSmooth and telecide video filters.

Many thanks for your answer. Yes, I understand that libraries are different and installers are different, but the key part is what I have quoted here. In that case, may I ask another question (the last one in this context : are there any fundamental reasons behind this difference in features, other than no Python in one of the two environments? I.e., should we expect to see in some months a VC++ build with fluxSmooth etc., or will it remain as it is (some features existing in MinGW builds only) for the foreseeable future? I mean, not because there is nobody who is able or wants to do some development, but for some more fundamental reasons.
My apology again if I am asking stupid things. The last time I did some serious software development was something like 35 years ago (Fortran, System/360 assembly language, etc., you can imagine . So, while I understand a thing or two about modern development environments (all in all, I do quite a lot in software-related fields as a translator and interpreter), I can say very honestly that I do not know much about all those specifics and limitations.

[eumagga0x2a]

Absolutely no stupid questions asked :-)

VC++ builds can be debugged (when compiled as debug builds), MinGW builds not. This is the main reason why VC++ builds exist. I personally can create only MinGW builds. I work only on Linux and on macOS, but some testing is done on Windows.

= no development targeting VC++ from me so far.

[Maksym Kozub]

VC++ builds can be debugged (when compiled as debug builds), MinGW builds not. This is the main reason why VC++ builds exist. I personally can create only MinGW builds. I work only on Linux and on macOS, but some testing is done on Windows.

Thank you so much, now I finally understand the logic behind having those two builds for the same version of Avidemux.
I wish you every success in further development of this great software.
By the way, there is something funny, and maybe it is of possible interest to some developers. I have installed both builds of Avidemux 2.8.0 on the same laptop under Windows 10 Professional, and they behave as follows. (I think I also observed the same behaviour for some earlier version a couple of years ago.)
If I start the MinGW build first, then the VC++ build cannot start.
If I start the VC++ build first, then the MinGW build starts fine. After that, I can start more instances of the VC++ build without stopping the MinGW build.
I.e., it is not that the MinGW build generally cannot run concurrently with the VC++ build, but maybe if the MinGW build _starts first_, it "monopolizes" some hook or something.

[eumagga0x2a]

If you try to run both concurrently, then please really don't. Both fight over the same log file and what happens then is unknown. Also, both access the same Avidemux profile, overwriting each other's configuration.

If you close MinGW build and this nevertheless prevents VC++ build from running later during the Windows session, this sounds indeed strange.

[Maksym Kozub]

If you try to run both concurrently, then please really don't. Both fight over the same log file and what happens then is unknown. Also, both access the same Avidemux profile, overwriting each other's configuration.

Thank you for the reminder . Please do not worry, I am careful, and I do not actually use them for editing concurrently. This was just a short test whether they would start etc.

If you close MinGW build and this nevertheless prevents VC++ build from running later during the Windows session, this sounds indeed strange.

Oh, no, I did not say that. After I close the MinGW build, the VC++ build starts fine; sorry for not mentioning it in my previous message. It is just while the MinGW build (started first) is running, that it prevents the VC++ build from starting (but not the other way round, as I already mentioned, and this "asymmetry" is sort of funny).

[eumagga0x2a]

After I close the MinGW build, the VC++ build starts fine; sorry for not mentioning it in my previous message. It is just while the MinGW build (started first) is running, that it prevents the VC++ build from starting (but not the other way round, as I already mentioned, and this "asymmetry" is sort of funny).

If _wfreopen() of the log file in the redirectStdoutToFile() funtion fails, VC++ builds crash (assertion failure) while the failure of fopen() to open the log file for writing in the implementation used by MinGW builds gets ignored.