Newsgroup: it.comp.programmare.win32
Titolo: Info su CreateToolhelp32Snapshot

Sto provando ad utilizzare l'api CreateToolhelp32Snapshot su Win NT 
workstation ma al momento dell'esecuzione del mio progettino VC++ mi viene 
fuori l'errore:
"Impossibile trovare il punto di ingresso CreateTollhelp32Snapshot della 
procedura nella libreria a collegamento dinamico KERNEL32.dll"
Nel mio progetto non faccio inclusioni o import.
Può trattarsi di un mio problema di inclusione o di import della suddetta 
Kernel32.dll?
Se si come posso risolverlo?
     Grazie a tutti
          Massimo
------------------------------------------------------------
 Get your FREE web-based e-mail and newsgroup access at:
 
http://MailAndNews.com
 Create a new mailbox, or access your existing IMAP4 or
 POP3 mailbox from anywhere with just a web browser.
------------------------------------------------------------


La funzione CreateToolhelp32Snapshot è supportata solo su Windows 95 e su 
Windows 2000.
Su NT devi utilizzare le funzioni di PSAPI (non supportate però da '95).
Windows 2000 supporta entrambi i set di API (dopo aver "partorito" due set 
di API incompatibili tra loro, microsoft ha deciso di supportarli entrambi, 
credo per facilitare la "migrazione" da 9X/ME a 2000/XP), ma credo sia 
preferibile utilizzare comunque PSAPI su tutti i sistemi NT-derivati.
-- 
Valter Minute
min...@inwind.it
 (the reply address of this message is invalid)


min...@inwind.it
 (the reply address of this message is invalid)
------------------------------------------------------------



Dovresti partire da EnumProcesses per ricavare l'elenco dei processi attivi 
e poi ricavare le info relative ad ogni processo.
P.S. su NT (e 2000) è possibile ricavare le informazioni sui processi dalla 
chiave HKEY_PERFORMANCE_DATA  del registry. In questo modo è possibile 
ricavare parecchie informazioni (quelle visualizzate dal Performance 
monitor), ma le modalità di accesso a queste informazioni sono più 
complesse rispetto a quelle messe a disposizione da PSAPI.
Su MDSN (
msdn.microsoft.com
, per la versione on-line) troverai tutte le 
info che ti servono. Su 
www.codeproject.com
 ci dovrebbero essere alcuni 
esempi.


complesse rispetto a quelle messe a disposizione da PSAPI.
e necessarie.... xche' in NT 4.x (non parliamo poi x Nt 3.5x) se si
vuole restare ai metodi documentati (si fa per dire considerando la
qualità della documentazione in merito..), ma contemporaneamente si
vogliono avere informazioni relative f.e ai threads la PSAPI e'
insufficente... ora ihmo questo e' uno di quei casi in cui si puo'
ricorrere alle vie undocumented e nella fattispecie le native API
Nt/ZwQuerySystemInformation (sostanzialmente la classe
SystemProcessAndThreadsInformation) ed  Nt/ZwQueryProcessInformation
(f.e. classi ProcessBasicInformation,ProcessTimes,etc..) ..
sicuramente qualcuno obbiettera' che le soluzioni undoc non sono
compatibili/portabili/bla bla...ma come al solito lo inviterei a dare
un'occhiata a come  sono implementate le PSAPI, ToolHelp32 API, il
task manager etc.. M$ stessa, anche se non ufficialmente, riconosce la
necessita' di utilizzare la c.d. Query API (laggasi articoli i Pietrek
su MDSN, etc..) ...
concludendo imho per questo genere di situazioni utilizzerei qualche
DLL wrapper che incapsuli la TooHelp32 api e delle Query api
(scavalcando quindi la PSAPI..) magari esponendo un'interfaccia
coerente alle prime 
Saluti,
 Walker Boh

insufficente... 
Questo è vero, ma se mi devo limitare ad elencare i processi per vedere, ad 
esempio, se un processo è attivo oppure cercare la sua finestra principale 
(e credo che questa casistica copra un buon 90% dell'uso di ToolHelp32 su 
9X), le PSAPI sono sufficienti (nel messaggio originale non si specificava 
lo scopo per cui si utilizzava CreateToolHelpSnapshot).
P.S. Le info sui thread non possono essere recuperate anche attraverso il 
"performance registry"? 


 Walker Boh
------------------------------------------------------------


"performance registry"? 
yup.. index = 232 ecc... ma ancora: la questione e' che questi dati
non sono prelevati dal registry.. ma sono delle snapshot che
"casualmente" utilizzano Nt/ZwQuerySystemInformation e
Nt/ZwQueryProcessInformation... quindi imho tutto ci riporta al punto
di partenza, ovvero che M$ farebbe bene, una volta per tutte, a
ducumentarle anche per chi non sviluppa drivers ed evitare di
nascondersi dietro un dito..
Saluti,
  Walker Boh

altre funzioni di cui parli?
i perf counters sono strutturati come una serie di struct i cui
elementi (a loro volta delle struc) sono indicizzati o referenziati
attraverso offset.. per leggerli e' sufficente (si fa per dire =)
utilizzare RegQueryValueEx.. (x headers , struct ed index fai
rifermento a winperf.h dell' NT SDK oppure online sul sito M$)
Tuttavia come dicevo a V. Minute io lascerei perdere i perf counters
ed andrei direttamente alla fonte: la query api!
Quanto a questa.. dunque.. documentazione: un testo che ho ricevuto di
recente, ma che oramai utilizzo come ref e' "Windows 2000 Natvie
Api.." di G. Nebbett.. ma oramai esempi li trovi un po' ovunque..
basta qualche search su Deja o dai un'occhiata agli archivi di MSJ e
WDJ o Sysinternals.. se proprio non trovi nulla (ma dubito!!) ti mando
gli headers via mail. 
Saluti,
    Walker Boh


Sono d'accordo al 100% con te su questo punto. Credo perň che sia un buon 
sistema di programmazione "difensiva" evitare di appoggiarsi a API 
undocumented quando c'č un'alternativa documentata (anche, nel caso del 
performance registry, piů incasinata da utilizzare...). Qualcuno che ha 
fatto affidamento su "BozoLivesHere" in Windows 3.1 potrebbe essersene 
amaramente pentito con la release di 95 :)


amaramente pentito con la release di 95 :)
gia' gia' =) .. pero' ammetterai che in ambiente win32 la
compatibilita' cross version e' utopica .. molte API risultano
"broken" anche solo fra SP o nelle cd. intermediate version  =)
nel caso specifico ritengo che le query api resteranno fra noi per
molto tempo almeno x quello che riguarda le info class principali.. e
non solo xche' indispensabili x i drivers devs x avere a KM
informazioni altrimenti ottenibili solo in UM, ma per tante altre API
che altrimenti dovrebbero diventare al loro volta "broken"
My 2 cents, 
          Walker Boh