Questão Por que não há IDs de processo do Windows estranhos?


Há muitas maneiras de examinar as identificações de processo no Windows.

Por exemplo, usando o comando do PowerShell:

ps | select Id, ProcessName  | Sort Id | ft -AutoSize

Nós vemos a seguinte saída:

  Id ProcessName         
  -- -----------         
   0 Idle                
   4 System              
 264 svchost             
 388 smss                
 476 csrss               
 536 wininit             
 580 winlogon                      
 620 services            
 628 lsass                          
 728 svchost             
 828 dwm                                     
1060 chrome              
1080 rundll32            
1148 vmms                                        
1620 spoolsv                                                
2912 taskhostex          
3020 explorer       
...     

Todos os IDs de processo são números pares e, além disso, são todos múltiplos de 4.

Não existem IDs de processo ímpares em qualquer versão do Windows baseada no Windows NT.

Qual é a razão para isto?


158


origem


Possivelmente interessante: Some detaila about linux - justskins.com/forums/why-are-process-ids-204416.html - Dave
Na verdade não há nenhum. Isso é estranho. - AndreKR


Respostas:


"Por que não existem IDs de processos do Windows?"

O mesmo código que aloca as alças do kernel também é usado para   aloca IDs de processo e encadeamento. Como as alças do kernel são múltiplas   de quatro, também são IDs de processo e encadeamento.


Por que os IDs de processo e encadeamento são múltiplos de quatro?

Em sistemas operacionais baseados no Windows NT, processos e identificadores de segmento acontecem   sempre para ser um múltiplo de quatro. Isso é apenas uma coincidência?

Sim, é apenas uma coincidência, e você não deve confiar nisso, pois é   não faz parte do contrato de programação. Por exemplo, o processo do Windows 95   e os IDs de encadeamento não eram sempre múltiplos de quatro. (Por comparação, o   razão que identificadores de kernel são sempre um múltiplo de quatro é parte de   a especificação e será garantido para o futuro previsível.)

IDs de processo e encadeamento são múltiplos de quatro como efeito colateral do código   reuso. O mesmo código que aloca as alças do kernel também é usado para   aloca IDs de processo e encadeamento. Como as alças do kernel são múltiplas   de quatro, também são IDs de processo e encadeamento. Esta é uma implementação   detalhe, por isso não escreva código que se baseia nele. Eu só estou dizendo para você   satisfaz sua curiosidade.

Fonte Por que os IDs de processo e encadeamento são múltiplos de quatro?


Por que os HANDLEs do kernel são sempre múltiplos de quatro?

Não muito bem conhecido é que os dois bits inferiores de HANDLEs do kernel são   sempre zero; em outras palavras, seu valor numérico é sempre um múltiplo   de 4. Observe que isso se aplica somente aos HANDLEs do kernel; não se aplica   para pseudo-alças ou para qualquer outro tipo de identificador (identificadores USER, GDI   alças, alças de multimídia ...) Alças do kernel são coisas que você pode passar   para a função CloseHandle.

A disponibilidade dos dois bits inferiores está enterrada no ntdef.h   arquivo de cabeçalho:

//
// Low order two bits of a handle are ignored by the system and available
// for use by application code as tag bits.  The remaining bits are opaque
// and used to store a serial number and table index.
//

#define OBJ_HANDLE_TAGBITS  0x00000003L

Que pelo menos a parte inferior dos HANDLEs do kernel seja sempre zero é   implícita pela função GetQueuedCompletionStatus, que indica   que você pode definir o bit inferior do identificador de evento para suprimir   notificação de porta de conclusão. Para que isso funcione, a parte inferior   bit normalmente deve ser zero.

Esta informação não é útil para a maioria dos escritores de aplicativos, que   deve continuar a tratar os HANDLEs como valores opacos. As pessoas que   estaria interessado em tag bits são aqueles que estão implementando   bibliotecas de classe de baixo nível ou estão envolvendo objetos do kernel dentro de um   estrutura maior.

Fonte Por que os HANDLEs do kernel são sempre múltiplos de quatro?


Leitura adicional



166



Uma citação diz "você não deve confiar nele, pois não faz parte do contrato de programação" mas então as próximas reivindicações ntdef.h diz que os bits são "disponível para uso pelo código do aplicativo como bits de tags."  A documentação em um arquivo de cabeçalho público é o mais próximo de um "contrato de programação" como você pode obter, a primeira reclamação está incorreta. - BlueRaja - Danny Pflughoeft
@BlueRaja, "Não muito bem conhecido é que os dois bits inferiores HANDLEs do kernel são sempre zero; Em outras palavras, seu valor numérico é sempre um múltiplo de 4."O código em ntdef.h também se aplica a outros tipos de alças (identificadores USER, identificadores GDI, manipuladores de multimídia ...) - DavidPostill♦
@BlueRaja: identificadores de kernel são múltiplos de quatro e isso é contratual, então você pode confiar nele; ids de processo (que são não o mesmo que alças de processo), em vez disso, acontecer ser múltiplo de quatro, mas isso é apenas um detalhe de implementação, então você não deve confiar nele. - Matteo Italia
@BlueRaja Eu acho que Raymond diria a você que quem escreveu a documentação olhou para o mundo através de vidros coloridos e, portanto, referiam-se apenas às alças do kernel e não a outros tipos de alças. - CodesInChaos
@ Mehrdad: bem, as alças USER e GDI não são normalmente chamadas de alças "kernel" (embora sejam geradas por componentes em execução no chamado modo kernel). - Matteo Italia