Als u graag sleutelt aan Windows en leert terwijl u bezig bent, is het u misschien al opgevallen dat Windows-proces- en thread-ID's even zijn genummerd en veelvouden van vier. Waarom is dat? De SuperUser Q & A-post van vandaag biedt de antwoorden op de vragen van een nieuwsgierige lezer. De vraag-en-antwoordsessie van vandaag komt tot ons dankzij SuperUser - een onderdeel van Stack Exchange, een gemeenschapsgedreven groep van Q & A-websites.

De vraag

SuperUser-lezer Peter Hahndorf wil weten waarom er geen oneven genummerde Windows-proces-ID's zijn:

Er zijn veel manieren om naar de proces-ID's in Windows te kijken. PowerShell gebruiken:

Ik krijg dit resultaat:

Zoals u kunt zien, zijn alle proces-ID's even genummerd, en niet alleen dat, ze zijn allemaal veelvouden van vier. U kunt er zo uitzien als u wilt en u zult nooit een oneven nummer van het proces-ID vinden, althans niet op een versie die op Windows NT is gebaseerd. Wat is de reden hiervoor?

Waarom zijn er geen oneven nummer Windows-proces-ID's?

Het antwoord

SuperUser-bijdrager DavidPostill heeft het antwoord voor ons:

Waarom is er geen oneven genummerd Windows-proces ID's?

Dezelfde code die kernelhandles toewijst, wordt ook gebruikt om proces- en thread-ID's toe te wijzen. Omdat kernel-handles een veelvoud van vier zijn, zijn ook proces- en thread-ID's.

Waarom zijn proces- en thread-ID's veelvouden van vier?

Op Windows NT-gebaseerde besturingssystemen zijn proces- en thread-ID's altijd een veelvoud van vier. Is dit toeval? Ja, het is toeval en u moet er niet op vertrouwen, omdat het geen deel uitmaakt van het programmacontract. Windows 95-proces- en thread-ID's waren bijvoorbeeld niet altijd een veelvoud van vier. Ter vergelijking: de reden dat de kernel handelt, is altijd een veelvoud van vier, maakt deel uit van de specificatie en zal in de nabije toekomst worden gegarandeerd.

Bron:

Waarom zijn proces- en thread-ID's veelvouden van vier?

Waarom zijn kernel altijd een veelvoud van vier?

Iets dat niet zo goed is bekend is dat de onderste twee bits van kernelhandvatten altijd nul zijn; met andere woorden, hun numerieke waarde is altijd een veelvoud van vier. Merk op dat dit alleen van toepassing is op kernel-handles; het is niet van toepassing op pseudo-handles of op een ander type handvat (USER-handles, GDI-handles, multimedia-handles, enz.). Kernel-handles zijn dingen die u kunt doorgeven aan de functie CloseHandle. Dat ten minste het onderste deel van de kernel-handles altijd nul is, wordt geïmpliceerd door de GetQueuedCompletionStatus-functie, die aangeeft dat u het onderste bit van de gebeurtenishandvat kunt instellen om voltooiing te onderdrukken poortmelding. Om dit te laten werken, moet de onderste bit normaal nul zijn.

Deze informatie is niet nuttig voor de meeste schrijvers van toepassingen, die handvatten moeten blijven behandelen als ondoorzichtige waarden. De mensen die geïnteresseerd zijn in tag-bits zijn degenen die klassenbibliotheken van een laag niveau implementeren of kernel-objecten verpakken in een groter kader.

Bron:

Waarom zijn kernel altijd een veelvoud van vier?

Verder lezen

Het oude nieuwe ding: praktische ontwikkeling in de evolutie van Windows door Raymond Chen ( Principal Software Design Engineer bij Microsoft

)

Heeft u iets toe te voegen aan de uitleg? Geluid uit in de reacties. Wilt u meer antwoorden van andere technisch onderlegde Stack Exchange-gebruikers lezen? Bekijk hier de volledige discussiethread

---

Hoe u meldingen voor een Facebook-bericht ontvangt zonder er commentaar op te geven

Heeft u ooit mensen opgemerkt die in de opmerkingen van een Facebook-bericht "volgden" schreven? Ze doen dit zodat ze meldingen kunnen ontvangen wanneer de post wordt bijgewerkt, maar er is een veel eenvoudigere en efficiëntere manier om dit te doen - en het is ingebouwd in Facebook. Toegegeven, het woord "volgen" schrijven terwijl je commentaar zijn doel, maar het betekent ook dat iedereen die ook de voortgang van een bericht wil volgen, er meestal ook achter komt.

(how-to)

Optionele functies van Windows beheren vanuit PowerShell in Windows

De meeste mensen weten dat u de optionele Windows-functies kunt in- of uitschakelen via het Configuratiescherm, maar vandaag gaan we u laten zien hoe u hetzelfde kunt doen via de PowerShell-opdrachtregel in Windows 8. Beheer Windows Optionele functies van PowerShell Het eerste dat u wilt doen, is kijken welke functies u hebt ingeschakeld, hiervoor hebben we nodig om de uitvoer van de Get-WindowsOptionalFeature cmdlet door de pijplijn te laten lopen, waar deze kan worden gefilterd en geformatteerd: Get-WindowsOptionalFeature -Online | Where-Object {$ _.

(how-to)