Indeed. Anything documented has a function wrapper. `NtCreateFile` is a function wrapper for the syscall number, so any user-mode code that has `NtCreateFile` instead of directly loading the syscall number 0x55 will be stable. The latter might not. In fact, it is not; the number has increased by 3 since Windows XP[1].
One could probably produce some sort of function pointer loader library with these tables, but at that point... Why not just use the documented APIs?
Only Malware uses the system call numbers directly. Using the system call numbers directly is foolish if they're going to change and break your app. Just import and call a function that will perform the actual SYSENTER (or WOW64 context change).
NTDLL should be stable since it's well documented, and many functions redirect to Ntoskrnl.exe, and things like kernel level drivers call those functions. Those functions won't change without the drivers breaking.
Then there's "Win32u.dll". These correspond to API calls from User32.dll, Gdi32.dll, etc. This DLL didn't even exist during the Windows 2000-XP era. This stuff is not well documented, and I don't know if this is stable.
Yeah, I had this problem when shipping go binaries on Windows. Antivirus vendors really do not care that your program regularly shows up as a false positive due to their crappy heuristics, even if you have millions of users.
It was really bad a couple years ago because anything wrapped in Inno Setup kept being flagged. Now maybe one or two flag vendors do; Bkav Pro and CrowdStrike Falcon are the dominate culprits always.
Apparently there's changes to boot that are more or less understood, but require some heavy work to handle.
Basically starting with M4 you have a choice between starting with Apple's page table monitor already running in their guarded mode extension, or all apple extensions disabled on the CPU cores.
I don't think chiplets require or even are even generally seen with silicon backplanes yet, otherwise you'd be leaving out stuff like AMD's CPUs.
And from there, stuff like the Vac 9000's packaging were very advanced for the time designs that I'd hesitate to call PCBs unless we're calling all organic packaging PCBs now.
Humphrey Davy, the British chemist who performed early work to isolate the element, and who initially named it, called it 'aluminum'. Americans mostly followed him, but the British changed later at the complaints of the French, Swedish, and Germans that it used essentially English roots rather than Latin ones. Which, considering that we now have elements named such things as Tennessine, seems to be a bit of an argument that doesn't quite apply anymore.
The suffix "-io-", which becomes "-ium" in accusative/nominative neuter Latin nouns, is extremely ancient. It is inherited from the common Indo-European language.
This suffix is used to derive nouns or adjectives from other nouns, where the derived nouns are understood to have some kind of relationship with the base nouns.
A great number of the names of chemical elements use the Latin variant of this suffix, i.e. "-ium", to derive the name of the element either from the name of the substance from which it has been extracted, or from the name of some characteristic property of the element or from some mythological name or from some person or place that is intended to be honored by this choice.
The name of aluminium comes from the name of the aluminium sulfate in Latin, which was "alumin-".
So "aluminium" means "something that is not aluminium sulfate, but it is related to aluminium sulfate".
On the other hand, "aluminum", which lacks the derivation suffix, just means "aluminium sulfate" (which has become "alum" in English), but the noun has been converted from the 3rd Latin declension to the 2nd Latin declension. Such conversion between declensions were not unusual even for native Latin speakers.
So this is definitely a grammar mistake, which is annoying for those who understand the meaning of words, because it creates an exception that must be remembered, instead of applying the general rule.
In general the British and American scientists have always been much more lax in observing grammar rules than the continental Europeans. So there are also other chemical elements where the English names differ from the correct names. For instance the name of the chemical element "silicium" is derived from Latin "silic-" (flint), from which it is extracted, but in English it has been changed to "silicon", for the silly reason to make it rhyme with "carbon", despite the fact that most chemical properties of silicon resemble more those of boron or of phosphorus or of germanium, than those of carbon (because valence is only 1 of the 3 main properties that determine chemical behavior, electronegativity and ionic/atomic size are equally important). (Carbon is one of the few elements that were known in pure form already in the Ancient World, so its name is not derived from another noun.) ("Boron" has also been changed in English to make it rhyme with "carbon", which is equally baseless.)
Except Davy said he named it after platinum, except with an alum- prefix instead of the silver plat- prefix, as it was to be considered a new precious metal out of what had previously just been considered impurities like platinum relatively contemporaneously had.
To be fair, those sensitive secrets included secret, unconstitutional, dragnet surveillance programs targeting american citizens, and the fact that the director of national intelligence had perjured himself during congressional hearings on those programs.
Less than 1% of what Snowden took and leaked pertained to domestic surveillance programs, The rest was intelligence capabilities and sources and methods.
But that's besides the point. There is a real argument that the U.S. government, in trying to catch Snowden, was protecting national security. There is no such argument with Trump.
No, it was retribution. The info was already out there when they were going after him. Even if he stayed in the US and was captured, it still wouldn't have "stopped" anything.
> The info was already out there when they were going after him.
This was of course not known at the time. The only thing that was known is that a single individual was responsible for the greatest breach of classified secrets in the nation's history, and that individual was still at large.
How does that change or affect the point I'm making?
> This was of course not known at the time. The only thing that was known is that a single individual was responsible for the greatest breach of classified secrets in the nation's history, and that individual was still at large.
If Snowden hasn't moved quickly, he wouldn't have been able to leak any of it.
What he did, grab it all, then give it to reputable journalists, was the correct option to be able to inform the public of massive intelligence dragnets targeting civilians that the government was lying about.
> If Snowden hasn't moved quickly, he wouldn't have been able to leak any of it.
How does stealings sensitive materials not related to domestic surveillance improve his odds of successfully leaking information and fleeing the country?
> That's been made clear pretty much from the very beginning, that nobody is forced to suddenly have to learn a new language, and that people who want to work purely on the C side can very much continue to do so.
If any C developer developed drivers in C previously for the DRM subsystem, they might in the future be forced to learn Rust.
You're confusing the audience here. That's directed at subsystem maintainers, not just 'anyone who wants to submit a patch'. If a subsystem doesn't want to deal with Rust code, they won't be forced to. But there's no restriction on the inverse.
Whether that's true or false depends on what your hypothetical developer wants to do in the future. When an all-new driver is written in Rust, then working on that driver will require knowing Rust. But nobody's talking about trying to re-write all the existing drivers in Rust, so there will still be plenty of C code to work on even in the DRM subsystem.
That means that, even if a C developer used or added C bindings to DRM when wanting to write a new driver, they would be forced to write their new driver in Rust regardless. That seems to run counter to the promises made by Linus.
reply