## Summary
Tests for UrlFixupW and semi stub function implementaion.
## Test results
- Tests are 100% ok on my local WIN 10 pc. Wine test bot seems to be okay too.
- Wine tests on debian machine
| function type | result |
| ------ | ------ |
| stub | 0020:url: 69802 tests executed (0 marked as todo, 0 as flaky, **200** failures), 0 skipped. |
| semi stub| 0020:url: 69802 tests executed (0 marked as todo, 0 as flaky, **100** failures), 0 skipped. |
## Todos
For follow up merge request(s).
- [ ] Add more tests for priority investigation, who url scheme fix up is working on windows.
- [ ] Implement missing parts of fix up.
## Conclusion
Semi stub implementation is an improvement to the existing solution. A grep showed that wine internals do not call this function, therefore it should not introduce any new bugs. Windows applications using/relying on the function should now work better, if not they may reveal already existing bugs.
--
v6: shlwapi: fixup leading and trailing typos in UrlFixupW
shlwapi: check for colon in UrlFixupW
kernelbase: Restructure UrlFixupW()
shlwapi/tests: Add tests for UrlFixupW.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1825
These invalid formats are rejected when creating WIC render targets. Otherwise, Wine may create a WIC render target with an unsupported format and in turn, will make testing IsSupported() method difficult.
--
v3: d2d1: Test creating WIC bitmap render targets.
d2d1: Reject unsupported formats when creating WIC bitmap render targets.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1321
Windows has a limit of 32767 characters in the environment block. https://superuser.com/questions/1070272/why-does-windows-have-a-limit-on-en…
Wine doesn't attempt to respect that at all. Do some programs actually depend on this? Unfortunately yes.
With this patch, during initialization, if the block size would exceed (or be close to) the limit, the biggest environment variables will be excluded.
This is useful when a user has very long environment variables in their system for reasons unrelated to Wine.
Do note that there's still nothing done to make sure that the limit isn't exceeded after initialization.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56941
Signed-off-by: Martino Fontana <tinozzo123(a)gmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6140
Salvage tests and fix a leak found in another review: see https://gitlab.winehq.org/wine/wine/-/merge_requests/897#note_9175 points 1 and 2. 3. is why !897 was reverted.
This does not contain the (incorrect) changes to VariantCopyInd, but instead fixes the leak identified in VariantClear (VT_RECORD needs to free pvRecord), and the wrong allocator being used in VariantCopy (it should have been IMalloc, rather than `HeapAlloc`, as shown by the fact IMallocSpy observes these allocations).
This also cleans up some dubious behavior by the test IRecordInfoImpl, which was modifying a VARIANT that it did not own or receive as an argument in the middle of VariantClear. This was likely undefined behavior, and in any case concealed the heap leak.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1035