On Tue Feb 14 16:20:32 2023 +0000, Jacek Caban wrote:
> This will work, but while reviewing this I noticed that current handling
> of VT_R4 and VT_R8 is not exactly right, overflow checks don't really
> make sense. Fixing that allows to simplify VT_BSTR case a bit. Please
> take a look at https://gitlab.winehq.org/jacek/wine/-/commits/varabs/
> and if it looks good to you, update MR with that branch (it also
> contains BSTR allocation fixup).
Thanks. Hopefully I rebased properly!
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2175#note_24086
While working in vbscript, I noticed abs on a `BSTR` value with a positive number would come back with an invalid value.
Given the following script:
```
Dim x
x = "30000"
Debug.Print "x" & "=" & abs(x)
```
Outputs:
```
Script.Print 'x=3.08221696253945E-314'
```
After debugging, `pVarIn` gets the R8 value but is never shallow copied into `pVarOut`.
I'm not sure how to write a test case in `oleaut32`, so I included a test case in `vbscript`.
--
v7: oleaut32: fix VarAbs function for BSTR with positive values
oleaut32: Fix VarAbs function for BSTR with positive values.
oleaut32: Remove overflow check for VT_R4 and VT_R8 in VarAbs.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2175
Today, test_RtlUniform() skips almost all of its tests on Windows Vista
or later. The skipped tests only succeed in Windows XP, and fail on
Windows Vista or later.
This is because RtlUniform()'s behavior has changed, presumably due to a
bug fix shipped in Windows Vista. It appears that RtlUniform, a linear
congruential generator, could overflow before computing the modulo in
WindoWs XP. This is no longer the case in Windows Vista or later.
Meanwhile, we no longer support Windows XP behavior and thus do not test
for it regularly; therefore, the tests are obsolete as of 2023.
Remove obsolete tests that no longer work with any of the Windows
versions actively tested by WineHQ (as of 2023), and replace them with
updated tests that works in the Windows versions from Vista up to 10.
Also, fix Wine's RtlUniform() to match the new behavior accordingly.
--
v10: ntdll: Fix integer overflow in RtlUniform.
https://gitlab.winehq.org/wine/wine/-/merge_requests/821
While working in vbscript, I noticed abs on a `BSTR` value with a positive number would come back with an invalid value.
Given the following script:
```
Dim x
x = "30000"
Debug.Print "x" & "=" & abs(x)
```
Outputs:
```
Script.Print 'x=3.08221696253945E-314'
```
After debugging, `pVarIn` gets the R8 value but is never shallow copied into `pVarOut`.
I'm not sure how to write a test case in `oleaut32`, so I included a test case in `vbscript`.
--
v6: oleaut32: fix VarAbs function for BSTR with positive values
https://gitlab.winehq.org/wine/wine/-/merge_requests/2175
On Tue Feb 14 14:55:14 2023 +0000, Huw Davies wrote:
> The optimization below doesn't seem to be worth it. On x86_64 I
> couldn't measure a difference between the algorithm above and the
> optimization below. On i386, while the optimization was about 10%
> faster, the algorithm above matched native's performance, so there seems
> little point in adding the complexity.
> If you really need the optimization, you could potentially introduce it
> in a later MR.
It was an attempt to implement it in an unusual way so that there was low likelihood that the algorithm matched any particular existing implementation.
I'll switch to the modulo one anyway.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/821#note_24060
Huw Davies (@huw) commented about dlls/ntdll/rtl.c:
> - result = *seed * 0xffffffed + 0x7fffffc3;
> - if (result == 0xffffffff || result == 0x7ffffffe) {
> - result = (result + 2) & MAXLONG;
> - } else if (result == 0x7fffffff) {
> - result = 0;
> - } else if ((result & 0x80000000) == 0) {
> - result = result + (~result & 1);
> - } else {
> - result = (result + (result & 1)) & MAXLONG;
> - } /* if */
> + /* The algorithm below is equivalent to the following expression:
> + *
> + * result = ((ULONGLONG)*seed * 0x7fffffed + 0x7fffffc3) % 0x7fffffff;
> + * return (*seed = result);
> + */
> +
The optimization below doesn't seem to be worth it. On x86_64 I couldn't measure a difference between the algorithm above and the optimization below. On i386, while the optimization was about 10% faster, the algorithm above matched native's performance, so there seems little point in adding the complexity.
If you really need the optimization, you could potentially introduce it in a later MR.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/821#note_24059
User32 uses the input codepage in Unicode edit control.
However, it uses ANSI codepage, i.e. CP_ACP, in ANSI version control.
Comctl32 is different from user32. It doesn't have A-W duality and uses the input codepage in it.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54424
--
v2: comctl32/tests: Add WM_CHAR tests for edit control.
user32/edit: Use CP_ACP for WM_CHAR convresion in ANSI version control.
user32/tests: Fix WM_CHAR tests to use the input codepage.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2173
This serie is to move Wine's implementation of EnumProcessModules
closer to Windows' behavior.
Wine's current implementation is broken for a wow64 process enumerated
from a 64bit bit process:
- it returns the list of 32bit modules, while Windows returns the main
module (32bit) and the 64bit modules (in wow64 process).
This series:
- adds tests to demonstrate that discrepancy
- fix all caller's to EnumProcessModules in Wine source tree which
require the 32bit bit modules (thanks to EnumProcessModulesEx)
- fortunately, a couple of callers only require the first (main)
module and don't need to be changed.
- re-implement EnumProcessModules on top of EnumProcessModulesEx
(to mimic Window's results)
- shows also that Wine's implementation returns loaded modules
from a different directory than Windows. Also tested on Win10,
the returned paths from EnumProcessModules+GetModuleFileNameEx
are the same as the ones stored in LDR_DATA.
So, there's still more work to do after this serie:
- with loader's path for wow64 processes
- fix dbghelp to handle the conversions: information from
EnumProcessModules, debug events reports from system32, while
dbghelp (SymEnumerateModules, SymRefreshModules and the like)
report from syswow64! (except ntdll)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2186