[cdimauro]

Originariamente inviato da gugoXX

Ma, sinceramente volevo provare a vedere se sarei riuscito a tirare fuori quello che serviva al nostro amico all'inizio, ovvero
-Frequenza CPU, nome CPU, Frequenza BUS e temperature.
I primi sono li', ma sono anche poi riuscito a tirare fuori la temperatura.

Mumble. Per il nome della CPU OK, ma per frequenza e bus non so se sono quelli fissi (rilevati alla partenza del s.o.) oppure calcolati dinamicamente.

Considerato lo scopo del progetto (che è orientato per gli overclocker), propenderei per la seconda, ma bisogna vedere, appunto, cosa viene restituito dalle classi WMI.

Comunque non e' una libreria generica.
E' l'incapsulamento di tutta la WMI messa a disposizione per .net, direttamente dalla Microsoft.
E' davvero immensa, penso che in qualche modo abbiano anche portato fuori le informazioni della CPUID, ma non ne sono sicuro.

Fra le sole Win32_Classes c'e' da sbizzarrirsi. Riporto qui un elenco
http://msdn2.microsoft.com/en-us/lib...84(VS.85).aspx

Ho fatto qualche ricerca, ma non ho trovato nulla su Win32_Classes e CPUID. Ho recuperato questa http://msdn2.microsoft.com/en-us/lib...73(VS.85).aspx ma parla di CPUID soltanto per quanto riguarda il tipo di processore:

ProcessorId
Data type: string
Access type: Read-only

Processor information that describes the processor features. For an x86 class CPU, the field format depends on the processor support of the CPUID instruction. If the instruction is supported, the property contains 2 (two) DWORD formatted values. The first is an offset of 08h-0Bh, which is the EAX value that a CPUID instruction returns with input EAX set to 1. The second is an offset of 0Ch-0Fh, which is the EDX value that the instruction returns. Only the first two bytes of the property are significant and contain the contents of the DX register at CPU reset—all others are set to 0 (zero), and the contents are in DWORD format.

Ce ne sono anche tante altre. La temperatura (in decimi di Kelvin!!) l'ho trovata qui dentro, in mezzo ad altre cose.
root\WMI MSAcpi_ThermalZoneTemperature
I valori non sono tutti in sola lettura. Per esempio ho potuto cambiare la frequenza di campionamento della temperatura. Non mi ha dato errore, ma non ho controllato se e' stata recepita.
Ovviamente la tua utenza deve avere i privilegi per farlo, tipicamente administrator.

Sì, dipende dalle informazioni a cui vuoi accedere e/o modificare. Per la CPUID non ce n'è bisogno: con un account limitato viene eseguita senza problemi.

Se vuoi provare a leggere la WMI direttamente in Python con l'SDK puoi farlo, ma non so se e' altrettanto agevole.
Le classi bisogna scriverle almeno una volta, e io non l'ho dovuto fare perche' erano gia' tutte belle pronte.

Ma non sono classi .NET? Se è così, dovrebbero essere accessibili senza problemi da IronPython...

Comunque per la sola CPUID e' chiaro che il programma e' una palla, il 90% delle tue righe erano solo la descrizione di ciascuno dei bit.

Esattamente. Ma volevo spedire in output qualcosa di umanamente comprensibile...

Se proprio dovessi eseguirla prenderei la strada con il minimo sforzo.
Poiche' in .net posso linkare progetti che arrivano da diversi linguaggi, nella soluzione aggiungerei semplicemente un progetto C++, con una sola funzione, il cui corpo sarebbe

public int getCPUID()
{
  int ret;
  __asm{
      mov eax, 1
      cpuid
      mov ret, eax
  }
  return ret;
}

Dovrebbe funzionare anche al di fuori del ring0, ma mi riservo di provare.

Sì, funziona, ma per le altre istruzioni, tipo quelle per accedere ai machine register, serve essere in ring0.

Comunque l'approccio di cui sopra ti costringerebbe comunque a doverti scrivere un driver per poter lavorare in ring0 e accedere a tutte le informazioni che ti servono.

Considerato che la libreria che ho usato fa già tutto, sarebbe come reinventarsi la ruota...

Tra l'altro ha driver certificati MS e funziona su qualunque versione di Windows, anche x64 (io l'ho provata con Python a 32 bit su Vista x64 con utenza limitata).

In C# poi, per trasformare l'intero nei singoli bit userei semplicemente:

BitArray ba = new BitArray(BitConverter.GetBytes(fromCPUID));

Da li' si tratterebbe solo di stampare le stringhe pallosissimamente messe.

Certamente.

Originariamente inviato da fek

E meno leggibile.
Piu' corto non vuol dire migliore, piu' leggibile e piu' mantenibile. Meno punti funzionali vuol dire (generalmente) piu' semplice, non meno caratteri.

Ma io avevo scritto questo:

simile (e corto)

in risposta a questo:

quanto codice

che aveva scritto gugoXX.

Volevo semplicemente sottolineare che con IronPython non ci sarebbero state sostanziali differenze (ho parlato di codice "simile", infatti), e visto che il codice di gugoXX è corto, sarebbe stato corto anche quello con IP.

Non ho parlato di codice più o meno corto né tanto meno di maggior o minor leggibilità.

Tu invece stai ipotizzando che sarebbe meno leggibile, senza nemmeno averlo visto.

Possibilissimo (conoscendomi ), ma chi ti dice che non venga fuori un codice almeno leggibile quanto quello in C# (sarebbe sufficiente "ricalcare" la struttura di quello in C#)?

Secondo me in molti esempi di Python che ti ho visto scrivere fai un errore: ti fai prendere dallo scrivere "cute code" sfruttando caratteristiche del linguaggio. E questo e' sbagliato. Io spesso non capisco a prima vista il codice che riporti in Python, lo devo rileggere, poi andarmi a guardare quello che scrivi e cercare la caratteristica del linguaggio che hai usato.

Al contrario, spesso, io faccio leggere il mio codice ad un artista e se mi dice che non capisce quello che sto facendo, quando ho tempo, lo riscrivo in maniera piu' chiara.

Le caratteristiche del linguaggio vanno usate per scrivere codice piu' chiaro e leggibile, non perche' fa figo.

E ora per cortesia non riportarmi un paio di righe di Python dicendo "a me sembrano chiare", perche' nove su dieci lo sembrano solo a te e a chi conosce bene Python

Lo so, e infatti ho cercato di scrivere un codice che fosse più leggibile anche per gli altri.

Ad esempio questa:

def BitSetToStringList(Value, Names):
  List = []
  for Name in Names:
    if Name and (Value & 1):
      List.append(Name)
    Value >>= 1
  return List

l'avrei potuta scrivere usando una list comprehension in una sola (complessa) riga , ma poi saresti sceso da Guildford con la mazza ferrata di Zio Paperone per prendermi a randellate...

Questa mi sembra invece piuttosto leggibile per chiunque, no?

Comunque rivedendo il sorgente che avevo postato mi sono reso conto che utilizzando una variabile "intermedia" per memorizzare il risultato di una list comprehension, il codice diverrebbe più leggibile. Ad esempio questo:

def c_intToStr(Value):
  return ''.join(chr((Value >> Shift) & 255) for Shift in (0, 8, 16, 24))

si potrebbe scrivere così:

def c_intToStr(Value):
  Characters = (chr((Value >> Shift) & 255) for Shift in (0, 8, 16, 24))
  return ''.join(Characters)

Usando una funzione di supporto verrebbe ancora meglio:

def c_intToStr(Value):

  def ConvertByteToCharacter(Shift):
    return chr((Value >> Shift) & 255)

  Characters = (ConvertByteToCharacter(Shift) for Shift in (0, 8, 16, 24))
  return ''.join(Characters)

Dipende tutto da quello che si vuole ottenere...

Originariamente inviato da cionci

Scusa, ma se la libreria che legge quello che serve al nostro amico non esiste...se la scrive da solo ? Per questo ho consigliato C#, perché con un solo strumento può fare tutto ciò che gli serve. Al contrario con Python dovrebbe impararsi a scrivere la libreria in C# o C++ e poi usarla con Python. Hai capito ora cosa intendo ?

A parte il fatto che con IronPython, che è un linguaggio .NET, si potrebbe fare lo stesso tutto, visto che può benissimo "consumare" tutte le classi messe a disposizione dal framework oppure altre "esterne", per quello che deve farci http://www.hwupgrade.it/forum/showpo...92&postcount=1 http://www.hwupgrade.it/forum/showthread.php?p=21295820 "Mazda" (visto che dovremmo rimanere in topic, no? ) non ha certo bisogno di andare a scriversi dei driver, come gli era stato suggerito in precedenza.

Quella di andare a smanettare con l'hardware è un'esigenza vecchia quanto il cucco, e da "secoli" sono disponibili soluzioni (come quella che ho impiegato): basta cercarle e usarle.

Fino a Windows ME era possibile accedere direttamente all'hardware, ma con Windows NT, e in ogni caso da Windows 2000 in poi, ciò non è più possibile e bisogna necessariamente ricorrere a un driver e/o libreria. Che qualcuno, appunto, ha scritto.

Rimane semplicemente da interfacciarvisi, e ho postato un esempio con Python che dimostra quanto ciò sia semplice. O non sei d'accordo?
Stessa cosa si può fare con C++ o C#, di cui il pacchetto fornisce include / namespace ed esempi (molto più facile: io ho dovuto scrivermi tutto da zero, anche se ho impiegato pochissimo ).

Non vedo quale sia il problema, quindi.

Questo, ripeto, non volendo considerare come soluzione IronPython, ma semplicemente Python.

Originariamente inviato da wizard1993

scusate l'intromissione, sono perfettamente d'accordo con te cionci. non ha senso in python dover utilizzare una libreria in c++, a quel punto si usa la piattaforma .net
io modificherei l'affermazione di cdimauro così:"In python, we often trust"

Vedi sopra: per .NET c'è IronPython che può "consumare" qualunque classe scritta per questo framework.

Tra l'altro se il framework .NET non permette di accedere a tutte le informazioni necessarie (e finora mi sembra che alcune manchino), giocoforza anche con C# sarà necessario rivolgersi a una libreria come quella che ho usato, oppure reinventarsi la ruota appoggiandosi a C++/CLR per realizzare le API / classi necessarie.

Nessuna differenza con C#, quindi.

Mah. Mi sembra una polemica inutile...