Thanks! That's useful info. I was more curious than anything else, knowing that (1) there aren't that many Win64 developers and that (2) there were some discussions that the move from c++98 -> c++11 might be problematic due to availability of a corresponding windows SDK or toolkit. So I just did some quick looking into other options. One was WSL which would allow us to build for Linux but run on Windows, and the other was maybe just go full linux-like builds; knowing that MSSY2 was a better alternative than cygwin, I was just wondering if maybe using that might make it easier for the Windows side of things. FWIW, I have no experience with either :-)
> On Aug 11, 2026, at 11:26 AM, [email protected] wrote: > > > Am 11.08.2026 um 15:23 schrieb Jim Jagielski: >> My investigation with Linux and macOS is that C++11 has been sufficient, >> especially for the updated versions of the various external dependencies we >> pull in. The C++98->c++11 bump is a bit less then jumping all the way to 14, >> which may be a factor. > yes C++11 is what we should aim at for now. The Issue is that at least > microsoft newer compiler lowest limit is C++14. >> Still curious about the feasibility of just baselining MSYS2 which provides >> both a gcc-based and clang-based build environment and just using the UCRT >> runtime instead of the MSVCRT... does anyone have any insights? > About msys2, we are using that already ot build AOO. It creates a lot of > fragility, since AWK from cygwin is not the same as in linux and we need to > fix it. And on the build bot it was one porblem that an update can, render a > build bot useless after a simple update. > What we do not use is the minGW compilers. They mimic GNU on Windows and have > some restraints i thing. Its main boon is to port Linux tools to windows. I > read that the MinGW support for the API lags behind. > The MSVC gives the best experience on Windows. And we have the structure to > support them. > Clang mimics MSVC behaviour on windows. (It may be that it can even mimic > MinGW behaviour). I remeber it enjoys official support from Microsoft. I am > playing with it a bit in the background. Not sure what it means for the > current build environment to support Clang instead of MSVC. However Clang > needs the Microsoft SDK, it does not bring an own (unlike MinGW, which is > based on the GNU stack) > > In total I did not see much benefit in MinGW. Clang is much more interesting > to use. But i have done quite some debugging with MSVC, I think i am fine > with that one too. Modernization will help a lot on windows. > Do you want to try something specific? Or in which direction do your thoughts > go? >> >>> On Aug 11, 2026, at 9:11 AM, Peter Kovacs <[email protected]> wrote: >>> >>> >>> >>> Am 11. August 2026 13:07:10 MESZ schrieb Jim Jagielski <[email protected] >>> <mailto:[email protected]>>: >>>> I've no real experience with building for Windows so these questions are >>>> based 100% on ignorance. What about building with MSYS2 (and the UNC) or >>>> maybe WSL? I know that we use cygwin to drive things but my understanding >>>> is that we still depend on Windows specific SDKs and compilers. Would a >>>> pivot to a total MSYS2 build bypass all that? >>> Sorry, i did not write clearly. >>> In order out code compiles on newer compilers we might need to change code. >>> I am looking into compatibility of C++98 to C++14. If the compilers is >>> newer, it might need C++17 or newer. At least the AI claimed that other >>> changes would become necessary if we use an compiler that is newer. >>> It might be small things. >>> So if the compilers on Mac the lowest is C++17, It may be worth it if I do >>> the windows update with a newer version. >>> Since for my personal fun I keep C++98 compatibility for now. That would >>> mean AOO would be by nature able to be compiles by a bigger range of >>> compilers. >>>> I _think_ that that would also allow us to support Win7, but again, I'm >>>> not exactly sure. >>>> >>>>> On Aug 11, 2026, at 1:58 AM, [email protected] wrote: >>>>> >>>>> Hi Jim, all, >>>>> >>>>> >>>>> I switched a bit the target, and try to do a minimal change raise to Win >>>>> 10 with modern compilers. >>>>> As cheap as possible. >>>>> >>>>> I found following issue: >>>>> >>>>> *An override may not make a weaker promise about throwing than the thing >>>>> it overrides* — because a caller holding a base pointer was told "this >>>>> never throws" and may rely on it. >>>>> >>>>> Your instinct was close. The adjustment: it's not that the destructor >>>>> must be /valid/ at every level, it's that the *promise must not get >>>>> weaker as you go down the chain*. >>>>> >>>>> What changed in C++11 isn't the rule — it's *who makes the promise*. >>>>> Under C++03, a destructor with nothing written on it had no promise, so >>>>> nothing could conflict. From C++11 on, the compiler fills one in, and a >>>>> class with nothing throwing inside silently gets /"never throws"/. At a >>>>> class inheriting from both a pre-UNO base and a UNO base, three promises >>>>> meet and only one was typed by a human — and the compiler's deduced >>>>> promise for the derived class is weaker than the compiler's deduced >>>>> promise for the legacy base. It fails in a class where nobody wrote a >>>>> destructor at all. >>>>> >>>>> None of these destructors actually throws. It's a paperwork conflict, and >>>>> the fix emits identical machine code. >>>>> >>>>> here is an abstract code example: >>>>> >>>>> struct Legacy { virtual ~Legacy(); }; // no spec written >>>>> struct Uno { virtual ~Uno() throw(RuntimeException); }; >>>>> struct Both : Legacy, Uno { }; // no destructor at all >>>>> >>>>> The situation on windows: >>>>> >>>>> ompiler / mode |SAL_THROW|expands to The destructor conflict >>>>> Forward declaration >>>>> VC9 (C++03) |throw(exc)| /doesn't exist/— no implicit promises >>>>> accepted >>>>> MSVC 14.29|/std:c++14| |throw(exc)| *error C2694* accepted, >>>>> silently >>>>> clang, Windows/MSVC target, c++14 |throw(exc)| *warning* >>>>> *warning* >>>>> …same, with|-Werror|on that flag >>>>> error error >>>>> clang, Windows/MSVC target, c++17 |throw(exc)| — *error: >>>>> dynamic exception specifications not allowed* >>>>> clang, MinGW target *nothing* /doesn't exist/— no specs at >>>>> all unused >>>>> >>>>> I forgot what is the floor we have on Apple side. >>>>> >>>>> For the existing issue i found a solution, to declare the runtime. Which >>>>> is cheap solution that makes AOO build. But Since i work with C++14 I >>>>> might miss some language error we might run into. >>>>> does it make sense to change the code to the highest floor Version we >>>>> need? >>>>> >>>>> All the best >>>>> >>>>> Peter >>>>> >>>> -- >>>> Jim >>>> "This is an outrage!" >>>> Tony Harrison >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> <mailto:[email protected]> >>> For additional commands, e-mail: [email protected] >>> <mailto:[email protected]> >> -- >> Jim >> "This is an outrage!" >> Tony Harrison >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Jim "This is an outrage!" Tony Harrison
