[PATCH 0/19] MR1191: msvcm: add missing function implementation
After applying these patches, the applications Athenas ASS MHFU v3.42b and miniDSP/IL-DSP runs without crash, and working correctly. Wine-bug: https://bugs.winehq.org/show_bug.cgi?id=47304 Wine-bug: https://bugs.winehq.org/show_bug.cgi?id=34537 Wine-bug: https://bugs.winehq.org/show_bug.cgi?id=32091 -- 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/1191
Piotr Caban (@piotr) commented about dlls/msvcp90/ios.c:
basic_ostream_wchar_vbase_dtor(&wclog.obj); basic_filebuf_wchar_dtor(&filebuf_wchar_log); } + + +// ?_Cin_func(a)std@@YAAAV?$basic_istream(a)DU?$char_traits(a)D@std@@@1(a)XZ +// ?_Cin_func(a)std@@YAAEAV?$basic_istream(a)DU?$char_traits(a)D@std@@@1(a)XZ
Please don't use C++ style comments (use /* ... */ instead).
msvcp90: add _Cin_func implementation
Please change commit message to: msvcp90: Add _Cin_func implementation.
We use Wine-Bug tag to store links to bugs. Please add it only to the patch that is fixing the bug (not all the patches in MR). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1191#note_12494
Piotr Caban (@piotr) commented about dlls/msvcp90/ios.c:
basic_istream_char* __cdecl _Cin_func(void) { return &cin.obj; +} + +// ?_Wcin_func(a)std@@YAAAV?$basic_istream(a)GU?$char_traits(a)G@std@@@1(a)XZ +// ?_Wcin_func(a)std@@YAAEAV?$basic_istream(a)GU?$char_traits(a)G@std@@@1(a)XZ +// ?_Wcin_func(a)std@@YAAAV?$basic_istream(a)_WU?$char_traits(a)_W@std@@@1(a)XZ +// ?_Wcin_func(a)std@@YAAEAV?$basic_istream(a)_WU?$char_traits(a)_W@std@@@1(a)XZ +// class std::basic_istream<unsigned short,struct std::char_traits<unsigned short> > & __cdecl std::_Wcin_func(void) +// class std::basic_istream<unsigned short,struct std::char_traits<unsigned short> > & __ptr64 __cdecl std::_Wcin_func(void) +// class std::basic_istream<wchar_t,struct std::char_traits<wchar_t> > & __cdecl std::_Wcin_func(void) +// class std::basic_istream<wchar_t,struct std::char_traits<wchar_t> > & __ptr64 __cdecl std::_Wcin_func(void) +basic_istream_wchar* __cdecl _Wcin_func(void) +{ + return &wcin.obj; unsigned short version should &ucin.obj instead.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1191#note_12495
Piotr Caban (@piotr) commented about dlls/msvcp90/ios.c:
basic_filebuf_wchar_dtor(&filebuf_wchar_log); }
- // ?_Cin_func(a)std@@YAAAV?$basic_istream(a)DU?$char_traits(a)D@std@@@1(a)XZ // ?_Cin_func(a)std@@YAAEAV?$basic_istream(a)DU?$char_traits(a)D@std@@@1(a)XZ +// class std::basic_istream<char,struct std::char_traits<char> > & __cdecl std::_Cin_func(void)
I'm not sure what to think about adding demangled function headers in comments. While it can improve readability in some cases it adds a lot of redundant information. Please stick to current style of not adding them - we can discuss adding them on wine-devel or in separate MR. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1191#note_12496
Piotr Caban (@piotr) commented about dlls/msvcm80/msvcm80.spec:
@ stub -arch=win64 ?_BADOFF_func(a)std@@YAAEB_JXZ @ stub -arch=win32 ?_Cerr_func(a)std@@YAAAV?$basic_ostream(a)DU?$char_traits(a)D@std@@@1(a)XZ @ stub -arch=win64 ?_Cerr_func(a)std@@YAAEAV?$basic_ostream(a)DU?$char_traits(a)D@std@@@1(a)XZ -@ stub -arch=win32 ?_Cin_func(a)std@@YAAAV?$basic_istream(a)DU?$char_traits(a)D@std@@@1(a)XZ -@ stub -arch=win64 ?_Cin_func(a)std@@YAAEAV?$basic_istream(a)DU?$char_traits(a)D@std@@@1(a)XZ +@ cdecl -arch=win32 ?_Cin_func(a)std@@YAAAV?$basic_istream(a)DU?$char_traits(a)D@std@@@1(a)XZ() msvcp90.?_Cin_func(a)std@@YAAAV?$basic_istream(a)DU?$char_traits(a)D@std@@@1(a)XZ +@ cdecl -arch=win64 ?_Cin_func(a)std@@YAAEAV?$basic_istream(a)DU?$char_traits(a)D@std@@@1(a)XZ() msvcp90.?_Cin_func(a)std@@YAAEAV?$basic_istream(a)DU?$char_traits(a)D@std@@@1(a)XZ I'm not familiar with msvcm* dlls. I don't know if it's correct. Is the dll exporting any unmanaged functions? If so please add some tests.
It's probably best to get the changes to msvcp* dlls first and then try to figure out what can be done with msvcm. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1191#note_12497
On Mon Oct 31 12:21:52 2022 +0000, Piotr Caban wrote:
Please don't use C++ style comments (use /* ... */ instead).
msvcp90: add _Cin_func implementation Please change commit message to: msvcp90: Add _Cin_func implementation. Wine-bug: https://bugs.winehq.org/show_bug.cgi?id=47304 We use Wine-Bug tag to store links to bugs. Please add it only to the patch that is fixing the bug (not all the patches in MR). All these patches are necessary for running Athenas ASS MHFU v3.42b application. After applying these patches other application (miniDSP/IL-DSP) also starts workings
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1191#note_12499
On Mon Oct 31 12:44:54 2022 +0000, Bartosz Kosiorek wrote:
All these patches are necessary for running Athenas ASS MHFU v3.42b application. After applying these patches other application (miniDSP/IL-DSP) also starts workings Let's look on first of the bugs (https://bugs.winehq.org/show_bug.cgi?id=47304). It's title is as follows:
Multiple applications crash on unimplemented function msvcm90.dll.?_Cin_func(a)std@@YAAAV?$basic_istream(a)DU?$char_traits(a)D@std@@@1(a)XZ (Athena's Charm Table search 0.35b, Intuit QuickBooks Pro 2012, MiniDSP iL-DSP v1.1)
What I've meant is that `Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47304` should be added to https://gitlab.winehq.org/wine/wine/-/merge_requests/1191/diffs?commit_id=d8... patch only. If multiple patches are needed to fix a bug - usually you add the Wine-Bug tag to the last patch only. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1191#note_12503
On Mon Oct 31 12:21:54 2022 +0000, Piotr Caban wrote:
I'm not familiar with msvcm* dlls. I don't know if it's correct. Is the dll exporting any unmanaged functions? If so please add some tests. It's probably best to get the changes to msvcp* dlls first and then try to figure out what can be done with msvcm. I am also not familiar with msvcm*. I only noticed that many already declared functions are pointing to the `msvcp90` DLL library. Also the mangled names are exactly the same. After applying these patches two tested applications starts working.
Do you have some tips how the tests could be written? I am novice in that area. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1191#note_12508
On Mon Oct 31 13:49:18 2022 +0000, Bartosz Kosiorek wrote:
I am also not familiar with msvcm*. I only noticed that many already declared functions are pointing to the `msvcp90` DLL library. Also the mangled names are exactly the same. After applying these patches two tested applications starts working. Do you have some tips how the tests could be written? I am novice in that area. The msvcm (Microsoft Visual C++ Managed Runtime) is used as a compatibility library. It allows using managed code (e.g. from Visual Studio 2005) with old Visual Studio (6.0): https://www.developer.com/microsoft/c-sharp/managed-unmanaged-native-what-ki...
More information is available at: https://social.msdn.microsoft.com/Forums/en-US/736125a3-634d-4265-9ee0-f17f7... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1191#note_12661
On Tue Nov 1 17:51:25 2022 +0000, Bartosz Kosiorek wrote:
The msvcm (Microsoft Visual C++ Managed Runtime) is used as a compatibility library. It allows using managed code (e.g. from Visual Studio 2005) with old Visual Studio (6.0): https://www.developer.com/microsoft/c-sharp/managed-unmanaged-native-what-ki... More information is available at: https://social.msdn.microsoft.com/Forums/en-US/736125a3-634d-4265-9ee0-f17f7... I don't really know how to proceed on msvcm functions without spending lots of time on it. I'm also afraid that if it will be hard to implement managed parts of the dll if needed.
Currently none of the functions from msvcm forwards to msvcp. You can try calling the functions in tests to see what is returned (and if e.g. the structure matches with msvcp). It would be hard to see any side effects this way thought. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1191#note_12664
On Tue Nov 1 18:24:55 2022 +0000, Piotr Caban wrote:
I don't really know how to proceed on msvcm functions without spending lots of time on it. I'm also afraid that if it will be hard to implement managed parts of the dll if needed. Currently none of the functions from msvcm forwards to msvcp. You can try calling the functions in tests to see what is returned (and if e.g. the structure matches with msvcp). It would be hard to see any side effects this way thought. I forgot to mention - another option for msvcm is to add stubs like we do for other functions to see if it's enough to get the app running.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1191#note_12666
participants (2)
-
Bartosz Kosiorek (＠gang65) -
Piotr Caban (＠piotr)