New release for Windows?

[MSoegtropIMC]

I am using wxMaxima on MacOS and Windows and compared to the Mac version, the Windows version has quite a few issues. How about a new release for Windows? I would prefer the same tag as I am using on Mac, but if you think a later release is better, I could also update the Mac version.

Btw.: can I download somewhere a nightly or weekly build? This should be easy to do with GitHub.

[daute]

Currently the Windows version seem to crash immediately, here a backtrace:

There are many messages that threads are created and exited and afterwards:

[New Thread 10968.0xd8c]
[Thread 10968.0xd8c exited with code 0]
[New Thread 10968.0x2a18]
[Thread 10968.0x2a18 exited with code 0]
[New Thread 10968.0xaf4]
[Thread 10968.0xaf4 exited with code 0]
[New Thread 10968.0x21e4]
[Thread 10968.0x21e4 exited with code 0]
[New Thread 10968.0x27b4]
[Thread 10968.0x27b4 exited with code 0]
[New Thread 10968.0x23a0]

Thread 343 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 10968.0x23a0]
wxStringOperationsWchar::DecodeChar (i=<error reading variable: Cannot access memory at address 0xe7fdaea>)
    at /home/dauti/Software/maxima-code/crosscompile-windows/build/wxwidgets/wxwidgets-prefix/src/wxwidgets/include/wx/stringops.h:81
81      /home/dauti/Software/maxima-code/crosscompile-windows/build/wxwidgets/wxwidgets-prefix/src/wxwidgets/include/wx/stringops.h: No such file or directory.
(gdb) bt
#0  wxStringOperationsWchar::DecodeChar (
    i=<error reading variable: Cannot access memory at address 0xe7fdaea>)
    at /home/dauti/Software/maxima-code/crosscompile-windows/build/wxwidgets/wxwidgets-prefix/src/wxwidgets/include/wx/stringops.h:81
#1  0x0000000000fd9ac8 in wxString::const_iterator::operator* (this=0xd9efb70)
    at /home/dauti/Software/maxima-code/crosscompile-windows/build/wxwidgets/wxwidgets-prefix/src/wxwidgets/include/wx/string.h:1005
#2  0x000000000044643c in Maxima::SendToWxMaxima (this=0x8d047b0)
    at /home/dauti/Software/maxima-code/crosscompile-windows/build/wxmaxima/wxmaxima-git-prefix/src/wxmaxima-git/src/Maxima.cpp:279
#3  0x00000000010487c6 in std::__invoke_impl<void, void (Maxima::*)(), Maxima*> (
    __f=@0xb90b8d0: (void (Maxima::*)(Maxima * const)) 0x445e44 <Maxima::SendToWxMaxima()>,
    __t=@0xb90b8c8: 0x8d047b0) at /usr/lib/gcc/x86_64-w64-mingw32/9.3-posix/include/c++/bits/invoke.h:73
#4  0x0000000001057d27 in std::__invoke<void (Maxima::*)(), Maxima*> (
    __fn=@0xb90b8d0: (void (Maxima::*)(Maxima * const)) 0x445e44 <Maxima::SendToWxMaxima()>)
    at /usr/lib/gcc/x86_64-w64-mingw32/9.3-posix/include/c++/bits/invoke.h:95
#5  0x000000000101d408 in std::thread::_Invoker<std::tuple<void (Maxima::*)(), Maxima*> >::_M_invoke<0ull, 1ull> (this=0xb90b8c8) at /usr/lib/gcc/x86_64-w64-mingw32/9.3-posix/include/c++/thread:244
#6  0x000000000101d457 in std::thread::_Invoker<std::tuple<void (Maxima::*)(), Maxima*> >::operator() (
    this=0xb90b8c8) at /usr/lib/gcc/x86_64-w64-mingw32/9.3-posix/include/c++/thread:251
#7  0x000000000101c5dc in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (Maxima::*)(), Maxima*> > >::_M_run (this=0xb90b8c0) at /usr/lib/gcc/x86_64-w64-mingw32/9.3-posix/include/c++/thread:195
#8  0x000000006fd43a51 in std::execute_native_thread_routine (__p=0xb90b8c0)
    at ../../../../../../src/libstdc++-v3/src/c++11/thread.cc:80
#9  0x000000005c985132 in pthread_create_wrapper (args=0x0)
    at ./mingw-w64-libraries/winpthreads/src/thread.c:1499
#10 0x00007ffcacfae634 in msvcrt!_beginthreadex () from C:\Windows\System32\msvcrt.dll
#11 0x00007ffcacfae70c in msvcrt!_endthreadex () from C:\Windows\System32\msvcrt.dll
#12 0x00007ffcad05257d in KERNEL32!BaseThreadInitThunk () from C:\Windows\System32\kernel32.dll
---Type <return> to continue, or q <return> to quit---
#13 0x00007ffcadfeaa48 in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll
#14 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

I am currently thinking, whats the cause for that, it works okay on Linux.

Concerning the nightly build: There are nightly builds of the current Maxima+wxMaxima development version on my website: https://wolfgang.dautermann.at/maxima/nightlybuild/

And I think you have commit permissions to the wxMaxima project, feel free to help to improve it (e.g. by creating Github workflows which create downloadable packages. Windows (and Mac and Linux) builds are already generated after each commit).

Best regards, Wolfgang

[MSoegtropIMC]

@daute: regarding the per commit builds: I had a look at the CI runs, e.g.:

Windows: https://github.com/wxMaxima-developers/wxmaxima/actions/runs/8908897401

Mac: https://github.com/wxMaxima-developers/wxmaxima/actions/runs/8908897404

The Mac CI run has a downloadable .dmg file. The Windows CI run doesn't have any artifacts. Am I looking in the wrong place?

When I am finished with my current computations (might take another week or two) I can e.g. bisect the Windows issue.

[gunterkoenigsmann]

We never found out where to download the artifact from after the max build. But I have heard that installing an unsigned dmg on Mac Os needs some work. If you have the means of finding it out: Could you add that info to our README.md?

For MS Windows: I once added all the command-line switches to make the build create a statically-linked .exe file. That one could be uploaded as an atrifact, if we wanted. I didn't make the CI upload an arifact on MS Windows, as well, as github had a very long retention period for artifacts, back then, and only little space for artifacts. In the meantime they made the retention time configurable,though, and I have reduced it, even if I don't remember, how...

[MSoegtropIMC]

Anyway, to get forward I wrote a little batch file inspired by the github action to download and compile wxWidgets and wxMaxima. It compiles fine (Using latest Visual Studio Pro 2022) and produces an exe. Just when I run it I get:

D:\Maxima\wxMaximaSource\wxmaxima>build\src\Debug\wxmaxima.exe
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.

When I use sxstrace.exe, I get:

=================
Begin Activation Context Generation.
Input Parameter:
        Flags = 0
        ProcessorArchitecture = AMD64
        CultureFallBacks = en-US;en;de-DE;de
        ManifestPath = D:\Maxima\wxMaximaSource\wxmaxima\build\src\Debug\wxmaxima.exe
        AssemblyDirectory = D:\Maxima\wxMaximaSource\wxmaxima\build\src\Debug\
        Application Config File =
-----------------
INFO: Parsing Manifest File D:\Maxima\wxMaximaSource\wxmaxima\build\src\Debug\wxmaxima.exe.
        INFO: Manifest Definition Identity is (null).
        INFO: Reference: Microsoft.Windows.Common-Controls,language="*",processorArchitecture="*",publicKeyToken="6595b64144ccf1df",type="win32",version="6.0.0.0"
ERROR: Activation Context generation failed.
End Activation Context Generation.

I usually use Visual Studio IDE projects to build stuff on Windows (which I do rarely anyway) and have never seen this. I guess when one builds with cmake, one needs to manually add some sort of manifest.

My build script is:

@ECHO OFF
SET WXVERSION=3.2.4

IF NOT "%VSCMD_ARG_HOST_ARCH%"=="x64" (
    ECHO Please start this script from a Visual Studio x84 command prompt!
    EXIT 1
)

IF EXIST "wxwidgets-source" (
    ECHO wxWidgets already present
) ELSE (
    ECHO ========== Downloading wxWidgets ==========
    POWERSHELL -Command "(New-Object Net.WebClient).DownloadFile('https://github.com/wxWidgets/wxWidgets/releases/download/v%WXVERSION%/wxWidgets-%WXVERSION%.zip', 'wxWidgets-%WXVERSION%.zip')
    ECHO ========== Unpacking wxWidgets sources ==========
    POWERSHELL -command "Expand-Archive wxWidgets-%WXVERSION%.zip wxwidgets-source
)
IF EXIST "wxwidgets-source\build-ok" (
    ECHO wxWidgets already built
) ELSE (
    ECHO ========== Configuring wxWidgets ==========
    CD "wxwidgets-source"
    cmake "." -DwxUSE_WEBVIEW_EDGE=true
    ECHO ========== Configuring wxWidgets ==========

    ECHO ========== Building wxWidgets from sources: SUCCESS ==========
    cmake --build .
    echo "OK" > "build-ok"
    ECHO ========== Building wxWidgets from sources: SUCCESS ==========
    CD ..
)

ECHO ========== Configuring wxMaxima ==========
MKDIR build
CD build
cmake -DwxWidgets_ROOT_DIR="../wxwidgets-source" -DwxWidgets_LIB_DIR="../wxwidgets-source/lib/vc_x64_dll" -DwxWidgets_CONFIGURATION="mswud" -DCMAKE_BUILD_TYPE=${{ env.config}} ..
CD ..
ECHO ========== Configuring wxMaxima: SUCCESS ==========

ECHO ========== Building wxMaxima from sources ==========
cd build
cmake --build .
cd ..
ECHO ========== Building wxMaxima from sources: SUCCESS ==========

[gunterkoenigsmann]

src/wxmaxima.rc.in tells the Ressources file to include the result of substituting a few strings in wxmaxima.manifest.in as side-by-side configuration. Including a side-by-side-configuration is necessary in order to tell

• that our application is not a Windows XP one and therefore can be layouted with whatever styles your win10 or win11 wants to apply to it.
• that our application supports HighDPI screens and does not need to be rendered in lo-res and then to be upscaled.

...and all these files have been created in a trial-and-error-blind-coding process as I don't have a Windows PC and sometimes have no idea what a setting is there for. If you find any bugs one can resolve any help is very welcome: I only own a Linux PC with so little resources that starting up a virtual Win10 literally costs hours.

[daute]

Anyway, to get forward I wrote a little batch file inspired by the github action to download and compile wxWidgets and wxMaxima. It compiles fine (Using latest Visual Studio Pro 2022) and produces an exe. Just when I run it I get:

The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.

Maybe the according Visual Studio Runtime is missing, as described in some websites? (Maybe the runtime DLLs must be in the same directory as wxMaxima?)

(There is no way to test a run it in the CI, even just calling wxMaxima with --version or --help pops up a Window where one must click on the 'OK' button)...

[MSoegtropIMC]

I guess it is more the

INFO: Manifest Definition Identity is (null).

(There is no way to test a run it in the CI, even just calling wxMaxima with --version or --help pops up a Window where one must click on the 'OK' button)...

One could have a -ci-test option, which loads a file, recomputes it and terminates then.

[MSoegtropIMC]

@daute : I double checked this. The Visual Studio is freshly installed (it is a new machine). Other Windows C/C++ projects compiled work fine (Debug and Release) regardless how I start them (console, VS prompt, click in explorer). Visual Studio comes with a cmake project generator - I will see how this compares to wxmaxima.

[gunterkoenigsmann]

With a bit of luck now both the crash and the assembly identity are fixed by now, the latter only if I understand https://learn.microsoft.com/de-de/dotnet/framework/configure-apps/file-schema/runtime/assemblyidentity-element-for-runtime correctly. @MSoegtropIMC : In order to make the fix work you might have to configure the project again with CMake.

[gunterkoenigsmann]

Does any of you have a High-DPI monitor to test if the change in wxmaxima.manifest.in broke displaying wxMaxima in hi-res on such a monitor again?

[MSoegtropIMC]

@gunterkoenigsmann : not sure what qualifies as "High-DPI" - I am working on 2560x1440 27" monitors, which is 109 dpi.

[MSoegtropIMC]

@gunterkoenigsmann : I did rebuild main (with delete of build folder), but I am still getting the same error. But the nightly build from @daute works. So apparently this is an effect of my build procedure. I would say I faithfully followed the provided build instructions (essentially do what CI does), but this does not work - I think the documentation should be updated. @daute : how do you create the nightly build?

I will now test the nightly build from tonight until tomorrow and report issues here.

[gunterkoenigsmann]

The nightly windows build is done on Linux.

[gunterkoenigsmann]

...and high dpi should be everything from 140dpi upwards. My guess is that the problem isn't the build procedure but the MSVC runtime being more strict on errors in the side-by-side stuff than a gcc-compiled program is. Is the error message still the same? Perhaps it gives a hint on what still goes wrong. And testers are welcome: while searching for a rare crash I've changed over 500 places a static code analysis tool protested about hoping that one of the warnings is the problem that in the end Wolfgang's backtrace found. All the changes made the program faster and shorter. Some actually resolved bugs. But you never know if a change introduces new bugs in other places

[daute]

My Maxima installer? It is crosscompiled on Linux, I do not use Windows for that. I tried it once - using the Documentation from Maxima, and as a result there is a working crosscompiling procedure. ;-)

See https://sourceforge.net/p/maxima/code/ci/master/tree/crosscompile-windows/README.txt (and https://github.com/daute/maxima-crosscompilation) for more Info.

[MSoegtropIMC]

@gunterkoenigsmann : yes the error message and also the SxTrace are still the same:

The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.

=================
Begin Activation Context Generation.
Input Parameter:
        Flags = 0
        ProcessorArchitecture = AMD64
        CultureFallBacks = en-US;en;de-DE;de
        ManifestPath = D:\Maxima\wxMaximaSource\wxmaxima\build\src\Debug\wxmaxima.exe
        AssemblyDirectory = D:\Maxima\wxMaximaSource\wxmaxima\build\src\Debug\
        Application Config File =
-----------------
INFO: Parsing Manifest File D:\Maxima\wxMaximaSource\wxmaxima\build\src\Debug\wxmaxima.exe.
        INFO: Manifest Definition Identity is (null).
        INFO: Reference: Microsoft.Windows.Common-Controls,processorArchitecture="msil",publicKeyToken="6595b64144ccf1df",type="win32",version="6.0.0.0"
        INFO: Reference: Microsoft.Windows.Common-Controls,language="*",processorArchitecture="*",publicKeyToken="6595b64144ccf1df",type="win32",version="6.0.0.0"
ERROR: Activation Context generation failed.
End Activation Context Generation.

[MSoegtropIMC]

@daute : it would help getting more support from others on Windows to have a working build procedure which doesn't require Linux.

[MSoegtropIMC]

One observation: when I run the binary from @daute, the SxTrace is empty - I tried two times. So apparently it doesn't have a "side by side configuration" - whatever this might be.

[MSoegtropIMC]

@gunterkoenigsmann ; I now tried SxTrace with a MSVC generated demo Windows project. This reads:

=================
Begin Activation Context Generation.
Input Parameter:
        Flags = 0
        ProcessorArchitecture = AMD64
        CultureFallBacks = en-US;en;de-DE;de
        ManifestPath = C:\Users\Michael\source\repos\WindowsProject1\x64\Release\WindowsProject1.exe
        AssemblyDirectory = C:\Users\Michael\source\repos\WindowsProject1\x64\Release\
        Application Config File =
-----------------
INFO: Parsing Manifest File C:\Users\Michael\source\repos\WindowsProject1\x64\Release\WindowsProject1.exe.
        INFO: Manifest Definition Identity is (null).
INFO: Activation Context generation succeeded.
End Activation Context Generation.

So one can conclude that the INFO: Manifest Definition Identity is (null). is not an issue.

What looks fishy in the wxmaxima output is this line:

INFO: Reference: Microsoft.Windows.Common-Controls,language="*",processorArchitecture="*",publicKeyToken="6595b64144ccf1df",type="win32",version="6.0.0.0"

The &#x2a for processorArchitecture and language is likely the culprit. A &#x2a should be a * decoded.

[MSoegtropIMC]

Also note that in the initial SxTrace I posted, there is one reference less. In the new trace it goes fine over one reference but stops immediately after the reference with the &#x2a.

        INFO: Reference: Microsoft.Windows.Common-Controls,processorArchitecture="msil",publicKeyToken="6595b64144ccf1df",type="win32",version="6.0.0.0"
        INFO: Reference: Microsoft.Windows.Common-Controls,language="*",processorArchitecture="*",publicKeyToken="6595b64144ccf1df",type="win32",version="6.0.0.0"
ERROR: Activation Context generation failed.

[daute]

@daute : it would help getting more support from others on Windows to have a working build procedure which doesn't require Linux.

There are Windows build instructions for Maxima: https://sourceforge.net/p/maxima/code/ci/master/tree/INSTALL.win32 https://sourceforge.net/p/maxima/code/ci/master/tree/INSTALL.win32nogcl

But I tried it once, and decided that it's easier to develop a cross-compilation build procedure. :-) If you have improvements, I am sure, the Maxima-team would appreciate it.

[gunterkoenigsmann]

* is the HTML escape code for * - and the manifest file no more contains a "*" => somehow your build seems still to use the manifest file generated from the old .manifest.in file.

[gunterkoenigsmann]

Found a possible reason: wxMaxima.manifest is only generated when cmake confiures the project for the first time. Am looking for a way to avoid needing to do a completely clear build of an previously unconfigured project in order to accomodate changes in wxMaxima.manifest.in

[MSoegtropIMC]

@gunterkoenigsmann : Ah ok, I deleted the build folder, but I see that the manifest file is in include. I will delete it and see. - sorry this were the wxwidgets manifest files. the wxmaxima one is under build.

[MSoegtropIMC]

Talking of wxwidgets: the wxwidgets manifest file reads:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
    version="0.64.1.0"
    processorArchitecture="x86"
    name="Controls"
    type="win32"
/>
<description>wxWidgets application</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="*"
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
</dependency>
</assembly>

It does have asterisks at the points of interest.

[gunterkoenigsmann]

It also would make sense to support them. But your MSVC runtime for some reason seems not to...

[gunterkoenigsmann]

Seems like CMake doesn't support automatically determining if to re-make the .manifest file: I found a way to make cmake create a new .manifest file whenever the .manifest.in file changes. But that will create the .manifest file at build time while cmake expects that source file to exist at configure time, already.

[MSoegtropIMC]

@gunterkoenigsmann : don't bother about the make rules - this file should change so rarely, that it isn't worth it. As I wrote, I guess the issue is with the wxwidgets manifest files - still testing ...

[MSoegtropIMC]

Sorry, I can't find out what this is. I replaced all occurances of in manifests with a proper value or deleted it, but I am still getting the error. I did a clean rebuild (delete build and wxwidgets-source folder, re-extracted the wx-widgets source folder and patched the manifests). Still I have many occurances of `processorArchitecture=''` in .obj files of wxMaxima and wxwidgets when I grep through them. The error remains.

[MSoegtropIMC]

Just for my records, I keep track here (in this one post) of the things which worked at some time and are broken now:

• auto focus of search text in "find" dialog (actually this also doesn't work in the Mac release, but it did work once)

[gunterkoenigsmann]

About the focus issue I'll create an own ticket so it isn't lost. ...and if the binary in the end contains a manifest that the program didn't introduce perhaps the problem is that MSVC by default adds its own manifest to programs so after compilation the program contains two manifests: One from MSVC trying to be helpful and one from wxMaxima. In that case there will be a command-line parameter to MSVC that turns that off.

[MSoegtropIMC]

I more expect that the manifest comes from wxwidgets, since it requests exactly a library wxWidgets asks for. But who knows ...

[gunterkoenigsmann]

wxWidgets 3.2 seems to come with a working manifest => changed the code so that we don't use our own manifest any more as I hope that everyone who has an advanced monitor will use wxWidgets 3.2, by now.

[gunterkoenigsmann]

Another question: The auto-activation of the find dialogue: What event should trigger it and no more does?

[MSoegtropIMC]

Another question: The auto-activation of the find dialogue: What event should trigger it and no more does?

I would say Ctrl+F and the corresponding menu item. Since the actual find is triggered by a button in the dialog, there is no ambiguity between "bring up the find dialog" and "find the next item" as in some other editors.