Normally I am a strong proponent of adjusting implementations one small step at
a time, but this is a bit of an extreme case.
The current state of UrlCanonicalize() is a prototypical example of "spaghetti
code": the implementation has been repeatedly adjusted to fix a new discovered
edge case, without properly testing the scope of the new logic, with the effect
that the current logic is a scattered mess of conditions that interact in
unpredictable ways.
To be fair, the actual function is much more complicated than one would
anticipate, and the number of new weird edge cases I found while trying to flesh
out existing logic was rather exhausting.
I initially tried to "fix" the existing implementation one step at a time. After
racking up dozens of commits without an end in sight, though, and having to
waste time carefully unravelling the broken code in the right order so as to
avoid temporary failures, I decided instead to just fix everything at once,
effectively rewriting the function from scratch, and this proved to be much more
productive.
Hopefully the huge swath of new tests is enough to prove that this new
implementation really is correct, and has no more spaghetti than what Microsoft
made necessary.
--
v4: shlwapi/tests: Add many more tests for UrlCanonicalize().
kernelbase: Use scheme_is_opaque() in UrlIs().
kernelbase: Reimplement UrlCanonicalize().
kernelbase: Do not canonicalize the relative part in UrlCombine().
kernelbase: Do not use isalnum() with Unicode characters.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4954
This MR implements `NtContinueEx(PCONTEXT, PCONTINUE_OPTIONS)` which was added in Windows 10 20H1.
Also added basic test reusing existing `test_continue()` (included from !4720)
League of Legends game hooks `NtContinue()` and `NtContinueEx()` by putting `jmp` instruction in front of it.
Note that LoL doesn't actually use `NtContinueEx()` itself and game will work fine without it but if game doesn't find `NtContinueEx()` it will permanently ban your account due to detecting "scripting program"
--
v5: ntdll/tests: Implement APC test for NtContinue()
ntdll/tests: Add basic test for NtContinueEx()
ntdll: Implement NtContinueEx()
ntdll/tests: Unify APC test functions
https://gitlab.winehq.org/wine/wine/-/merge_requests/4761
On Tue Feb 6 18:52:35 2024 +0000, Esme Povirk wrote:
> No, that doesn't seem right either, I need to think about this.
Thought about it, I do think it should be ||. We should break if all of the text has been measured, and we should break if the current section doesn't fully fit in to_measure_length.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4082#note_60325
On Tue Feb 6 15:01:50 2024 +0000, Santino Mazza wrote:
> I tested GdipMeasureString with different strings that require font
> linking and it behaves correctly. It's strange because I also tested
> with the exact same string the game uses and with the generic
> typographic format, but I still can't get the bug to reproduce.
> Apparently when the game tries to draw that specific string,
> GdipMeasureString returns a bounding box with width 0, which causes
> draw_string_callback to not increase the X position, so it overwrites
> the other word. Again this doesn't happen if I use font_link_get_text_extent_point.
The difference might have to do with scaling? It looks like GdipMeasureString scales the size, and I don't think font_link_get_text_extent_point would.
Come to think of it, it's probably necessary to account for text rotation when in draw_string_callback (an arbitrary affine transform can be applied to the text, although I think at the moment our handling of anything beyond rotation is a bit broken). I think it might be a good idea to add output parameters for dx and dy to draw_driver_string.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4082#note_60317
Fixes a crash in Microsoft Flight Simulator (which passes some currently invalid values to ucrtbase._gmtime64() and doesn't expect NULL result).
It looks like any msvcrt version on modern Windows accepts wider range of values. Meanwhile, the exact range is different for ucrtbase vs older CRT versions (the exact values for ucrtbase also vary before Win10 1909). Also, older msvcrt.dll matches what we have in Wine now. So the patch keeps old msvcrt behavior, adds universally correct limits for msvcrt 70-120 and the latest (Win10 1909+) for ucrtbase.
--
v2: msvcrt: Adjust _gmtime64_s() accepted time limits.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5024
There are still some issues I need to fix, mainly around timing conversion between MIDI and dmusic. Right now MIDI files seem to be cut off before the end is reached.
Please have a look at the general approach in the meantime, I need to know if this is the right way to do this or not.
--
v11: dmime: Create a band track for MIDI segments.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4982
The game I was trying to run (Ravendawn) was polluting the stdout with hundreds of CreateFile2 FIXMEs.
The game worked fine, probably because the params pointer was NULL, so any non-implemented extra parameters weren't even used and we just forwarded to CreateFileW.
So, a simple if was added to check whether the pointer is null, and if it is, we just call TRACE instead of FIXME since in this case it isn't really necessary.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5037