Newsgroup: it.comp.os.win.windows7
Titolo: Passaggio a 64 bit?

Come da oggetto...
 
Parte degli applicativi che mi servirebbero ci sono, ma
sono sotto la metà (e alcuni di quelli che sono solo a 32
bit mi sarebbero indispensabili). Premesso che il nuovo PC
sarà un i5-2500K con 16G RAM le domande sono:
 
1) Ammesso di trovare tutti i drivers delle periferiche,
la versione di 7 a 64 bit è stabile o ogni tanto c'è
qualche problema?
 
2) A quanto ne so, in caso di applicativi a 32 bit,
windows virtualizza in modo trasparente o qualcosa di
simile. A me non creerebbe problemi avere una macchina
virtuale a 32 bit; per adesso Oracle virtual box si è
comportato bene, ma ho sempre virtualizzato per
applicazioni non critiche, come sviluppo software e prova
di programmi. Adesso, invece, dovrei in un certo senso far
conto sulla virtualizzazione, vuoi imposta da win, vuoi
gestita da me. Che mi devo aspettare come calo di
prestazioni rispetto a un normale S.O. a 32 bit?
 
grasssssie
 
Apx.
 
-- 
Le persone nel mondo si dividono in tre
categorie: quelle che sanno contare e
quelle che non sanno contare.
 

Per i posteri, *Archaeopteryx* scrisse:
| Come da oggetto...
|
| Parte degli applicativi che mi servirebbero ci sono, ma
| sono sotto la metà (e alcuni di quelli che sono solo a 32
| bit mi sarebbero indispensabili). Premesso che il nuovo PC
| sarà un i5-2500K con 16G RAM le domande sono:
|
| 1) Ammesso di trovare tutti i drivers delle periferiche,
| la versione di 7 a 64 bit è stabile o ogni tanto c'è
| qualche problema?
 
Stabile. I problemini sono solo di driver che devon esser certificati a 64 
bit e qualche software che fa lo schizzinoso ad essere installato _anche_ in 
modalità compatibile 32 bit (leggansi autocad 32 bit 2011 che si installa 
solo il 64 bit)
 
| 2) A quanto ne so, in caso di applicativi a 32 bit,
| windows virtualizza in modo trasparente o qualcosa di
| simile. A me non creerebbe problemi avere una macchina
| virtuale a 32 bit; per adesso Oracle virtual box si è
| comportato bene, ma ho sempre virtualizzato per
| applicazioni non critiche, come sviluppo software e prova
| di programmi. Adesso, invece, dovrei in un certo senso far
| conto sulla virtualizzazione, vuoi imposta da win, vuoi
| gestita da me. Che mi devo aspettare come calo di
| prestazioni rispetto a un normale S.O. a 32 bit?
 
Naaaaaaa, hai una CPU paragonabile alla tua cibierre come prestazioni, ci 
puoi anche fare il caffè.Quello che metti su rulla bene. STOP
Mettere il 32 bit sul tuo pc avrebbe senso solo per motivi particolari, la 
RAM verrebbe vista tutta con la mia patch :-D ma IMO oramai ti conviene 
saltare il fosso.
 
| grasssssie
 
 
 
 
 
 
-- 
Don Fizzy © on GSX-R 750
"Non c'è trucco non v'è inganno"
       /)/)
     (  '.')
   o(_('')('')   That's all, folks!
Nessun bit è stato maltrattato
per spedire questo messaggio. 
 
 

 prestazioni rispetto a un normale S.O. a 32 bit?
 
per le applicazioni windows a 32 bit non noterai alcuna differenza.
Se installi un virtualizzatore per far girare un altro sistema 
operativo, dipende da quante risorse gli puoi/vuoi assegnare. In linea 
di massima piu' ram fisica hai e meglio e', il che porta verso sistemi 
a 64 bit che la possano utilizzare
 
Adriano
 
 

 Come da oggetto...
 
Grazie molte a entrambi. Appena la nuova creatura arriverà
(anche se a pezzi) partirò con un dubbio in meno e
32 bit più del mio solito (sì, sarà il mio primo windows a
64 bit).



Uhm, windows a 64 bit esiste già dai tempi di XP :)  Non è certo una novità 
di win7 :) Personalmente da quando sono passato a processori a 64 bit, ho 
sempre usato sistemi operativi a 64 bit.
Lascia perdere i luoghi comuni, è la stessa paura che c'è quando si 
abbandona il vecchio per il nuovo, la stessa paura che c'era quando sono 
iniziate a spuntare le macchine a vapore quando si usava ancora camminare 
col cavallo.
In questo caso, la differenza tra il 32 bit e il 64 bit è solo a livello 
architetturale della macchina, ma a livello utente, la differenza è solo in 
un sensibile miglioramento delle prestazioni.
Poi comunque il 64bit come ho sempre detto è retrocompatibile, vale a dire 
che fa girare senza problemi tutto il software sviluppato a 32bit, cosa che 
invece non avviene nel caso opposto.
L'eccezione unica è solo per i driver, che un sistema a 64 bit accetta solo 
driver a 64 bit, ma questo problema era presente *SOLO* i primi anni in cui 
è uscito il primo windows a 64 bit e i driver a 64 bit per le periferiche 
esistenti erano pochi, ma ora a distanza di 10 anni questo problema non 
sussiste più; potrebbe esserci se hai periferiche hardware più vecchie di 10 
anni ma non per quelle più nuove.
In ogni caso, per le periferiche più vecchie, windows supporta i driver 
standard nativamente, e quindi il problema è superato; poi se prendi la 
versione ultimate di win7 e hai hardware vecchio piu di 10 anni e vuoi usare 
i driver nativi del produttore, puoi sempre bypassare il problema usando 
l'XP-Mode.
Quindi non hai motivo di doverti preoccupare più di tanto. Fai passare il 
principio che con CPU a 64 bit, devi usare il sistema operativo a 64 bit; 
altrimenti con un sistema operativo a 32 bit e una CPU a 64 bit, è come se 
tu usassi la CPU a 32 bit e non a 64 bit :) Insomma è come se tu fossi 
ancorato ancora a 10 anni fa :) con una macchina più moderna :)
 
 

 Apx.
L'unico "problema" che ho trovato con i 64bit me l'ha dato Java, con
cui ci lavoro. Oracle pubblica JVM sia a 64bit che a 32bit, ma l'unico
web browser per windows a 64bit che conosco ï¿œ Internet Explorer. Questo
significa che, installata una JVM a 64bit, le eventuali applet (o
applicazioni JNLP) che vengono eseguite nello stesso contesto del
browser, funzioneranno solo su Internet Explorer a 64bit, non su
Firefox o Chrome.
La soluzione? Installare JVM a 32bit, almeno finchï¿œ anche gli altri
browser non vengano compilati nativamente a 64bit.
-- 
erk: C0 CE FE 84 C2 27 F7 5B D0 7A 7E B8 46 50 9F 93 B2 38 E7 70 DA CB
9F F4 A3 88 F8 12 48 2B E2 1B riv: 47 EE 74 54 E4 77 4C C9 B8 96 0C 7B
59 F4 C1 4D - further info: Google it!
(per rispondere personalmente leva IlDitoDalCulo)


Basta con sta leggenda metropolitana dei driver per il 64 bit,
una volta3-4 anni fa, forse.....adesso non più dai....una critica però
devo muovertela, per 20-30 euro in più, visto la quantità di ram
suppongo che stai assemblando un signor pc, caspita, la cpu
potevi prenderla con il K, moltiplicatore sbloccato, dove stà il senso
di prendere il 2500 secco?
Qui hai cappellato...secondo me , intendiamoci.... 
 

Scusa, azz non avevo visto il K.....come non detto
infatti mi sembrava strano...scusa ancora..... 
non tenete conto del mio post precedente,
sono io che ho cappellato......

 intendiamoci....
Ma no, ho preso la K; infatti intendo downclockarlo almeno
un poco :) A meno che non si dimostri un miracolo di
"freddezza", perché per quanto sia buono il case che mi è
stato consigliato, il PC va per forza in un soppalco non
troppo ventilato che d'estate si sente tutto. Se poi so
che devo fare cose turche, rebooto e porto il clock a
quello che sarà possibile. Eppoi, il collo di bottiglia
non era la RAM? Non lo so, chiedo.
ciao!


 Come da oggetto...
 
grazie a tutti dei suggerimenti... ero un po' dubbioso
perché qualche anno fa ricordavo tonnellate di post in cui
ci si lamentava per drivers, mancanza di applicativi,
problemi di compatibilità con le periferiche. Credo che
proverò il 64 bit, faccio sempre in tempo a tornare al 32 ^_^


Per i posteri, *Archaeopteryx* scrisse:
 
[...]
 
| Ma no, ho preso la K; infatti intendo downclockarlo almeno
| un poco :) A meno che non si dimostri un miracolo di
| "freddezza", perché per quanto sia buono il case che mi è
| stato consigliato, il PC va per forza in un soppalco non
| troppo ventilato che d'estate si sente tutto. Se poi so
| che devo fare cose turche, rebooto e porto il clock a
| quello che sarà possibile. Eppoi, il collo di bottiglia
| non era la RAM? Non lo so, chiedo.
 
Non downloadare una mazza e la RAM non è il collo di bottiglia, casomai 
potrebbe esserlo l'HD, se non lo pigli statico, se ti accontenti invece di 
un normalissimo HDD, i suoi 100 e passa MB/s te li tira sempre e potrebbero 
bastare.
Quindi assembla quel pc e non stare a farti paranoie brunellesche :-D


 brunellesche :-D
 
Ho saputo che c'è un raduno organizzato da Priano (lo so
dalla lista romana, non so se è su IHM che non leggo più),
vieni? Come? Sì? Ah, ok...



credi all'asino che vola?


http://www.unawave.de/windows-7-tipps/32-bit-ram-barrier.html?lang=EN
 


Per nulla affidabile.
Se un sistema è a 32 bit, la capacità di indirizzamento della memoria è 
limitata a 32 bit; limite hardware.  Sarebbe fattibile qualora il processore 
sia a 64 bit e il sistema operativo sia a 32 bit, il discorso in questo caso 
è diverso.
A parte questo, si parla di patchare il kernel, già la parola patchare è 
sbagliata, perchè essa allude alla correzione di un qualcosa, ma in questo 
caso non si tratta di correggere ciò che è corretto ma di modificare 
qualcosa per ottenere un altra cosa.
E' chiaro che modifiche di questo genere, per di più a livello di kernel, 
sono del tutto inaffidabili; pensiamo pure a un aggiornamento che corregge 
un bug proprio li. Tutto salta.
E che dire dei programmi, essi sono progettati in un certo modo per 
funzionare in quel modo, alterazioni di questo tipo comporterebbero per 
l'applicazione delle instabilità.
E meglio quindi lasciare le cose come stanno o se si ha la necessità di 
tutta la memoria utilizzare una versione di windows a 64 bit direttamente.
Ste porcherie cosi, fanno perdere solo tempo.
 
PS: Nell'articolo si evidenziava il fatto che la starter legge fino a 2 gb, 
mentre la home etc fino a 3,5 etc. Nel caso della starter sussiste un blocco 
software alla capacità di indirizzamento e questo è fattibile, infatti 
rientriamo al di sotto dei 2^32 bit di memoria.
 

 Ste porcherie cosi, fanno perdere solo tempo.
 
su questo quoto!
 
 
-- 
Fri(END), Boyfri(END), Girlfri(END), Bestfri(END). Everything has an END 
except...Fam(ILY)! It Has 3 Letters that say I LOVE YOU 
 

 limitata a 32 bit; limite hardware.
 
Ma anche no. Per esempio, sotto Windows a 32 bit,
con PAE abilitato, *ogni processo* ha accesso ad
un massimo di 4 GB. Con AWE si può anche andare
oltre.
http://msdn.microsoft.com/en-us/library/aa366718%28v=VS.85%29.aspx
 
 
Bye, G.


Non è detto, la memoria è organizzata per indirizzi. Forzare la memoria 
cercando di prendere per il culo il sistema operativo comporta per il 
programma che agisce secondo la logica del sistema operativo "non forzato" 
delle instabilità o meglio delle incompatibilità.
Scenario: se la memoria è a 32 bit e quindi gli indirizzamenti variano da 
$00000000 a $FFFFFFFF  nel momento in cui devi allocare in uno spazio che 
eccede, dove vai? Ricordiamo che l'indirizzamento di memoria è a 32 bit e 
non a 33 bit o superiore :)
Ammesso che trovi una cella che sta fuori, il sistema operativo diviene del 
tutto inaffidabile visto che è stato preso per il culo, e il programma che 
si affida al sistema operativo?
Il punto è: potrà anche funzionare, ma certamente il funzionamento non sarà 
stabile e quindi siamo al punto di partenza. Questi sono dei casi in cui, 
uno usa ste porcherie e poi quando installa un programma open source (ad 
esempio) e vede che crasha, darà la colpa al sistema operativo che non 
funziona :)
Poretti noi! 
 


Ogni processo ha accesso a 4gb perchè 4 gb sono 32 bit e quindi niente di 
strano.  A questi 4 gb dobbiamo togliere la memoria allocata per la scheda 
video, per le periferiche etc etc, quindi si scende a quei 3,5 gb circa.
In ogni caso, se ogni processo ha accesso a 4gb, due processi hanno accesso 
a 8gb ? Certamente no! Se il totale è 4 gb, la quantità deve rimanere in 
quel limite.
E poi comunque esiste sempre la memoria virtuale, quindi quando quella 
fisica si esaurisce il sistema alloca su quella virtuale che non è soggetta 
a questi vincoli di natura hardware. 
 

 accesso a 8gb ?  Certamente no!
 
Sì. Capisco che è una cosa complicata fare click
su quel link e leggere quello che c'è scritto,
ma se ci provassi... in particolare qui:
"Physical Address Extension"
http://msdn.microsoft.com/en-us/library/aa366796%28v=VS.85%29.aspx
 
e qui:
"Address Windowing Extensions"
http://msdn.microsoft.com/en-us/library/aa366527%28v=VS.85%29.aspx
 
 
Bye, G.


Non è complicato fare click :) E' più complicato capire che se ci sono 
precisi limiti hardware, questi non possono essere bypassati a livello 
software.
Ripeto limiti hardware, non software. Poi si sa, che è possibile adottando 
oppurtune tecniche al livello hardware è possibile bypassare questi vincoli, 
ma questa è un altra storia.
Qui si sta parlando di bypassare i limiti hardware con il software. Prima 
avevo scritto che se l'hardware è a 64 bit, e il sistema operativo è a 32 
bit è chiaro che col software è possibile bypassare il vincolo dei 32 bit 
del sistema ma al contrario non vale :).
E' un po' come dire al motore di una 500 di comportarsi come quello di una 
ferrari.
 
 

 Non è complicato fare click :) E' più complicato capire
 
Si vede.
 
Bye, G.


Hai ragione, si vede che non hai letto fino in fondo :) Ci sono notevoli 
restrizioni, ci hai fatto caso? :) Oppure ti sono sfuggite? :) 
 

 Ci sono notevoli restrizioni, ci hai fatto caso? :)
 
Certo che ci sono.
 
 > Oppure ti sono sfuggite? :)
 
Quello che pare sia sfuggito a te è il punto puro e
semplice che hai detto una cazzata. O più di una,
per la precisione. E non è arrampicandoti sugli
specchi con "ma ci sono delle restrizioni" che una
cazzata smetterà di essere tale.
 
Bye, G.

 del sistema ma al contrario non vale :).
 
non esattamente.... la MMU serve appunto per questo, basta programmarla 
opportunamente:
 
<cit>
La MMU può avere vari compiti tra cui la traslazione (o traduzione) degli 
indirizzi virtuali in indirizzi fisici (necessaria per la gestione della 
memoria virtuale), la protezione della memoria, il controllo della cache 
della CPU, l'arbitraggio del bus, e, in architetture più semplici 
(specialmente nei sistemi a 8-bit), la commutazione di banchi di memoria.
</cit>
 
L'ultima frase " (specialmente nei sistemi a 8-bit), la commutazione di 
banchi di memoria" puù trarre in inganno, nessuno vieta in un sistema ad n 
(nel nostro caso 32) bit, di programmare la MMU in modo che la memoria venga 
gestita a banchi o pagine, in modo da superare il limite imposto 
dall'indirizzamento, e presumo che PAE faccia esattamente questo.
 
per i meno giovani, ricordo che  nel 1980 gli MSX con qualche accorgimento 
potevano indirizzare ben più dei 64k consentiti con un bus address da 16 bit
 
<cit>
"RAM: da un minimo di 16 kB ad un massimo di 64 kB, e con opportune cartucce 
e software poteva gestire fino a 1 MB (in Europa vennero commercializzati 
solo modelli con 32, 48 e 64 kB di RAM)"
</cit>
 
con un "misero" Z80 ad 8bit
 
per saperne di più:
 
http://it.wikipedia.org/wiki/Memory_management_unit
 
http://it.wikipedia.org/wiki/Standard_MSX
 


 Poretti noi!
 
mi sa che non hai le idee molto chiare....
 
applicazione: ehi SO mi servono 20MB
SO: spï¿œ che vedo...
a questo punto se i 20 mega ci sono, vengono allocati e stop, altrimenti il 
SO cerca un modo per procurarseli, scaricando eventualmente qualcosa nello 
swap, se non ci sono ottieni un "out of memory error"
 
*nessun* programma puï¿œ chiedere un quantitativo di memoria a partire da un 
indirizzo di sua scelta, ed in ogni caso la MMU (vedi altro messaggio a 
proposito...) puï¿œ benissimo ingannare il programma facendogli credere che 
gli indirizzi sono quelli richiesti.
Non siamo piï¿œ ai tempi del C64 e dello ZX Spectrum, dove andavi di PEEK & 
POKE a smandruppare per la memoria a tuo piacimento.



Ecco :) queste sono le "particolari tecniche" a cui alludevo prima.  Nella 
sostanza comunque resta il fatto che si rimane vincolato all'hardware, il 
software non può scavalcarlo.
Puoi fare qualcosa del genere senza ricorrere a queste tecniche soltanto col 
software? :) 
 


Ovvio, ma se alteri il kernel di windows... questa modifica forza il sistema 
ad assumere un comportamento diverso da quello di origine, i programmi che 
dipendono dallo stesso windows per forza di cose ne risentono.
Poi sono modifiche comunque non esenti da rischi... quindi...


 col software? :)
 
bhï¿œ... la MMU ï¿œ presente in tutti i processori moderni, quindi......


 Poi sono modifiche comunque non esenti da rischi... quindi...
 
con questo ragionamento, qualsiasi patch effettuata sul SO inficierebbe la 
stabilità del sistema, quando scarichi aggiornamenti (sopratutto quelli di 
sicurezza) da WU cosa credi che succeda? Il sistema viene patchato. Che le 
modifiche estemporanee possano creare problemi è sicuramente vero, ma voglio 
sperare che a Redmond qualcosa ne capiscano e PAE è supportato nativamente 
da diverse versioni di Windows.
 
http://it.wikipedia.org/wiki/Physical_Address_Extension
 


 bhè... la MMU è presente in tutti i processori moderni, quindi......
 
I computer "veri" ;) ce l'avevano praticamente da sempre, ma
già a fine anni '70 erano roba normale anche nei processori
per microcomputer, dallo Z80 alla serie 68K.
 
Bye, G.

 
"Paperino" <non...@lo.dico.invalid> ha scritto nel messaggio 
news:j7crgk$eoi$1...@dont-email.me...

eh eh eh.... ho scritto "processori" non computer :) la MMU è stata per 
molto tempo un componente separato, così come lo erano i coprocessori 
matematici (per es. 680x0 - cpu 6888x - cop 68451 - mmu)


quindi come fare? ho 6 gb in un sistema con windows 7 ultimate con 2,94 
mb utilizzabili...

 matematici (per es. 680x0 - cpu 6888x - cop 68451 - mmu)
 
Diciamo che alcune caratteristiche dell'indirizzamento
e dell'I/O potevano essere utilizzate, in combinazione
con un minimo di logica HW, per ottenere caratteristiche
simili (ovviamente con minor efficienza) anche senza
una MMU. Per esempio lo Z80 aveva delle istruzioni
ufficialmente non documentate, tranne che sui libri
non della Zilog ;-) per indirizzare anche l'I/O a
16 bit anzichè gli 8 ufficiali.
Da questo punto di vista non aveva strettamente bisogno
di una MMU esterna :-).
 
Un Paperino con lo ZX-80 (ma con la ROM dello ZX-81 :-))
ancora in garage.


Il problema non sono le patch  ufficiali, nel caso di windows, quelle 
rilasciate da microsoft, ma quelle di terze parti; che nel caso del thread 
vanno ad alterare il kernel di windows.
Per fare un esempio pratico, se devi fare un trapianto di cuore, ti rivolgi 
ad un cardiologo affermato o ad un pincopallino chiunque? Io penso ad un 
cardiologo affermato, perchè ti senti più sicuro? Lo stesso anche nel caso 
di patch ufficiali rilasciate da microsoft e di patch rilasciate da terze 
parti.
Ecco quindi che si ritorna al punto di partenza. Hai bisogno di piu ram? non 
modificare a caso il sistema operativo a 32 bit, prendine direttamente uno a 
64 :)



Certamente, ma il punto non è se è presente o no :) ma come questa viene 
usata dal software. Riprendendo l'esempio del cardiologo di cui al post 
precedente, hai davanti due cardiologi uno con 25 anni di esperienza, 
primario e quello che vuoi, e un altro invece appena laureato e al primo 
anno di esperienza.
Fra i due, a chi ti rivolgi per l'intervento chiururgico? Sincero :) Io 
personalmente al primo, con maggiore esperienza perchè mi da maggiore 
sicurezza, e tu? :)
 


Passa a windows 7 ultimate a 64 bit. E' il modo più semplice e indolore :) 
 

 ancora in garage.
 
Un liftman con ancora in cantina lo ZX Spectrum 16k espanso a 48 + IF1 e 2 
MD :)


 ha scritto nel messaggio 
news:4e9a030b$1...@news.x-privat.org...

l'esempio non calza.... qui il cardiologo è solo uno (Microsoft) e il cuore, 
qualsiasi "cuore" attualmente in uso nei pc, ha tutte le "coronarie" 
d'ordinanza, compresa la MMU, e il primario ha certamente esperienza d'uso 
della terapia giusta (PAE)
 
a marcè... come dicono gli anglofoni "Don't climb yourself on the mirrors" 
(non arrampicarti sugli specchi) :)


 uno a 64 :)
 
hai bisogno di + ram? hai delle vecchie periferiche per le quali non 
esistono drivers 64bit e per nessun motivo al mondo sei disposto a 
separartene? usi PAE che non è una "modifica a caso".


per microcomputer, dallo Z80 alla serie 68K.
 
Ricordo bene lo Z8S180, era uno Z80 con MMU incorporata (~1985) che permetteva
di indirizzare fino ad 1MB linearmente mantenendo per� il data address a 16 bit
e quindi la compatibilita' con lo Z80.
 
Fu la sua fortuna, unita al fatto che l'architettura del �P (Von Neumann)
consentiva l'esecuzione di codice rilocabile in ram, permettendo quindi
l'esecuzione di routines in segmenti di ram separati.
 
 
http://www.wfms.org/sb180/z180-prelim.pdf
 
 
http://it.wikipedia.org/wiki/Architettura_von_Neumann
 
 
 
--
ciao
  Stefano