Prendo spunto da un post apparso su OneApple qualche giorno fa in cui si chiedeva: cosa vi manca di Windows? Senza nemmeno pensarci troppo rispondo: le scorciatoie da tastiera! Da bravo power user Windows sono abituato ad utilizzare per il 90% del tempo la tastiera e non il mouse: su questo fronte Mac Os X è spesso un insulto all’usabilità.

Facciamo un esempio pratico: sulla scrivania ho un file test.jar e voglio rinominarlo in test.zip.

Prima considerazione: non conviene rinominare il file direttamente dal finder, talvolta non si ottiene il risultato desiderato. Ad esempio: create un file test.zip sul desktop con YemuZip, selezionatelo, premete invio ed eliminate l’estensione .zip. Apparentemente il file cambia nome (non icona) ma basta andare nelle informazioni (MELA+I) per scoprire che il file continua imperterrito a chiamarsi test.zip.

A questo punto tanto vale rinominare il file direttamente dalla finestra Informazioni su (MELA+I), almeno andiamo sul sicuro. Questa è la finestra che appare nel momento in cui cerco di rinominare test.jar in test.zip

In Windows avrei il mio simpatico access key per attivare il pulsante “Usa .zip”: su un Mac come faccio? Devo premere due volte il tasto TAB per selezionare il pulsante e poi la barra spaziatrice per attivarlo! I casi sono due: vogliono farmi cambiare la tastiera con una frequenza maggiore, oppure sono finanziati dalla lobby del tunnel carpale.

La situazione non migliora se voglio aggiungere l’estensione ad un file che ne è sprovvisto

Ma veniamo alla vera ciliegina sulla torta: cerco di sostituire un file esistente, ad esempio con un MELA+C e un MELA+V (il classico copia/incolla), e cosa mi trovo?

Una finestra in cui NON posso usare la tastiera: sono semplicemente obbligato a prendere in mano il mouse.

Certe volte odio Mac Os X (ma con moderazione 😉 )

Stasera ho acceso il notebook per registrare un po’ di contabilità e ho notato immediatamente uno strano rallentamento del sistema : è bastata una rapida occhiata al task manager per scoprire un processo svchost.exe fisso al 100%. A questo punto ho provato a dare un’occhiata con Process Explorer ed ho scoperto che quell’istanza di svchost.exe era collegata ad almeno una decina di servizi di sistema (il solito fortunello…).

Una ricerca su Internet mi ha fatto arrivare alla KB916089, in cui si scopre che il problema è causato dall’accoppiata Windows Update/Microsoft Update: “When you run Windows Update to scan for updates that use Windows Installer, including Office updates, CPU utilization may reach 100 percent for prolonged periods”.

Siccome la patch iniziale (KB916089) creava problemi risolti con una contropatch (KB927891) decisamente “fresca” (10 maggio), per il momento ho preferito la strada meno rischiosa: ho aperto Windows Update e disattivato Microsoft Update. In questo modo non riceverò gli aggiornamenti di Office ma almeno il notebook non prenderà il volo a forza di far girare la ventola.

Se ricevete una segnalazione di errore con questo titolo, la causa è della KB 925902 installata in questi giorni attraverso gli aggiornamenti automatici (il file in questione è legato alla scheda audio).

La DLL user32.dll del sistema è stata rilocata in memoria. L’applicazione non sarà eseguita correttamente. La DLL c:\windows\system32\HHCTRL.OCX è stata rilocata poiché occupava uno spazio di indirizzamento riservato a una delle DLL del sistema di Windows. Contattare il fornitore della DLL per ottenere una nuova DLL.

Soluzione: scaricare ed installare la patch KB 935448.

Scenario: due pc con Windows XP Home sp2, un notebook e un desktop, entrambi con indirizzo IP fisso. I pc riescono a pingarsi, il desktop accede tranquillamente al notebook, il notebook non riesce ad accedere al pc desktop (accesso negato).

Provando da prompt dei comandi con net use, il codice di errore che appare è il seguente

Errore di sistema 1385
Errore durante l'accesso. L'utente non ha ottenuto il tipo di accesso richiesto a questo computer.

Le prime ricerche non hanno dato esito positivo: come spesso capita in questi casi finisco sul blog di Andrea Beggi, peccato che le indicazioni siano valide solo per XP Professional 🙁

Dopo parecchio ravanare ecco una possibile soluzione (trovata in questa utilissima pagina):

• scaricare ed installare il Windows Server 2003 Resource Kit Tools
• aprire il prompt dei comandi da Start->Programmi->Windows Resource Kit Tools->Command Shell (in alternativa aprire la shell e posizionarsi nella cartella dove si trova ntrights)
• digitare i seguenti comandi (servono per abilitare l’accesso guest alla rete)
  net user guest /active:yes
ntrights +r SeNetworkLogonRight -u Guest
ntrights -r SeDenyNetworkLogonRight -u Guest

A questo punto (almeno nel mio caso) ci sono ancora problemi ad accedere direttamente al computer (\\nomepc) ma è possibile usare le stampanti e le condivisioni usando l’indirizzo completo (\\nomepc\condivisione o \\nomepc\stampante).

Prologo: ricordate l’hard-disk che ci ha tristemente lasciati nel fiore della sua giovinezza lunedì mattina? Bene. Oggi ho riconsegnato e reinstallato la macchina: siccome il pc aveva solo 72 ore di vita, ho ritenuto corretto non fatturare le ore necessarie per la sostituzione del disco, la reinstallazione del sistema operativo e dei vari software.

Piccolo dettaglio: nessuno mi toglie dalla testa che il disco non sia morto per suicidio ma per omicidio colposo. Il pc è collegato a un gruppo di continuità “serio” (industriale, non quelli plasticosi da ufficio): la persona che usa il pc lo dovrebbe spegnere in un orario compreso tra le 17.30 e le 19.30, alle 22 finisce la produzione e viene chiuso l’interruttore generale (e spento il gruppo di continuità che fischia come un dannato).
Siamo sicuri che il computer sia stato spento come $entità_superiore comanda? No.

A questo punto mi è venuto il dubbio: come posso verificare che il pc venga spento prima delle 22? Creo una cartella LOG, restringo le possibilità di accesso all’utente Administrator, imposto un’operazione pianificata che alle 20.30 esegue uno stupidissimo file batch:

echo Il computer risulta acceso alle %time% del %date% > log.txt

Piccolo problema: se l’hard-disk va a peripatetiche, che me ne faccio di un file log.txt sullo stesso disco illeggibile? Purtroppo non ci sono altri pc o storage di rete su cui salvare il file.

Soluzione: inviare una e-mail alla mia casella di posta con il file di testo usando blat, un semplicissimo tool per l’invio di mail da linea di comando.

Per prima cosa bisogna scrivere nel registro le informazioni sul server in uscita (nel mio caso un server SMTP con autenticazione). Questa operazione è necessaria solo la prima volta che si usa il programma sul pc

blat -install $indirizzo_server_smtp utente@dominio.tld

Poi basta modificare il file batch in questo modo (sostituendo i vari parametri con i vostri dati)

echo Il computer risulta acceso alle %time% del %date% > log.txt
blat log.txt -to $mio_indirizzo_email -server $indirizzo_server_smtp -u utente@dominio.tld -pw $password_auth -subject "File di controllo spegnimento pc"

Per il corpo del messaggio verrà utilizzato il file log.txt; il messaggio verrà spedito all’indirizzo $mio_indirizzo_email autenticandosi sul server $indirizzo_server_smtp con nome $nome_utente_auth e utente@dominio.tld

Per ulteriori informazioni potete consultare l’abbondante documentazione 😉

Non esistono più le mezze stagioni ma almeno ci resta una certezza: passano gli anni, cambiano le versioni ma le previsioni di Windows sui tempi necessari per completare un’operazione sono sempre assurde.

Da notare: l’operazione ha richiesto complessivamente un paio di minuti e non era nemmeno all’inizio (come si può notare dalla barra di scorrimento).