Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Using replaceable operating system API plugins #120635

Closed
zhuxiujia opened this issue Feb 4, 2024 · 4 comments
Closed

Using replaceable operating system API plugins #120635

zhuxiujia opened this issue Feb 4, 2024 · 4 comments
Labels
C-discussion Category: Discussion or questions that doesn't represent real issues. O-windows Operating system: Windows T-libs Relevant to the library team, which will review and decide on the PR/issue.

Comments

@zhuxiujia
Copy link

zhuxiujia commented Feb 4, 2024

Currently, I see that Mutex locks on Windows using TryAcquireSRWLockExclusive and AcquireSRWLockExclusive. The former only supports Windows 7 and above, while the latter supports Windows Vista and above.

Using the APIs of both resulted in compatibility only with Windows 7 and not supporting Windows XP, Windows 2003, Windows 2008. if you want run this exe will be can't find TryAcquireSRWLockExclusive on kernel32.dll

see this example :

fn main() {
    println!("Hello, world!");
}

image

What I want to ask is why not move the API called by the operating system to a replaceable plugin, such as the toolchain toolchain in Rust, so This is more flexible, and we can build our own toolchain that is compatible with older versions of the operating system

@zhuxiujia zhuxiujia added the C-bug Category: This is a bug. label Feb 4, 2024
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Feb 4, 2024
@AngelicosPhosphoros
Copy link
Contributor

AFAIK, Rust is dropping support of Windows 8.1 soon: rust-lang/compiler-team#651

@saethlin saethlin added O-windows Operating system: Windows T-libs Relevant to the library team, which will review and decide on the PR/issue. C-discussion Category: Discussion or questions that doesn't represent real issues. and removed C-bug Category: This is a bug. labels Feb 4, 2024
@han1548772930
Copy link

Yes I agree too

@riking
Copy link

riking commented Feb 5, 2024

The rust9x and win7 targets will need to add cfg blocks to backfill compatibility on those old targets. The main Windows targets are now Win10+ only.

The win7 target has no changes to make with SRW locks, of course. You should get in contact with the rust9x mantainers.

@saethlin saethlin removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Feb 9, 2024
@ChrisDenton
Copy link
Member

Currently the only way to have different OS configurations is to add a new target (either in tree or out of tree, e.g. rust9x). Fully addressing this will require a few things to happen. RFC 3379 proposes a target_os_version config that could be used to select different function for different versions. However, std is prebuilt for each target so won't be able to make use of it on its own. The build-std project goal hopes to address that.

So closing this in favour of those efforts.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
C-discussion Category: Discussion or questions that doesn't represent real issues. O-windows Operating system: Windows T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants