Am 11.08.2026 um 17:50 schrieb Jim Jagielski:
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 :-)
Imho the windows C++11 issue was an issue because Microsoft moved to the
new standard slower then other system tool builders.
WSL is nothing i would consider. Basically it is you run a full Linux
Distribution within windows through a Hypervisor and have a "seemless"
integration. So i used it to run tools that are laging behind on windows.
But you have all the issues from containerization. Plus you need to
activate the hyperwisor. Its cool if you want to use Windows but you
jump into Linux environments. The same is true for Android.
It just to much overhead for normal users.
What was interesting to me was if we could circumvent the bumb of VC9 by
switching compilers. But all option were not feasible and ended in same
or bigger work then bumbing VC9.
So far I have not found any reason to switch tooling away from MSVC.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
