2013-08-16 5 views
19

Su WinAPI, il tipo HANDLE è definito come void*, pertanto su un'applicazione a 64 bit il valore HANDLE può variare da 0 a 18446744073709551615. Ma è vero nella pratica? Qualche documentazione specifica l'intervallo integrale di tale HANDLE?Qual è l'intervallo di un HANDLE di Windows su un'applicazione a 64 bit?

Se ad esempio si desidera archiviare questo HANDLE come in un'applicazione a 32 bit è tutto a posto, ma su un'applicazione a 64 bit i dubbi rimangono.

+2

_perché_ fare il necessario per memorizzare un 'ansa di in un' int'? Sembra problematico. Si consideri un 'std :: map '. – MSalters

+0

@MSalters Questo è correlato ai descrittori di file POSIX (che sono 'int'). Sto usando C, quindi nessun STL, ma sì, potrei creare un secondo sistema di handle che punta a un 'HANDLE' di Windows, ma sarebbe più lento di un cast semplice, quindi sono qui a chiedere. – thelink2012

risposta

19

MSDN afferma:

versioni

64-bit di Windows a 32 bit utilizzano maniglie per l'interoperabilità. Quando si condivide un handle tra applicazioni a 32 bit e 64 bit, solo i 32 bit inferiori a sono significativi, quindi è sicuro troncare il handle (quando lo si passa da 64 a 32 bit) o ​​firmare l'estensione il manico (quando lo si passa da 32-bit a 64-bit). Le maniglie che possono essere condivise includono gli handle per gli oggetti utente come HWND, gli handle per gli oggetti GDI come penne e pennelli (HBRUSH e HPEN) e le maniglie per oggetti denominati come mutex, semafori e handle di file.

È anche interessante notare questo commento aggiunto su quella pagina:

Il modo corretto per condividere tali maniglie di tutti i limiti di processo è di estendono a zero 32 bit maniglie a 64 bit, o viceversa di troncamento 64 bit gestisce a 32 bit scartando i bit superiori.

Si noti la distinzione tra "estendere il segno" un handle rispetto a "estendere zero" un handle.

Edit: A giudicare dalla discussione visto in una risposta cancellato a questa domanda, suppongo che il significato del segno-estensione di una maniglia a 32 bit per arrivare a un 64-bit gestire invece di zero-estendendolo è quello di mantenere un trattamento adeguato del valore INVALID_HANDLE_VALUE per un handle.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa384203%28v=vs.85%29.aspx

+1

Il commento su cui si basa non ha autorità. Segui la documentazione. –

+1

Inoltre, hai abbastanza reputazione per vedere la risposta più votata in questa pagina (la cui eliminazione è discutibile) che riguardava questo, e dove anche MSalters ha partecipato ai commenti. –

+1

@BenVoigt Attualmente non ho questa capacità di vedere la risposta cancellata * (fantastico, non lo sapevo) * ma era la risposta accettata prima che fosse cancellata, qualche ideia per la ragione? Sui commenti forse? Per curiosità, l'undelete è possibile se l'autore lo desidera? – thelink2012

2

Mi piacerebbe sapere dove è documentato, ma un mio collega insiste che le maniglie HWND a 64 bit si adattano sempre a 32 bit. Non ho mai visto un caso in cui non sia vero, ma non posso parlare al futuro o dove è documentato. Riguardo ad altre maniglie come dire, HTREEITEM .... Sono piene 64-bit e sono stato un po 'supponendo che anche loro si adattano a 32 bit.

+1

"Un mio collega" non è una fonte affidabile di informazioni, specialmente considerando la documentazione ufficiale (vedi risposta accettata) in disaccordo. –

+0

@BoundaryImposition, Joe Willcoxson è corretto. Gli HTREEITEM dal processo a 64 bit possono essere molto più grandi di 32 bit. Questo è indicato anche nei documenti Microsoft, in particolare che gli handle per gli oggetti del sistema operativo saranno a 32 bit e per firmare l'estensione, ma ciò non include altri tipi di handle come HTREEITEM.Forse il suo collega lavora per Microsoft. +1 per lui menzionando questo aspetto molto utile. Ne sto fissando una che tronca 3 bocconcini del manico tramite SendMessage in un processo a 64 bit proprio ora. – Celess

+0

@Joe Willcoxson Interoperabilità a 32 bit e 64 bit (MSDN): https://msdn.microsoft.com/en-us/library/windows/desktop/ee872017(v=vs.85).aspx – Celess

Problemi correlati