Windows 7 added an API set called UMS which allowed you to reclaim threads from user mode, and implement custom scheduling logic.
Starting with Windows 11 this feature does not appear to work. This issue is reflected on the official msdn page: https://learn.microsoft.com/en-us/windows/win32/procthread/user-mode-scheduling
While this seems to close the issue, this change was made by a stackoverflow user who added it because they experienced this issue on their Windows 11 machine.
You can find this conversion on another question's comment section:
UMS threads deadlocked with no error code
It is also stated on the wikipedia page for Features Removed In Windows 11 (https://en.wikipedia.org/wiki/List_of_features_removed_in_Windows_11) that UMS was removed, but the citation just links to the MSDN page.
The reason I'm suspicious is because Windows 11 is pretty new, so its possible this is just a kernel bug or unimplemented feature?
Also, this is a pretty significant feature with no replacement available. In contrast, APIs such as InterlockedExchangeAquire (https://learn.microsoft.com/en-us/previous-versions/windows/desktop/legacy/ms683594(v=vs.85)) are still supported despite being specific to IA-64 which has been discontinued.
I could not find any official statement from Microsoft about this feature's removal.
The official support statement is now in the documentation:
As of Windows 11, user-mode scheduling is not supported. All calls fail with the error ERROR_NOT_SUPPORTED.
This was added on March 15th, 2022 by Raymond Chen after it was brought to their attention, that the documentation no longer reflects reality.
Unfortunately it looks like UMS has been officially discontinued. This was confirmed to me by a Microsoft employee with access to the Windows Kernel.
This code is currently being shipped in Windows 11:
WINBASEAPI BOOL WINAPI
EnterUmsSchedulingMode(
__in PUMS_SCHEDULER_STARTUP_INFO SchedulerStartupInfo
)
{
UNREFERENCED_PARAMETER(SchedulerStartupInfo);
SetLastError(ERROR_NOT_SUPPORTED);
return FALSE;
}
While it's technically possible that this is just a temporary "hot fix" the more likely explanation according to employees who worked on the feature is that it was removed due to lack of use.
source:
https://twitter.com/itanium_guy/status/1512127881740181509
Related
E.g. I search “JetCommitTransaction”, search finds https://msdn.microsoft.com/en-us/library/gg269191(v=exchg.10).aspx which redirects to https://learn.microsoft.com/en-us/previous-versions/
That API is available in all versions of Windows starting from Win2000 to the very latest Win10, and even available for Windows 10 UWP apps, https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-esentdll so it’s not deprecated or something.
archive.org works but it's slow and inconvenient.
Microsoft is moving all documentation from msdn.microsoft.com to learn.microsoft.com so I assume this will work itself out after a while but this is the first time I have seen a completely broken redirect.
I think Google cache and Archive.org are your best options for now. You could also try contacting #docsmsft/Github issues.
We are working on moving all MSDN documentation to learn.microsoft.com. Some of the redirects were accidentally deployed early - those have been rolled back, until the migration is complete. In the meantime, the documentation is accessible on MSDN on the links you specified above.
This was pompted by a couple of recent questions where the answer amounted to "there seems to be no API for that" in both cases.
Retrieving Windows version "1511" was about retrieving the "Version 1511" string prominently displayed in the Help / About boxes of system apps from Notepad to MMC since the November update. The only proposed workaround was to read it off an undocumented registry key.
How to detect whether Windows 10 features are currently enabled in the console was about a console app detecting whether it's running under the "new" console (ForceV2=1) vs. the legacy console. An incomplete and unsatisfactory workaround (that I posted there) was to check whether the console window allows itself to be resized wider.
I would expect that there must be more cases of such new features that the published APIs haven't caught up with, yet. Examples welcome, references and known workarounds even better.
The inability to obtain a version number is entirely intentional. Both GetVersion(Ex) and VerifyVersionInfo are deprecated, although they are still available for Windows desktop apps. The use of GetVersion(Ex) is strongly discourage, and VerifyVersionInfo should really only be used for you must be this high to ride this ride checks. See this post and this one.
Universal Windows apps have access to an opaque string for logs and telemetry, but apps shouldn't be trying to display a user-visible version number. See AnalyticsInfo.VersionInfo. In short, if you are UWP you already know you are on Windows 10. If you have hard dependencies on a particular version, that is handled through AppX manifest elements.
What is the future of Windows Script Host ?
Microsoft has announced, in may 2015, the end of VBscript and ActiveX in their new browser Windows Edge (and that's a good news for web standards, by the way). However, I can't find out recent information about the desktop part of the scripting world. I'd like to know if VBscript, wscript.exe, cscript.exe and mshta.exe will still be supported by the next Windows desktop versions. I'm worried because Windows Script Host reference is, days after days, more and more difficult to find in MSDN library.
I've a lot of vbscript and hta files to maintain (in a professional environment) and I need to anticipate if a migration will soon be required.
If you have any information about that, please share !
It is on sustained maintenance so no updates (unless a major security flaw is found).
Millions of businesses use so it is safe for admin purposes. Well over half of all programmers are basic programmers.
Yes, this question still stays relevant nowadays. I also can't find any official announcement from Microsoft. They ended up with IE and AHT support years ago, but WSH stays usable. So, the answer is: there's no official end date for it, but Microsoft stimulates programmers to choose Powershell over VBScript for new applications.
Having tons of professional VBScript code running and with Powershell's leaking for easy Windows deploying and maintenance in mind, my piece of advice for you is: stuck with VBScript until you can develop a custom flawless deploying architecture for Powershell. Then, start every new project with the last, but keep the support for the former until its app's end cycle comes.
Since the above-mentioned exe files are part of both the already released Windows 11 and Windows 12 in the test state, it can be rightly assumed that sooner or later Microsoft will further develop both VBScript and the closely related HTA. Last year I read in a Microsoft blog post about Windows that the company is already working on enabling VBScript to be able to use .NET classes directly, and on updating mshta.exe, that in Windows 12 the new version can be released.
Since I myself do VBScript-HTA developments, I was also concerned about how long the company would support this. But after reading this blog post, which unfortunately I can't find now, I am no longer concerned with switching to other systems.
The fact that Microsoft has further plans for the VBScript-HTA pair is perhaps also indicated by the fact that one of the example programs of the new Visual Studio, VS 2022, which has just been released, demonstrates how to integrate a new language into the VS environment through VBScript. And also trough it is demostrated how to develop a new project template.
Where is the documentation on creating a custom Windows Credential Provider located? Everything I've found so far points to the same article on how to make a custom credential provider (MSDN Magazine: "Create Custom Login Experiences With Credential Providers For Windows Vista"), but neither that article nor anything else I can find provides documentation on how things actually work. At best there are some code samples, but those don't explain the full mechanics of credential providers or usefully show how to roll your own.
There is now a proper documentation here. It contains everything you should know when developing custom credential providers.
In an article on Windows Vista Smart Card Infrastructure, there is a link to Credential Provider Technical Reference (link to Credential Provider Technical Reference on archive.msdn.microsoft.com). The list contains a document which describes the Windows Vista Credential Provider Framework. I think you will find this technical reference quite helpful in understanding how Credential Provider in Windows works.
Hope you find what you are looking for!
In the Windows SDK, there is a Credential Provider code example in the Samples\security folder. There is also documentation (in MHTML format) for the example, contained in the SDK files. In the latest Windows SDK, the Credential Provider example has been updated to be suitable for Windows 7, says the document.
Strangely, the documentation doesn't seem to be available online anywhere. It's just there in the SDK docs.
Please note that Microsoft Windows SDK is something that you need to separately install, even if you already have Visual Studio installed.
Welcome to the beautiful world of Windows 10.
Microsoft have actually updated the documentation a tiny little bit for Windows 10, there is this page, and at the bottom, it links to the technical reference for credentail providers with updates for Windows 10. Which has (at the time of writing this) a big disclaimer at the top that it is only pre-release information and accuracy is not guaranteed. For example, at the bottom of the reference is still the e-mail address credprov#microsoft.com which has apparently been invalid for a long time already.
The most recent source code example is the open-source C# wrapper pgina which may help illustrate how to use this CredentialProvider API.
This MSMVP How-To looks pretty helpful up to Windows 7 and points you to some documentation.
And this MSDN V2 Credential Provider sample includes changes for Windows 8/8.1. Seems like a good place to start.
How do I let Microsoft know about a problem I've found in one of their core library routines? Do they have a central repository to report these things?
I am not a member of Microsoft Development Network (MSDN).
Or should I even bother?
There is no official way to report bugs to Microsoft for an end-user. If you are participating in a beta program for an upcoming release, the beta program includes a bug-reporting channel. Otherwise, if the bug causes problems that you want to get resolved, you can call Microsoft support, and they will help you solving the problem (be it by providing a patch, or a work-around); if the problem turns out to be caused by a bug indeed, they will refund the costs of the support call.
Microsoft does have a central repository (perhaps separate ones per product), but this repository is not accessible for the general public.
If it's a documentation bug (or if the documentation should call it out), you can get good results with the Feedback links in MSDN library. You can report bugs in Microsoft developer tools (among other things) by signing up at connect.microsoft.com.
If you're sure you've found a bug in a core library routine, you can raise a PSS (support case. It'll cost you money, but if it turns out you're right (and they issue you a hotfix), I think that they refund the money.
I've never been so confident that I've found a bug that I'm willing to make that gamble.
I don't know why ChrisN took back his answer. I saw it earlier today when he had it up, He said:
You can report bugs on the Microsoft Connect website (I've done this in the
past). You don't have to have an MSDN
subscription.
I had not heard of the Microsoft Connect website, but when I used the search box there to search for "Registry Unicode", the first entry listed was a bug very similar to the one I encountered. And clicking through on that entry led me to look at the conversation that appears to be Microsoft people addressing the issue, passing it on to appropriate people and escalating it as necessary.
I have no experience with the Microsoft Connect website, but if it turns out to be as promising as it appears, this may be the answer to my question.