It looks like msvcp doesn't export anything for the std::bad_function_call exception construction and if std::bad_function_call is constructed directly from the app the corresponding class data is generated in the application binary.
I am attaching an ad-hoc test program I used to test it (using MSVC 2022 community edition).
[msvcp_except.cpp](/uploads/558f0911366525d05af4ac69552c4aae/msvcp_except.cpp)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4446
This serie:
- adds a couple of msvcrt env tests (mainly env block inheritance)
- introduces env tests for ucrtbase
- reimplement most of the env related functions to mimic native
behavior (basically when env is modified, native crt uses
a per-variable entry allocation block (instead of having
pointers inside a single chunk of memory).
This fixes programs which keep a pointer on returned getenv()
string and expect that pointer content is not modified when
other variables in env are modified.
@piotr: from previous version
- I dropped the synchronization of \_environ and \_wenviron
hence requiring the duplication of most of the code in
ansi/unicode versions
- I also tested the changes with unicode crt startup code
(you can find in [1] this MR extended with this test code
but I don't think we want to push it upstream)
- there are some init code changes because of ucrtbase tests
and unicode crt startup tests
[1] https://gitlab.winehq.org/epo/wine/-/tree/mr-crt-env-full?ref_type=heads
--
v5: msvcrt: Fix ucrtbase environment initialization.
msvcrt: Allocate environment variables in separate allocation chunks.
msvcrt: Lazily initialize ___winitenv.
msvcrt: Factor out wenv_get_index helper.
msvcrt: Factor out env_get_index helper.
ucrtbase/tests: Introduce environment tests.
msvcrt/tests: Test passing environment in child process.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4377
This allows initializing locale from Mac locale identifiers like
'zh-Hans-US'. The current implementation recognizes it as 'zh-US'
which isn't a valid locale identifier for Windows.
This patch will try again with the 'lang-script' identifier after
get_win_locale() fails with the 'lang-region' identifier.
--
v3: ntdll/unix: Support to initialize locale from 'lang-script' format language identifier.
ntdll/unix: Use different variable names for Mac locales.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4357
Based on @rbernon's work in !1088, with additional ARM support and
some cleanups.
--
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4445
I tested a program a user was asking about on the forum (https://forum.winehq.org/viewtopic.php?t=38192).
The program (or in fact a file called Unity.Licensing.Client.exe) looks for namespace "root\\StandardCimv2"
After adding this patch following query is done:
0024:trace:wbemprox:wbem_services_ExecQuery 00007FFB582B6660, L"WQL", L"SELECT Name,InterfaceDescription,PermanentAddress,NetworkAddresses,PNPDeviceID FROM MSFT_NetAdapter", 0x20, 0000000000000000, 00007FFFFE27DCD8
I don't know exactly what the problem is that user is experiencing, I can only tell that I'm not able to login. I provided some
dummy values for the requested properties from the MSFT_NetAdapter class but that didn't help. For now I think adding the MSFT_NetAdapter class
is not yet worth the trouble, but with this patch it is at least visible for what class the program is looking for.
The program can be found at https://unity3d.atlassian.net/wiki/spaces/AR/pages/1571848193/New+in+ArtEng…
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4453