Console window is visible on Windows

[Vort]

It is common that GUI programs have no console visible in Windows. It was so in 0.0.19, but in latest build of 0.0.20 console is appearing.

Tested with build (4205dd3) on Windows 7 SP1 x64.

[thomaslepoix]

Hi!

I just faced this problem on a different project. It is due to a missing WinMain() entry in the program, which is the difference between a "console application" and a "graphic application". With CMake we fix it by adding the WIN32 flag to add_executable() commands. I don't know the correct way to do with Autotools.

Did you build using CMake or Autotools? Or maybe a prebuild release (Autotools I guess?)

Note : The problem does not seem to occur with Wine.

[Vort]

which is the difference between a "console application" and a "graphic application"

The difference is in subsystem flag inside PE (portable executable) file. You can even change it manually with hex editor inside exe and console window will disappear. Don't know why cmake documentation focuses on entry point differences.

And that's why another solution is specifying subsystem manually: set(CMAKE_EXE_LINKER_FLAGS_RELEASE "${CMAKE_EXE_LINKER_FLAGS} /SUBSYSTEM:WINDOWS /ENTRY:mainCRTStartup")

Did you build using CMake or Autotools?

I did not built it at all. Just downloaded binary somewhere.

[thomaslepoix]

Interesting.

Microsoft /ENTRY and /SUBSYSTEM docs say that /SUBSYSTEM:WINDOWS comes by default when WinMain is set as entry point.

The MinGW equivalent flag seems to be -mwindows.

CMake build seems good to me, except maybe qucs-filter-v2 tool if launched standalone. Could someone confirm?

By reading Qucs build instructions and appveyor file I assume your binary was built using Autotools but this has to be confirmed too.

I don't believe that Autotools provide a compiler independent flag for that, like CMake do, but I don't know Autotools.

As non Windows user, I cannot help much more..

[Vort]

I don't believe that Autotools provide a compiler independent flag for that

But it for sure contains conditional directives.

By reading Qucs build instructions and appveyor file I assume your binary was built using Autotools but this has to be confirmed too.

I have found which link I was using. Here it is: x64.

---

However, now that binary is based on different commit, 10ba944c8, which is completely broken. And no one cares.

[thomaslepoix]

An appveyor artifact, so it is Autotools based.

But it for sure contains conditional directives.

Of course!

However, now that binary is based on different commit, 10ba944, which is completely broken.

As our problem comes from build systems, this does not affect its resolution, as long as it is possible to build Qucs.

May I ask you to build head version using Autotools and CMake to check if the problem persist and try a fix if it does for the Autotools one?

[Vort]

May I ask you to build head version using Autotools and CMake to check if the problem persist

Build instructions are outdated. Both cmake and autotools. Also project uses outdated Qt version (which support is dropped in MSYS2, but luckily it is still possible to install it manually: mingw-w64-x86_64-qt4-4.8.7-4-any.pkg.tar.xz). That is, of course not the only problem. Next one: It is fixed trivially, by replacing LoadLibrary with LoadLibraryW (do anyone want to make PR to fix this problem?). Next problem is resurrected (who knows how) #295. I was forced to install dos2unix and apply fix manually. Also I was not able to make -G "MinGW Makefiles" work, so replaced it with -G "MSYS Makefiles". Autotools portion is having problems too: autogen.sh is missing. ./bootstrap should be used instead. Not mentioning lots of missing dependencies, which was required for build, but was not listed in documentation.

But anyway, 955ccd1b1 is built (at least, partially) and assumption is confirmed: autotools version is having console problem, cmake version is not having it: What change do you think I should make to autotools build system to check if it will remove console window?

[thomaslepoix]

Such an adventure.. well done!

I think it should check which compiler is used :

• MSVC : add /ENTRY:WinMain flag, or maybe /SUBSYSTEM:WINDOWS
• MinGW (whether the unix compatibility layer is MSYS, cygwin, or something else) : add -mwindows flag
• gcc or clang : we are on unix platform, nothing to add

I don't really know if they are compiler or linker flags. I think Qucs GUI and the different tools (transcalc, active-filter, etc.) need the fix.

May you starting point be near this kind of lines?

Note : Actually I am not sure that MSVC is supported, if you cannot build with it, no need to treat its case.

[Vort]

I think it should check which compiler is used :

And this part is broken too!

I don't really know if they are compiler or linker flags.

Linker.

---

Here is what I have done:

diff --git a/qucs/configure.ac b/qucs/configure.ac
index 3d32c8a60..148ab5bd4 100644
--- a/qucs/configure.ac
+++ b/qucs/configure.ac
@@ -217,10 +217,10 @@ fi # if pkg-config exists
     *linux* | *cygwin* | *mingw* | *msys* | *bsd* )

       dnl Set Clang
-      if test "$CXX -dM -E - < /dev/null | grep __clang__" ; then
+      if `$CXX -dM -E - < /dev/null | grep __clang__` ; then
         CFLAGS="$CFLAGS -pipe"
         CXXFLAGS="$CXXFLAGS -pipe -fno-exceptions -Wno-deprecated-register"
-        LDDFLAGS="$LDDFLAGS"
+        LDFLAGS="$LDFLAGS"
         use_CLANG="yes"
       fi

@@ -230,6 +230,7 @@ fi # if pkg-config exists
         CXXFLAGS="$CXXFLAGS -pipe -fno-exceptions -fno-check-new"
         if test x$WIN32 = xyes; then
           CXXFLAGS="$CXXFLAGS"
+          LDFLAGS="$LDFLAGS -mwindows"
         fi
       fi

And it works (no console window). Except that I did not tested it with clang.

[thomaslepoix]

Really nice!

Clang build is successful for me, but your fix is partial, use this line instead and it will be ok.

      if test "`$CXX -dM -E - < /dev/null | grep __clang__`" ; then

[Vort]

https://ci.appveyor.com/api/buildjobs/4hquup1h4149wmwp/artifacts/qucs-win64.zip looks good. Thanks!

[Vort]

By the way, Clang build do not produces schematic UI corruption:

[in3otd]

Thanks! I think we had the -mwindows flag in the past but likely it got accidentally removed when reworking configure.ac..

Great that the clang build does not have graphic issues: we knew that the AppVeyor build is badly broken (#958) but nobody did find a solution for that yet and to get a working Windows executable currently we had to use Wine (#962).

Maybe you could update the AppVeyor build to use clang (in another PR) ? :grin:

[Andronx]

Hi, can someone share working Qucs 0.0.20 rc2 build for Windows? @Vort could you share that mentioned file? "https://ci.appveyor.com/api/buildjobs/4hquup1h4149wmwp/artifacts/qucs-win64.zip"

[ra3xdh]

@Andronx you may try Qucs-S instead https://github.com/ra3xdh/qucs_s/releases/tag/0.0.24 Qucs-S uses Ngspice as the default simulation kernel, but the usage of qucsator is also possible if necessary.

[Andronx]

@ra3xdh Yes, I know Qucs-S, but Optimization with preffered numbers E24.. so on, functionality is very usefull for me and I didn't found that in Qucs-S or Qucs Studio. That's the reason that I'm looking for Qucs 0.0.20 rc2.