PDA

View Full Version : cosa crea l' incompatibilità con Vista?


nuovoUtente86
23-04-2008, 23:53
Soprattutto nei primi mesi, molti software era incompatibili con il nuovo OS. Ma nella pratica della programmazione a cosa sono dovute queste incompatibilità? Le API almeno per quanto riguarda l' "interfaccia" esposta non dovrebbero essere cambiate..

cdimauro
24-04-2008, 09:06
Le API sono cambiate: estese o aggiunte, ma c'è compatibilità col passato.

Il problema, al solito, è che i programmatori non seguono tutte le direttive MS per la scrittura delle applicazioni.

Esempio minchione: usare la cartella in cui sta l'applicazione per memorizzare dati & informazioni. Appena passi a usare un utente limitato non ti funziona più perché non hai i privilegi per accedervi.

71104
24-04-2008, 12:14
Esempio minchione: usare la cartella in cui sta l'applicazione per memorizzare dati & informazioni. Appena passi a usare un utente limitato non ti funziona più perché non hai i privilegi per accedervi. se è per questo si può fare di peggio: hard-coded paths, "C:\Temp"... :Puke:

comunque non sempre la retrocompatibilità viene mantenuta: in rarissimi casi certe semantiche vengono proprio cambiate (in modo documentato ovviamente).

khelidan1980
24-04-2008, 13:16
se è per questo si può fare di peggio: hard-coded paths, "C:\Temp"... :Puke:



Allora c'è davvero qualcuno che lo fà!:eek: :p

^TiGeRShArK^
24-04-2008, 13:18
a proposito...
queste famose microsoft guidelines dove si trovano? :fagiano:

Ziosilvio
24-04-2008, 13:59
a cosa sono dovute queste incompatibilità?
A Vista.


















:D
Scherzi a parte:
Le API sono cambiate: estese o aggiunte, ma c'è compatibilità col passato.

Il problema, al solito, è che i programmatori non seguono tutte le direttive MS per la scrittura delle applicazioni.

Esempio minchione: usare la cartella in cui sta l'applicazione per memorizzare dati & informazioni. Appena passi a usare un utente limitato non ti funziona più perché non hai i privilegi per accedervi.

cdimauro
24-04-2008, 14:21
a proposito...
queste famose microsoft guidelines dove si trovano? :fagiano:
Le trovi su MSDN. :)

Ad esempio per recuperare il path corretto di Temp, Program Files, ecc., mi pare che ci sia una sezione apposita sull'argomento shell folder et similia. Onestamente al momento non ricordo con precisione perché è passato troppo da quando ho letto queste cose. :|

x Alberto. Vero :)

^TiGeRShArK^
24-04-2008, 16:07
Le trovi su MSDN. :)

Ad esempio per recuperare il path corretto di Temp, Program Files, ecc., mi pare che ci sia una sezione apposita sull'argomento shell folder et similia. Onestamente al momento non ricordo con precisione perché è passato troppo da quando ho letto queste cose. :|

x Alberto. Vero :)

Si, quelli li so ricavare, però volevo + che altro una guida sulle best-practices da tenere..
ad esempio con xp tenevo i file di configurazione sotto la cartella shared files, ma con Vista bisogna avere i permessi di amministratore per accedervi, allo stesso modo delle chiavi di registro hkey_localmachine/software ecc.. ecc...
qual'è il modo consigliato con Vista per salvare i file di configurazione in modo che siano condivisibili anche da un servizio? :fagiano:
Su msdn ho trovato un casino di link che poi alla fine ho scoperto che non c'entravano una mazza, per questo volevo sapere se ve lo ritrovavte sotto mano :p

cdimauro
27-04-2008, 08:48
Francamente non ne ho idea: quelle informazioni le ho recuperate mentre mi spulciavo le API di Windows, sezione per sezione. :|

DanieleC88
27-04-2008, 13:36
se è per questo si può fare di peggio: hard-coded paths, "C:\Temp"... :Puke:
Io Vista non l'ho ancora provato e quindi non mi permetto assolutamente di giudicarlo. Sta di fatto che ho sentito molte persone lamentarsi di qua e di là, ma già se Vista costringe ad evitare certa spazzatura, Vista++. :D

71104
27-04-2008, 14:09
Io Vista non l'ho ancora provato e quindi non mi permetto assolutamente di giudicarlo. Sta di fatto che ho sentito molte persone lamentarsi di qua e di là, ma già se Vista costringe ad evitare certa spazzatura, Vista++. :D non è che proprio lo impedisce del tutto, solo che i programmatori iniziano ad accorgersi delle porcate che hanno fatto grazie al fatto che ora i path predefiniti sono cambiati (e in meglio, oserei dire :D) e quindi quelli hard-coded spesso non funzionano più.

per evitare la spazzatura di cui sopra servirebbe che Microsoft cambiasse lo schema dei "well-known paths" ad ogni versione di Windows, e vedi allora che software pulito che iniziano a sfornare le terze parti :asd:

PS: scherzo, i path di Vista vanno benissimo :read:

nuovoUtente86
27-04-2008, 14:54
se è per questo si può fare di peggio: hard-coded paths, "C:\Temp"... :Puke:

comunque non sempre la retrocompatibilità viene mantenuta: in rarissimi casi certe semantiche vengono proprio cambiate (in modo documentato ovviamente).

Cosa sono gli hard-coded paths?
come mai è cosi grave utilizzare "c:\Temp"?

wizard1993
27-04-2008, 15:24
come mai è cosi grave utilizzare "c:\Temp"?

prova ad indovinare che cosa succede se io installo windows su d:\ e avarai la risposta

nuovoUtente86
27-04-2008, 16:13
prova ad indovinare che cosa succede se io installo windows su d:\ e avarai la risposta

Giusto....non avevo capito che alcuni utilizzassero direttamente il path assoluto.

71104
27-04-2008, 17:40
prova ad indovinare che cosa succede se io installo windows su d:\ e avarai la risposta oppure se non si ha il permesso di creare files e cartelle in C:\, cosa del tutto ragionevole dato che quella è la partizione di boot e io potrei tranquillamente voler negare permessi di scrittura e affini.

71104
27-04-2008, 17:42
Cosa sono gli hard-coded paths? quando un programma cerca di installarsi in "C:\Program Files\" (string literal scritto nei sorgenti, non modificabile) :muro:
oppure quando cerca di mettere la sua voce nel menu Start scrivendo un file in "C:\Documents and Settings\<Nome utente>\Start Menu\Programs" :muro: :muro:

nuovoUtente86
27-04-2008, 20:28
oppure se non si ha il permesso di creare files e cartelle in C:\, cosa del tutto ragionevole dato che quella è la partizione di boot e io potrei tranquillamente voler negare permessi di scrittura e affini.

be però negando completamente C:\ non si installa nulla praticamente, almeno che non si abbia una seconda partizione dove concedere l' accesso!Bloccando C:\ del resto non si accede neppure alla cartella programmi...non la vedo un qualcosa di utile da fare.

71104
27-04-2008, 21:16
be però negando completamente C:\ non si installa nulla praticamente, almeno che non si abbia una seconda partizione dove concedere l' accesso!Bloccando C:\ del resto non si accede neppure alla cartella programmi...non la vedo un qualcosa di utile da fare. ma un conto sono gli installers e un conto i programmi applicativi; se tu ti ritrovassi a regolare i permessi delle tue cartelle in maniera un minimo stretta concederesti permessi di vita e di morte su C:\ all'utente sotto cui gira il browser web, per dire? o magari Outlook Express?

nuovoUtente86
27-04-2008, 21:56
ma un conto sono gli installers e un conto i programmi applicativi; se tu ti ritrovassi a regolare i permessi delle tue cartelle in maniera un minimo stretta concederesti permessi di vita e di morte su C:\ all'utente sotto cui gira il browser web, per dire? o magari Outlook Express?

Vista per IE( non per gli altri browser) fa qualcosa di simile attraverso la modalità protetta!
In linea teorica hai ragione ma se andiamo a vedere nella pratica...sono 3 i punti principali dove i programmi piazzano i loro file e cartelle: sotto C:\, nella cartella programmi e sotto la home Utente....se gli impedissimo di poter accedere non potremmo alla fine utilizzarli, almen di sovrascrivere i permessi solo su determinate cartelle da concedere.

Relativamente ai path divergenti tra Xp e Vista mi sembra che Vista sia retrocompatibile nel senco che ad esempio mutua automaticamente da \Documents and Settings\nomeUtente in Utenti\nomeUtente

marco.r
28-04-2008, 00:52
Vista per IE( non per gli altri browser) fa qualcosa di simile attraverso la modalità protetta!
In linea teorica hai ragione ma se andiamo a vedere nella pratica...sono 3 i punti principali dove i programmi piazzano i loro file e cartelle: sotto C:\, nella cartella programmi e sotto la home Utente....se gli impedissimo di poter accedere non potremmo alla fine utilizzarli, almen di sovrascrivere i permessi solo su determinate cartelle da concedere.

Dovrebbero esistere solo due punti. La cartella programmi durante l'installazione, e la cartella dell'utente durante l'uso. Usare altri path per i dati vuol dire cercare rogne, e trovarle di sicuro non appena il computer lo usano due persone diverse.


Relativamente ai path divergenti tra Xp e Vista mi sembra che Vista sia retrocompatibile nel senco che ad esempio mutua automaticamente da \Documents and Settings\nomeUtente in Utenti\nomeUtente
Questa secondo me e' una porcata. Tra l'altro la fa anche XP se si cambiano i percorsi di default. Per inciso... ho fatto il downgrade di un portatile da Vista a XP perche' era parecchio inchiodato. Per pigrizia non ho formattato tutto "tanto", mi son detto, "Vista usa Users e Program Files, XP Documents and Settings e Programmi, per cui non ci dovrebbero essere problemi". Le ultime parole famose, mi son trovato i programmi installati in c:\Program Files e gli utenti in c:\Users. A livello di file system. Da explorer invece sembrava ci fossero i soliti c:\documents and settings e C:\programmi. LA cosa ha mandato in confusione piu' di un programma, ad esempio l'antivirus ha installato i file da una parte ma poi outlook cercava la dll dall'altra :muro:. Ho sistemato, ma che fatica ! :stordita:.

A meno che non sia l'utente a deciderlo e ad impostare i permessi opportunamente si intende.

nuovoUtente86
28-04-2008, 12:30
Dovrebbero esistere solo due punti. La cartella programmi durante l'installazione, e la cartella dell'utente durante l'uso. Usare altri path per i dati vuol dire cercare rogne, e trovarle di sicuro non appena il computer lo usano due persone diverse.
Se va direttamente sotto C:\ troverai diverse cartelle di applicativi..nel mio caso trovo dagli antivirus(log di KIS) al compilatore Dev c++(ha piazzato sotto C:\ direttamente il workspace) a together.Non so se si piazzino cosi per consentire a piu utenti l' utilizzo.


Questa secondo me e' una porcata. Tra l'altro la fa anche XP se si cambiano i percorsi di default. Per inciso... ho fatto il downgrade di un portatile da Vista a XP perche' era parecchio inchiodato. Per pigrizia non ho formattato tutto "tanto", mi son detto, "Vista usa Users e Program Files, XP Documents and Settings e Programmi, per cui non ci dovrebbero essere problemi". Le ultime parole famose, mi son trovato i programmi installati in c:\Program Files e gli utenti in c:\Users. A livello di file system. Da explorer invece sembrava ci fossero i soliti c:\documents and settings e C:\programmi. LA cosa ha mandato in confusione piu' di un programma, ad esempio l'antivirus ha installato i file da una parte ma poi outlook cercava la dll dall'altra :muro:. Ho sistemato, ma che fatica ! :stordita:.

A meno che non sia l'utente a deciderlo e ad impostare i permessi opportunamente si intende.

Intendi il fatto che XP lo faccia cambiando i percorsi di default attraverso il registro?
Come hai fatto ad installare Xp...lasciando le cartelle di Vista ovvero senza formattare?
Penso che la retrocompatibilità abbia un senso proprio per quei programmi che non pescano il path dal sistema ospite ma lo hanno mappato al loro interno in maniera assoluta.

71104
28-04-2008, 19:56
Penso che la retrocompatibilità abbia un senso proprio per quei programmi che non pescano il path dal sistema ospite ma lo hanno mappato al loro interno in maniera assoluta. quei programmi sono sbagliati, punto. e fanno anche schifo (Dev-C++ :Puke: omg, come se già non avessi abbastanza motivi per odiarlo)

dupa
28-04-2008, 21:36
io so solo che almeno con XP non c'è modo di spostare la Document and Settings... e mi sembra vergognoso.

71104
29-04-2008, 09:23
io so solo che almeno con XP non c'è modo di spostare la Document and Settings... e mi sembra vergognoso.
http://support.microsoft.com/kb/314843