Win 7 [Thread Generale] Rilasciata ISO del SP1 (7601.17514.101119-1850)

[KamiG]

Originariamente inviato da @ndrey

Con Skype tutto ok.. (xro non installo i loro plugin)

Era a questo che ti riferivi?

http://blog.merlinox.com/rimuovere-skypepm-ram/

In effetti dal taskmanager vedevo il processo SkypePM.exe sempre attivo con una grossa occupazione di cpu... cancellata la directory Plugin Manager è tutta un'altra cosa. Non mi spiego però perchè su XP (testo or ora in dual boot) il processo, seppure pesante, non impalli il pc.

[KamiG]

Originariamente inviato da john18

Quanto scritto in alto...

ok, scusami ma a scuola ero un maniaco dei bignami

[nitroin]

Originariamente inviato da @ndrey

Max Clear modificato da me
http://molinarosp.deviantart.com/art...-7RC-122606353

Rainmeter con il tema Enigma
http://code.google.com/p/rainmeter/
http://kaelri.deviantart.com/art/Enigma-103823591

Icone varie da DeviantArt
http://browse.deviantart.com/customi...icons&order=24

Grazie!

[rеpne scasb]

Originariamente inviato da raffounz

Anche io ho una configurazione uguale a casa, tranne per l'Athlon che è un 900Mhz, la ram che è 512 e la video che è una GeForce GTS 2 32MB... facci sapere del tuo test...

Nulla non si installa. In fase di boot ottengo l'errore: CDBOOT: Cannot boot from CD - Code: 5
Invalid partition table

Sembrerebbe un errore tipico quanto comune, che impedisce l'installazione di Windows 7 su hardware particolarmente obsoleti.

Addendum: nuovo test fatto su ECS K7S5A Pro Rev 5.0 - Athlon XP 2400+ - 1Gb RAM DDR - Ati Radeon 9600 Pro - HDD Maxtor 250Gb IDE - DVD-RW Pioneer: stesso identico errore.

[@ndrey]

John.., OS Windows x64 è piu pesante del x86.. Io parlo di pesantezza e non di accelerazione e non solo di GB di spazio. Perche con un Athlon 64 c'e poco da accelerare, non credo proprio che vai ad utilizzare varie encoder/converter, virtualizzazioni ecc..
.. Alla fine della fiera os a 32bit risulta piu legero per qst tipo di PC.
64bit ha necessita di più risorse e ti accorgi fortemente su pc poco potenti via via che lo usi.
PS. Che senso ha usare varie vLite/nLite per alleggerire l’os, visto che abbiamo vista/7 a 64?!

[@ndrey]

Originariamente inviato da john18

Come dicevo ho fatto il test su sistema appena installato quindi addirittura più pulito della controparte a 64 bit.


http://www.xtremeshack.com/scheda/27...mark7.PNG.html

Ora vi posto quello su sistema a 64 bit che si è perso tra i vari post.

http://italianhost.org/imagehost/pic...5a6ba353fe.PNG

Come potete vedere i 64 bit permettono di sfruttare al massimo la potenza di un athlon64,vecchio o nuovo che sia.

Cambia ben poco in qst test.. vince e perde a secondo..

[john18]

Originariamente inviato da @ndrey

John.., OS Windows x64 è piu pesante del x86.. Io parlo di pesantezza e non di accelerazione e non solo di GB di spazio. Perche con un Athlon 64 c'e poco da accelerare, non credo proprio che vai ad utilizzare varie encoder/converter, virtualizzazioni ecc..
.. Alla fine della fiera os a 32bit risulta piu legero per qst tipo di PC.
64bit ha necessita di più risorse e ti accorgi fortemente su pc poco potenti via via che lo usi.
PS. Che senso ha usare varie vLite/nLite per alleggerire l’os, visto che abbiamo vista/7 a 64?!

Nel frattempo ho aggiornato con il test dei 64 bit...Ah bhè con un athlon64 dualcore quindi non acceleri niente.

@ndrey non capisco sinceramente perchè ostinarsi in questo modo nonostante aldilà dei punti di vista c'è un insieme di regole ben precise che non puoi inventare di testa tua.

Un athlon64 3000+ guadagna al passaggio ai 64 e tanto più guadagna anche un athlon64 dualcore.

Specialmente in ambiti come conversione video,compressione di file,e via dicendo.


Mettitelo nella zucca!

[john18]

Originariamente inviato da @ndrey

Cambia ben poco in qst test.. vince e perde a secondo..

A parte che devi guardare il risultato totale,c'è un test solo dove perde ma devo capire perchè.

[@ndrey]

Originariamente inviato da john18

Nel frattempo ho aggiornato con il test dei 64 bit...Ah bhè con un athlon64 dualcore quindi non acceleri niente.

@ndrey non capisco sinceramente perchè ostinarsi in questo modo nonostante aldilà dei punti di vista c'è un insieme di regole ben precise che non puoi inventare di testa tua.

Un athlon64 3000+ guadagna al passaggio ai 64 e tanto più guadagna anche un athlon64 dualcore.

Specialmente in ambiti come conversione video,compressione di file,e via dicendo.


Mettitelo nella zucca!

Usa Windows 7 64bit con il tuo athlon64 3000+ e 2GB non voglio più parlarne guarda..

[john18]

Originariamente inviato da @ndrey

Usa Windows 7 64bit con il tuo athlon64 3000+ e 2GB non voglio più parlarne guarda..

Io il test l'ho messo,te nega l'evidenza se ti sta bene. Chiudiamola qui e buona notte che mi son stufato pure io di dimostrare qualcosa a qualcuno che risponde guardando dall'altra parte.

[KamiG]

john18, @ndrey... io vi consiglio una bella O a 32bit... poi sì che non ne parliamo più

[john18]

Originariamente inviato da KamiG

john18, @ndrey... io vi consiglio una bella O a 32bit... poi sì che non ne parliamo più

Uhm effettivamente...

[@ndrey]

Originariamente inviato da KamiG

john18, @ndrey... io vi consiglio una bella O a 32bit... poi sì che non ne parliamo più

Hai detto bene a 32bit non vado di certo ad accelerare.., più dura meglio è

[lupin87]

Originariamente inviato da mjordan

Perchè non hai mai scritto programmi che vadano al di la di un semplice esempio. Usare soltanto malloc() / free() senza alcuna tecnica di memory pooling ti espone a qualsiasi tipo di bug senza che nemmeno tu abbia il tempo di accorgertente. Supponendo che tu per qualche errore ti trovi a richiamare una free() due volte sullo stesso chunk di memoria, otterresti un crash senza alcuna informazione aggiuntiva, rendendo il debug di quel codice una cosa estremamente complessa. Utilizzando invece un'allocazione con sentinelle, puoi gestire l'allocazione / deallocazione in modo molto piu' versatile e gestire le situazioni in cui ci siano memory leaks o altri problemi. Allo scopo di comprendere quello che ti sto dicendo, ti consiglio di leggere il codice sorgente di Blender, l'allocator che hanno scritto si chiama MEM_GUARDEDALLOC ed è l'implementazione che ho in mente io mentre ti scrivo, ma devi avere un qualche fondamento di algoritmi e strutture dati.


Non sei d'accordo perchè non sai com'è strutturato un file binario. Se tu in C hai una struct del genere:

typedef struct __node {
           struct __node * next;
           void * data;
           int no_nodes;
} node;

che è una semplice lista collegata, un programma a 32 bit scriverà i campi interi nel file con dimensione di 4 byte, un programma a 64 bit li scriverà con valori di 8 byte (perchè gli interi sono 4 byte sui 32 e 8 byte sui 64). Questa genera incompatibilità, soprattutto quando le strutture devono includere una qualche sorta di padding per l'alignment in memoria. C'è di piu'. Come verrà scritto il puntatore void? Qui ti volevo: verrà scritto come un intero a 32 bit nel caso di architettura a 32 bit e come intero a 64 bit nel caso di un sistema a 64 bit. Solo che quello è un campo che accedervi necessita di un casting esplicito. E qui ti ritroveresti un codice che ritorna valori diversi se non hai in mente di scrivere il codice con queste cose in mente.
E' ovvio che questa situazione va gestita. Non si tratta di essere d'accordo, si tratta di prendere atto di come funziona. Se tu quel file poi lo devi leggere su un'altra architettura che magari ha un'endiannes diversa, devi prevedere pure il fatto che i bit sono scritti in ordine inverso

sinceramente non ho capito un granchè,molti concetti non mi sono stati spiegati all' università e altri non me li ricordo molto bene(ma sta tranquillo,in c e c++ ho fatto di tutto,ereditarietà,composzione,overriding,gestione di puntatori e reference )...so solo che la gestione dell' allocazione della memoria non spetta a me,e neanche l' uso di sentinelle....sono tutti meccanicismi che spettano al compilatore..è ovvio che non avrebbe senso utilizzare la free 2 volte sulla stessa locazione di memoria in quanto ciò creerebbe un errore di run-time

cos' è poi il padding per l'alignment in memoria?perchè nel caso dei 64 bit necessito di un casting esplicito?il casting non si fa solo per cambiare il tipo di un dato?

sul discorso dell' altra architettura non sono d' accordo:cos'è l' endiannes? ...nella programmazione ci sono vari livelli di astrazione,il livello di astrazione di un linguaggio di programmazione(alto livello) dev' essere tale che io non mi debba preoccupare di gestire i bit (cosa relativamente di basso livello-linguaggio assembly)...giusto?

[Barky]

ragazzi io vorrei chiedervi un aiuto: con la configurazione in firma ho installato seven. Non ho usato il dvd dei driver della mobo, ha trovato tutto da solo: è possibile?
Il problema però è che ho una stampante hp 6310 multifunzione ethernet, e quando vado ad installare il software non me lo fa installare e mi dice che la stampante non è collegata alla rete.
In realtà non solo è collegata, ma l'ho anche aggiunta tra le stampanti e gli ho fatto scaricare il driver da solo. Però di installare la suite hp non se ne parla, quindi col cavolo che posso fare una scansione....
Avete qualche dritta?
Grazie a tutti

[mjordan]

Originariamente inviato da lupin87

so solo che la gestione dell' allocazione della memoria non spetta a me,e neanche l' uso di sentinelle....sono tutti meccanicismi che spettano al compilatore..

L'allocazione in quanto preparazione delle risorse disponibili da parte del sistema operativo non spetta a te. E' quello che fanno malloc() / free(). Una gestione un po piu' accurata e controllata di quello che fanno grezzamente malloc() / free() invece spetta proprio a te. Nessun programma serio alloca memoria chiamando "grezzamente" malloc() e free() ma si utilizzano routine wrapper intorno a quelle funzioni per gestire le risorse in modo piu' brillante. I memory pool, appunto, che consentono di rilevare memory leaks in fase di runtime e quindi di semplificare il debug in modo traumatico. Semplifica anche la costruzione di strutture dati avanzate, visto che i problemi in genere compaiono subito al primo "sgarro" e di questo ne beneficia tremendamente anche la qualità del codice complessiva. Non sono questioni rilevanti solo su linguaggi interpretati o comunque gestiti, come ad esempio su .NET o Java, visto che di base implementano un garbage collector. Tuttavia anche con la presenza del garbage collector, i memory leak sono possibili.

è ovvio che non avrebbe senso utilizzare la free 2 volte sulla stessa locazione di memoria in quanto ciò creerebbe un errore di run-time

Appunto perchè è ovvio e appunto perchè un puntatore a zonzo potrebbe creare tale situazione, vale quanto detto sopra.

cos' è poi il padding per l'alignment in memoria?

Alcuni limiti dell'architettura impongono delle penalità di prestazioni nell'accesso di strutture dati che non siano allineate in memoria. Questo in genere non viene fatto esplicitamente a mano, perchè se ne occupa il compilatore. Tuttavia ci sono casi in cui è auspicabile farlo a mano: prendi per esempio del codice che deve supportare due compilatori diversi o, peggio, codice cross platform o, meglio ancora, codice che deve avere livelli di performance tali da non potersi permettere il lusso di affidarsi al comportamento del compilatore. Il padding consiste nell'aggiungere campi "dummy" a un struttura in modo da renderla "allineata" in memoria secondo dei canoni precisi, ovvero allineata al tipo intero piu piccolo nell'architettura (4 byte sui 32 bit, 8 byte sui 64 bit). I campi dummy si aggiungono all'inizio o alla fine della struttura. Facciamo un'esempio per capire meglio.
Supponiamo di avere una word di 4 byte. Il computer accede in memoria utilizzando proprio la word come offset minimo, di conseguenza il successivo indirizzo sarà un qualche multiplo di 4. Poichè le strutture in genere non hanno campi omogenei, questo non è sempre il caso che si verifica. Supponiamo che il prossimo campo da leggere si trova al byte 14 (anzichè 16). Per accedere a quel dato, il computer deve fare accessi multipli di lettura invece di accederlo direttamente (l'architettura RISC emette un'interrupt di "alignment fault" in questo caso). Questo crea una penalità di performance, soprattutto su programmi che fanno pesante uso di accessi in memoria. L'architettura x64 unitamente alle istruzioni SSE2 richiede un'alignment di 128 bit per essere efficiente
In genere non ci si preoccupa di queste cose su programmi semplici, su programmi dove le performance sono cruciali è la prima cosa da guardare, perchè l'alignment è il primo male nella scarsa performance di accesso alla memoria.

perchè nel caso dei 64 bit necessito di un casting esplicito?il casting non si fa solo per cambiare il tipo di un dato?

Non c'entra l'essere a 32 bit o a 64 bit. Il puntatore void non si può mai accedere direttamente ma solo mediante casting. Il casting non cambia tipo di dato, effettua una conversione di tipo. (sembra la stessa cosa ma non lo è). Non è la stessa cosa perchè un int può essere trattato come un char e viceversa, se si rimangono nei limiti di tipo. Non è quindi un "cambio" ma una conversione.

sul discorso dell' altra architettura non sono d' accordo:cos'è l' endiannes?

Scusa, mi chiedi cos'è l'endiannes è mi dici che non sei d'accordo? L'endiannes è il tipo di byte ordering che usa la CPU. Le macchine "little-endian" come ad esempio le cpu x86 rappresentano i bit da sinistra verso destra. Le macchine big-endian rappresentano i bit da destra verso sinistra (come ad esempio i processori RISC). Un file PDF generato su una macchina little-endian non sarà leggibile su una macchina big-endian se non si considerano queste cose

...nella programmazione ci sono vari livelli di astrazione,il livello di astrazione di un linguaggio di programmazione(alto livello) dev' essere tale che io non mi debba preoccupare di gestire i bit (cosa relativamente di basso livello-linguaggio assembly)...giusto?

Giusto e sbagliato nello stesso tempo a livello accademico, praticamente sempre sbagliato nel mondo pratico. In primis, un linguaggio di alto livello non significa che non possa gestire cose di basso livello (lo stesso C/C++ supporta i campi bitfield, che sono usati spessissimo, soprattutto in programmi di rete). Secondo, non ti dovrai certo mettere a "leggere i bit", ma dovrai trattare offset di byte. Non è forse la stessa cosa ai fini del byte ordering?
Se tu decidi di leggere i primi 8 byte in un file, otterrai dati differenti se ti trovi su una macchina little-endian o su una macchina big-endian proprio perchè la rappresentazione binaria è differente. Non si tratta di essere d'accordo, si tratta di capire come funziona

[Ibanez86]

Originariamente inviato da mjordan

Insomma, sicuramente molto del codice può essere riutilizzato così com'è ma è sicuramente meno banale di una ricompilata e di "cambiare qualche valore" (che poi che vuol dire ). Altrimenti adesso non avevamo il problema della latitanza di software a 64 bit. La realtà è che è meno banale del previsto e per software di una certa complessità va prevista una fase di analisi e testing rigorosa (e dispendiosa), oltre che a una riprogettazione di diverse parti del programma.

e ovvio che ogni sistema ha il suo sistema di calcolo.. ad esempio col 64bit lavori tanto in doppia precisione..

quello che volevo dire era la stessa cosa tua, solo che da me han capito in una riga, da te, si saran addormentati sulla tastiera

il concetto di base era.. il comando base write() o read() è lo stesso sia in 64 che 32bit.. parlo della funzione in se.. poi è ovvio che il sistema avendo una parola di bit diversa, deve ragionare con concetti diversi..

il programmatore in se non si fa enormi paranoie per ricompilare un programma.. nel senso.. quando hai già steso tutto il codice, devi solo "perfezionarlo" e non getti tutto per reiniziare con una struttura di codice completamente diversa..

si diceva che il 64bit fosse iper pesante ecc ecc ecc.. in realtà non lo è..

[mjordan]

Originariamente inviato da Ibanez86

e ovvio che ogni sistema ha il suo sistema di calcolo.. ad esempio col 64bit lavori tanto in doppia precisione..

quello che volevo dire era la stessa cosa tua, solo che da me han capito in una riga, da te, si saran addormentati sulla tastiera

il concetto di base era.. il comando base write() o read() è lo stesso sia in 64 che 32bit.. parlo della funzione in se.. poi è ovvio che il sistema avendo una parola di bit diversa, deve ragionare con concetti diversi..

il programmatore in se non si fa enormi paranoie per ricompilare un programma.. nel senso.. quando hai già steso tutto il codice, devi solo "perfezionarlo" e non getti tutto per reiniziare con una struttura di codice completamente diversa..

si diceva che il 64bit fosse iper pesante ecc ecc ecc.. in realtà non lo è..

Io le cose le spiego e spiego i motivi per cui dico quello che dico, non faccio asserzioni di verità che poi alla fine concettualemnte sono false e potenzialmente anche sbagliate. Il programmatore non si fa enormi paranoie perchè consideri "programmatori" gente che ha letto un libro di C e scrive programmi di esempio "giocattolo". I programmatori, quelli veri, stanno ancora lavorando duramente alla conversione di software a 64 bit e le aziende stanno investendo miliardi di dollari. Non è un processo "banana" come lo volete far credere. Io ho spiegato quali sono i punti cruciali nella conversione di software a 64 bit, se ti ci sei addormentato o è perchè conosci alla perfezione quello che ho detto (e quindi non dovresti asserire quello che hai asserito) o perchè di opposto non c'hai capito nulla (e quindi, ancora, non dovresti asserire quello che hai asserito )
In entrambi i casi, che il codice a 64 bit sia una semplice ricompilata, per software reali (non giocattolini da esercizio accademico) è puramente una sciocchezza.

[citytrader]

Ciao a tutti, vorrei un suggerimento da parte vostra.... il mio hardware è: i7 920 + 6 GB di RAM e scheda nvidia 9600GT.
Uso il pc con Photoshop CS4 esclusivamente e lavoro con file RAW di 21 Mpx (130Mbyte di TIFF)... quindi con 3Gig di Ram usabili in WinXP non va più bene, ho bisogno di più, stavo pensando a tre opzioni:

Windows XP + Superspeed Ramdisk in questo modo con 6 Giga di Ram uso 3 GB per il ramdisk

Windows 7 64Bit + photoshop 64 bit con il problema che ci sono pocchi plugin a 64 bit, pero con l'OS a 64 bit posso avere 3 GB dedicati al PS CS4 e il resto lo può usare il OS, diverso del XP che usa 3 GB tanto per l'OS come per l'applicativo (nel caso che usi PS CS4 a 32 bit)....

Ultima opzione Windows 7 32 Bits con Ramdisk...

Domanda: riscontrate che è W7 è veloce come XP?... secondo voi che opzione potrebbe essere meglio per me?

Grazie!

[Ibanez86]

Originariamente inviato da mjordan

Io le cose le spiego e spiego i motivi per cui dico quello che dico, non faccio asserzioni di verità che poi alla fine concettualemnte sono false e potenzialmente anche sbagliate. Il programmatore non si fa enormi paranoie perchè consideri "programmatori" gente che ha letto un libro di C e scrive programmi di esempio "giocattolo". I programmatori, quelli veri, stanno ancora lavorando duramente alla conversione di software a 64 bit e le aziende stanno investendo miliardi di dollari. Non è un processo "banana" come lo volete far credere. Io ho spiegato quali sono i punti cruciali nella conversione di software a 64 bit, se ti ci sei addormentato o è perchè conosci alla perfezione quello che ho detto (e quindi non dovresti asserire quello che hai asserito) o perchè di opposto non c'hai capito nulla (e quindi, ancora, non dovresti asserire quello che hai asserito )
In entrambi i casi, che il codice a 64 bit sia una semplice ricompilata, per software reali (non giocattolini da esercizio accademico) è puramente una sciocchezza.

quello che dico semplicemente ricade in una cosa.. siamo dentro ad un topic che parla di windows 7.. se si paragonano le 2 versioni di windows 7, allora si sta in-topic.. sennò.. si va completamente off..

te hai perfettamente ragione.. ma alla fin fine è il 3D sbagliato.. nel senso.. va a scrivere ste cose in un 3D cui si parla di x86 e x64, non in uno di sistemi operativi.

è come se ora voi mi chiedeste qual'è la differenza tra differenziale autobloccante e normale.. e invece di dirvi che il primo permette più stabilità, inizio ad inculzarvi la zucca di nozioni fisiche e meccaniche del funzionamento del planetario intrinseco nel sistema..

non so se ho reso l'idea..

quello che volevo dire era..
I programmatori buttano via tutto il codice sorgente di un programma passando da x86 a x64? nel senso.. sono 2 standard talmente diversi che cambia proprio la logica di base?