Implement fallbacks for functions unavailable in older versions of Windows #13932
Conversation
|
I'm still unconvinced that we should add this level of complexity to support an OS that's no longer supported. I don't think there's consensus to do this in #12842. If a bug is found in this code or it gets in the way of a change, can it be stripped out without trying to fix it? |
|
@thestinger, this compatibility layer is implemented such that calls after the initial function loading are essentially directly to the function in question (or the fallback on older versions), and otherwise has the same exact function signatures. The modifications I made to libnative to use it were just to point it to a different module. |
|
As for the lack of support for the OS, for what it's worth, Server 2003 is still being supported for another year. |
|
So can we drop it when Server 2003 / XP Embedded are no longer supported? If the answer isn't yes, the argument that there are still supported XP version (unlikely to be used by anyone with Rust) doesn't really work. What's the lifespan of this extra code? I think this needs to be addressed, along with whether this needs to be maintained by anyone touching this code or if it can simply be dropped rather than fixing it. |
|
I don't want to bend over backwards to support XP, but if patches are provided (thanks to @MrAlert!) and they're not invasive (as it is here), then I don't mind accepting them. We don't currently have a fundamental reason to not support XP, although one may arise in the future. |
Well it's a bit like supporting IE7/8 when doing web development. |
This addresses #12842 by offering fallback implementations for functions that aren't available. In this case, as Windows XP simply doesn't support symbolic links at all, the fallbacks simply return an error code indicating that the function hasn't been implemented. This should allow programs written in Rust to run under XP while still offering full support for symbolic links under newer versions of Windows with the same binary, but due to LLVM using stderror_s(), which isn't available in msvcrt.dll in XP, rustc itself will not. The fallback implementation is as follows: Calling the function instead calls to a mutable function pointer. This in and of itself would not constitute a performance hit because DLL calls are implemented in a similar manner (see Import Address Table). The function pointer initially points to a thunk which tries to get the address of the associated function and write it back to the function pointer. If it fails to find the function, it instead writes the address to a fallback. As this operation is idempotent, reading and writing the pointer simply needs to be atomic. Subsequent calls to the function should be as fast as any other DLL call, as the pointer will then point directly to either the correct function or a fallback.
…-lang#13932) When the expression is transformed into an equality, parentheses are needed only if the resulting equality is used: - as a receiver in a method call - as part of a binary or unary expression - as part of a cast In other cases, which will be the majority, no parentheses are required. This makes the lint suggestions cleaner. changelog: `none`
This addresses #12842 by offering fallback implementations for functions that aren't available.
In this case, as Windows XP simply doesn't support symbolic links at all, the fallbacks simply return an error code indicating that the function hasn't been implemented. This should allow programs written in Rust to run under XP while still offering full support for symbolic links under newer versions of Windows with the same binary, but due to LLVM using stderror_s(), which isn't available in msvcrt.dll in XP, rustc itself will not.
The fallback implementation is as follows:
Calling the function instead calls to a mutable function pointer. This in and of itself would not constitute a performance hit because DLL calls are implemented in a similar manner (see Import Address Table). The function pointer initially points to a thunk which tries to get the address of the associated function and write it back to the function pointer. If it fails to find the function, it instead writes the address to a fallback. As this operation is idempotent, reading and writing the pointer simply needs to be atomic. Subsequent calls to the function should be as fast as any other DLL call, as the pointer will then point directly to either the correct function or a fallback.