"DIR /o" (no order specifier after /o) hasn't functioned the same as it does on Windows. This change makes the functionality of /o by itself equivalent to behavior on Windows.
--
v22: programs/cmd: Cleanup DIR /O logic and remove @todo_wine@ from working tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7131
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v3: windowscodecs: Remove redundant guid-to-string conversion when writing readers registration entries.
windowscodecs: Fix a typo in metadata readers registration helper.
windowscodecs/metadata: Add a stub for WICIfdMetadataWriter.
windowscodecs/metadata: Add a stub for WICExifMetadataWriter.
windowscodecs/metadata: Add a stub for WICGpsMetadataWriter.
windowscodecs/metadata: Add a stub for WICUnknownMetadataWriter.
windowscodecs/metadata: Add registration information for the "Unknown" writer.
windowscodecs: Add a stub for IWICMetadataWriterInfo.
windowscodecs: Move an hkey handle to the component info base structure.
windowscodecs: Move component info registry key cleanup to a common failure path.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7254
"DIR /o" (no order specifier after /o) hasn't functioned the same as it does on Windows. This change makes the functionality of /o by itself equivalent to behavior on Windows.
--
v20: programs/cmd: Remove @todo_wine@ from working tests.
programs/cmd: Cleanup DIR /O logic.
programs/cmd: Add tests patch from @epo.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7131
I don't think these are serious problems, but Clang 20's defaults (from llvm-mingw nightly) were resulting in build failures with `--enable-werror` due to `-Wtautological-compare` and `-Wunused-function`. I hope that the buffer wrap checking is somewhat idiomatic/standard.
If necessary, I can split off the winevulkan change, but it seems minor enough to be grouped in this MR.
--
v2: rpcrt4: Pointer arithmetic fixes (-Wtautological-compare).
https://gitlab.winehq.org/wine/wine/-/merge_requests/7231
On Tue Feb 4 17:55:14 2025 +0000, Tim Clem wrote:
> I think this calls for a quick comment (or at least a note in the commit
> message) as to why we're using this function.
Added a comment, explaining the rationale there.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7256#note_93649
`mach_continuous_approximate_time()` has the necessary precision for win32 ticks and can be up to 4x faster than `mach_continuous_time()`.
Also `clock_gettime( CLOCK_REALTIME, &ts )` calls always end up in `__commpage_gettimeofday( struct timeval *tp )`:
```
* frame #0: 0x00007ff806788763 libsystem_kernel.dylib`__commpage_gettimeofday
frame #1: 0x00007ff8066709a3 libsystem_c.dylib`gettimeofday + 45
frame #2: 0x00007ff806678b31 libsystem_c.dylib`clock_gettime + 117
```
These extra calls, setup and converting from one struct format to another costs another 60 CPU cycles and in my testing makes `NtQuerySystemTime` approximately 30% faster as well with this MR. This is a fairly hot code path (especially when using certain out-of-tree in process synchronization patch sets), so probably worth the optimization here.
All of these APIs are available since 10.12.
--
v2: ntdll: Replace '0' with 'NULL' in gettimeofday() calls.
ntdll: Use __commpage_gettimeofday in NtQuerySystemTime on macOS.
ntdll: Always use mach_continuous_approximate_time on macOS.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7256