No a Explorer, c'è la Francia

[ConteZero]

Ad oggi l'assenza di codici sorgenti ha un solo grande vantaggio... se rubi qualche tecnologia sotto patent e la implementi nel tuo codice in modo non visibile molto probabilmente non lo scoprirà mai nessuno.

[trallallero]

Originariamente inviato da cdimauro

No, quello è un altro tipo di lock (lock su risorsa).

Quello di cui parlavamo è un lock software, utilizzato nel codice per arbitrare l'accesso a una struttura dati in memoria.

Intendi i mutex ?
Boh, non ho più seguito la discussione quindi non so come siate arrivati a parlare di lock e perchè ...

Quello che posso dire su Windows è che in ditta vige la regola, e questa và rispettata senza se e senza ma: "non usare membri statici in C++ altrimenti su Windows potrebbe non funzionare".
Boh, io programmo per Linux ed è anni che non faccio codice per Win quindi non sono aggiornato, ma per l'ultima gui QT che ho fatto e che deve girare sia su Linux che su Win, mi è stato esplicitamente chiesto di evitare qualsiasi variabile statica, singletone etc.
Mi è stato detto da gente che ha fatto in C++ per Windows la gestione audio e video della simulazione per l'esercito tedesco, non da 4 novelli (nello stesso progetto io sono stato responsabile della gestione della logica e della comunicazione che gira su Linux tranquillamente con singletones).
Ovviamente non ho problemi ad evitare variabili statiche essendoci n modi per ottenere lo stesso risultato, ma la cosa mi ha fatto pensare ...

[AntonioBO]

Originariamente inviato da cdimauro

La fiera dei luoghi comuni.

Hai detto tu stesso che non hai competenze in materia, e continui a tirare fuori storie di s.o. che dovrebbero "sfiorare la perfezione" solo perché sarebbero a pagamento.

Non hai la minima idea di quel che sta dietro, fra teoria e pratica, alla scrittura del software, e ciononostante continui a parlare.

L'abbiamo capito che ti piace di più Linux perché è "gratis", "libero", e quello che vuoi tu, per quanto poco possano valere discorsi come questi che sono avulsi dal contesto e da una marea di considerazioni. E che Windows lo vedi come la peste perché "costa", è nelle mani del signore del male, ecc. ecc.

Adesso, cortesemente, potresti almeno riflettere sul "contributo" che stai dando alla discussione, e se non sia il caso di smettere di inquinare il thread con affermazioni che lasciano il tempo che trovano?

Grazie

Ovviamente io dico quello che voglio e non devo rendere conto a te per un beneamato cazzo di quello che penso. E soprattutto in una discussione che ho aperto io. Tu che contributo hai dato? Che Windows è il meglio del meglio? Cazzi tuoi che lo usi. E modera i toni !!! Non ho mai parlato nè di signore del male nè di altre cazzate al contrario di te!. Se pago qualcosa, non chiedo, MA PRETENDO che questa cosa funzioni e bene se no... che vada pure al diavolo . Che poi questa cosa che funziona poco bene venga imposta grazie a monopolio e ad un mercato non libero del software.. è un altro paio di maniche. Tienti i tuoi codici del piffero!!!

[cdimauro]

Originariamente inviato da ConteZero

Tu non sei Microsoft...

Vero, ma ho espresso soltanto il mio giudizio.

quello che segue la progettazione dell'XBox 360 (specie sul versante sicurezza) è stato attentamente esaminato da ben più che un gruppo d'analisti di codice.

I documenti li ho letti, e a maggior ragione mi sono fatto quell'idea.

Per Microsoft PPC è un architettura nuova.

Direi di no, visto che IE e Office li ha sviluppati anche per Mac, quando questi ancora usavano i PPC e non gli x86.

Quindi da un po' di anni hanno gente con esperienza sui PPC, in particolare nella sezione compilatori (per il back-end che emette codice).

Basta che il compilatore, non abbastanza sveglio, riceva dal sorgente un dato a 32 bit.
Se poi l'exception entry point è scritto in un codice ed il gestore delle syscall è scritto in un altro codice (es perché se ne occupavano "squadre" diverse) è facile che la compilazione sia "differita" e l'ambiguità non sia "saltata all'occhio".

Non credo, proprio perché il dato che riceve la syscall è di un unico tipo: o è a 32 bit, o è a 64 bit.

Nell'esempio evidenziato che porta all'exploit, lo stesso registro viene usato prima a 32 bit, e poi a 64 bit.

Differenze così grossolane sono praticamente impossibili per un compilatore.

Originariamente inviato da Unrue

Ma scusami, se un codice è sotto gli occhi di migliaia di persone, è molto più probabile trovare un bug e correggerlo. Se invece è sotto gli occhi di pochi sviluppatori, allora le probabilità diminuiscono. Questo non significa ovviamente che il codice open source sia perfetto, ma che la tempistica di correzione dei bug è potenzialmente molto più veloce. Se tu sviluppi un progetto ma tieni i codici tutti per te, solo tu puoi scovare i bug da codice e correggerli, se li condividi con altri, molte altre persone possono trovare un bug e segnalarlo.

Questo perché presupponi che le persone che analizzano il codice abbia tutte le medesime skill, e soprattutto che i bug siano distribuiti in maniera abbastanza "omogenea". Inoltre che i bug richiedano tutti il medesimo impegno per il loro rilevamento.

Tutte ipotesi che non reggono.

Se è open source e non lo espone, non è open source..

Appunto: possiamo considerarlo "closed", ma l'esempio che ho citato serve a 2 cose.

La prima a mostrare che il modello open source non è migliore di quello closed relativamente alla sicurezza (altro esempio: ho un sistema d'allarme eccezionale, e sono talmente convinto della sua sicurezza che attaccato alla porta lascio il suo schema completo per farlo esaminare dai ladri ).
Ovviamente non significa che quello closed sia meglio.

La seconda è che la differenza fra closed e open è molto sottile, visto che entrambe le centrali nucleari alla fine utilizzano esattamente lo stesso codice (non tenendo conto dell'offuscamento delle scritte), e che il semplice non rilasciare i sorgenti cambi completamente lo scenario.

Originariamente inviato da ConteZero

Ad oggi l'assenza di codici sorgenti ha un solo grande vantaggio... se rubi qualche tecnologia sotto patent e la implementi nel tuo codice in modo non visibile molto probabilmente non lo scoprirà mai nessuno.

Lo stesso si può dire dei bug, allora.

Originariamente inviato da trallallero

Intendi i mutex ?
Boh, non ho più seguito la discussione quindi non so come siate arrivati a parlare di lock e perchè ...

Sì, i mutex fanno parte della famiglia.

I lock li ha citati ConteZero in un messaggio.

Quello che posso dire su Windows è che in ditta vige la regola, e questa và rispettata senza se e senza ma: "non usare membri statici in C++ altrimenti su Windows potrebbe non funzionare".
Boh, io programmo per Linux ed è anni che non faccio codice per Win quindi non sono aggiornato, ma per l'ultima gui QT che ho fatto e che deve girare sia su Linux che su Win, mi è stato esplicitamente chiesto di evitare qualsiasi variabile statica, singletone etc.
Mi è stato detto da gente che ha fatto in C++ per Windows la gestione audio e video della simulazione per l'esercito tedesco, non da 4 novelli (nello stesso progetto io sono stato responsabile della gestione della logica e della comunicazione che gira su Linux tranquillamente con singletones).
Ovviamente non ho problemi ad evitare variabili statiche essendoci n modi per ottenere lo stesso risultato, ma la cosa mi ha fatto pensare ...

Francamente non ho idea del perché non debbano essere usati. Dico: non mi capacito della motivazione tecnica che sta alla base di questa scelta.

Io non mi sono mai fatto problemi a utilizzare membri statici, quando m'è servito.

Passi per il pattern Singleton, che viene visto come il male da molti programmatori, ma per il resto i membri statici vengono utilizzati in maniera utile in alcuni pattern.

Originariamente inviato da AntonioBO

Ovviamente io dico quello che voglio e non devo rendere conto a te per un beneamato cazzo di quello che penso.

Laurea a Oxford immagino.

E soprattutto in una discussione che ho aperto io.

Questo non te ne dà automaticamente la proprietà.

Tu che contributo hai dato?

Lo puoi leggere nei miei messaggi precedenti.

Che Windows è il meglio del meglio?

Mai detto questo.

Cazzi tuoi che lo usi.

Ci mancherebbe che dovessi privarmi di uno strumento per questioni ideologiche e non tecniche.

E modera i toni !!!

Non confondere la critica, anche dura, con la mancanza di rispetto nei confronti dell'interlocutore.

Nel mio caso si applica la prima. Nel tuo la seconda.

Non ho mai parlato nè di signore del male nè di altre cazzate al contrario di te!.

Hai parlato di "software quasi perfetto". Adesso te lo rimangi?

Se pago qualcosa, non chiedo, MA PRETENDO che questa cosa funzioni e bene

Col software puoi metterti l'anima in pace: che tu abbia pagato o meno, è praticamente impossibile essere sicuri che sia esente da difetti.

se no... che vada pure al diavolo .

In tal caso non vedo perché ti lamenti: tanto tu mica lo compri, no?

Che poi questa cosa che funziona poco bene venga imposta grazie a monopolio e ad un mercato non libero del software.. è un altro paio di maniche.

Sì, e sono sicuramente le maniche sbagliate. Di chi nemmeno conosce la definizione di monopolio, e la usa riportando la classica leggenda metropolitana di MS brutta, cattiva, e monopolista, che impone Windows a tutti.

Tienti i tuoi codici del piffero!!!

Ma certamente. E tu tieniti le tue considerazioni che di tecnico non hanno nemmeno l'ombra, e che purtroppo elargisci erroneamente al mondo intero.

[AntonioBO]

Originariamente inviato da cdimauro

Vero, ma ho espresso soltanto il mio giudizio.

I documenti li ho letti, e a maggior ragione mi sono fatto quell'idea.

Direi di no, visto che IE e Office li ha sviluppati anche per Mac, quando questi ancora usavano i PPC e non gli x86.

Quindi da un po' di anni hanno gente con esperienza sui PPC, in particolare nella sezione compilatori (per il back-end che emette codice).

Non credo, proprio perché il dato che riceve la syscall è di un unico tipo: o è a 32 bit, o è a 64 bit.

Nell'esempio evidenziato che porta all'exploit, lo stesso registro viene usato prima a 32 bit, e poi a 64 bit.

Differenze così grossolane sono praticamente impossibili per un compilatore.

Questo perché presupponi che le persone che analizzano il codice abbia tutte le medesime skill, e soprattutto che i bug siano distribuiti in maniera abbastanza "omogenea". Inoltre che i bug richiedano tutti il medesimo impegno per il loro rilevamento.

Tutte ipotesi che non reggono.

Appunto: possiamo considerarlo "closed", ma l'esempio che ho citato serve a 2 cose.

La prima a mostrare che il modello open source non è migliore di quello closed relativamente alla sicurezza (altro esempio: ho un sistema d'allarme eccezionale, e sono talmente convinto della sua sicurezza che attaccato alla porta lascio il suo schema completo per farlo esaminare dai ladri ).
Ovviamente non significa che quello closed sia meglio.

La seconda è che la differenza fra closed e open è molto sottile, visto che entrambe le centrali nucleari alla fine utilizzano esattamente lo stesso codice (non tenendo conto dell'offuscamento delle scritte), e che il semplice non rilasciare i sorgenti cambi completamente lo scenario.

Lo stesso si può dire dei bug, allora.

Sì, i mutex fanno parte della famiglia.

I lock li ha citati ConteZero in un messaggio.

Francamente non ho idea del perché non debbano essere usati. Dico: non mi capacito della motivazione tecnica che sta alla base di questa scelta.

Io non mi sono mai fatto problemi a utilizzare membri statici, quando m'è servito.

Passi per il pattern Singleton, che viene visto come il male da molti programmatori, ma per il resto i membri statici vengono utilizzati in maniera utile in alcuni pattern.

Laurea a Oxford immagino.

Questo non te ne dà automaticamente la proprietà.

Lo puoi leggere nei miei messaggi precedenti.

Mai detto questo.

Ci mancherebbe che dovessi privarmi di uno strumento per questioni ideologiche e non tecniche.

Non confondere la critica, anche dura, con la mancanza di rispetto nei confronti dell'interlocutore.

Nel mio caso si applica la prima. Nel tuo la seconda.

Hai parlato di "software quasi perfetto". Adesso te lo rimangi?

Col software puoi metterti l'anima in pace: che tu abbia pagato o meno, è praticamente impossibile essere sicuri che sia esente da difetti.

In tal caso non vedo perché ti lamenti: tanto tu mica lo compri, no?

Sì, e sono sicuramente le maniche sbagliate. Di chi nemmeno conosce la definizione di monopolio, e la usa riportando la classica leggenda metropolitana di MS brutta, cattiva, e monopolista, che impone Windows a tutti.

Ma certamente. E tu tieniti le tue considerazioni che di tecnico non hanno nemmeno l'ombra, e che purtroppo elargisci erroneamente al mondo intero.

Se volevo aprire un thread tecnico non lo aprivo qui in storia politica e attualità, ma nella sezione appropriata. Quindi se vuoi parlare di codici e altre amenità, sloggia e vai nella sezione adatta. E impara anche a leggere con attenzione quello che scrivo e quello che non scrivo!!!

[cdimauro]

Originariamente inviato da AntonioBO

Se volevo aprire un thread tecnico non lo aprivo qui in storia politica e attualità, ma nella sezione appropriata.

Che ha implicazioni tecniche.

Quindi se vuoi parlare di codici e altre amenità, sloggia e vai nella sezione adatta.

Lo faccio già.

E impara anche a leggere con attenzione quello che scrivo e quello che non scrivo!!!

Lo faccio già, e ti ho risposto di conseguenza.

[trallallero]

Originariamente inviato da cdimauro

Francamente non ho idea del perché non debbano essere usati. Dico: non mi capacito della motivazione tecnica che sta alla base di questa scelta.

Io non mi sono mai fatto problemi a utilizzare membri statici, quando m'è servito.

Passi per il pattern Singleton, che viene visto come il male da molti programmatori, ma per il resto i membri statici vengono utilizzati in maniera utile in alcuni pattern.

Boh, ho dato per curiosità un'occhiata in rete e la MS spiega come implementare i singletons su Windows, quindi pare sia possibile.
Il problema che abbiamo avuto coi membri statici (e da quì i singletons) è uscito fuori quando dovevamo instanziare più applicazioni che usano la stessa libreria dll: i membri statici della libreria rimanevano statici per tutte le librerie aperte ovvero, se modificavi il valore di un membro statico da una libreria, tutte le librerie leggevano il medesimo valore. Ovviamente la cosa era rischiosissima per la mancanza di mutex sui membri statici con relativi crash delle applicazioni, ma ovviamente anche senza crash il risultato non era quello desiderato. Da li la regola ferrea in ditta di non usare membri statici ...
Comunque chiudo l'OT, non voglio continuare sul tecnico perchè vedo che state già litigando proprio per questo motivo

[cdimauro]

Ho capito il tuo problema, ma per le DLL il discorso è diverso. A parte il fatto che, per come lo hai descritto, mi sembra che il membro statico si comporti come da manuale, è possibile ricorrere ai mutex.

In ogni caso è anche possibile, se non ricordo male, avere memoria non condivisa (quindi "locale") nelle DLL per tutte le applicazioni che ne fanno uso.

Chiudo qui anch'io, che siamo andati un po' troppo OT.

[trallallero]

Originariamente inviato da cdimauro

Ho capito il tuo problema, ma per le DLL il discorso è diverso. A parte il fatto che, per come lo hai descritto, mi sembra che il membro statico si comporti come da manuale, è possibile ricorrere ai mutex.

Beh direi proprio di no, a meno che la MS abbia i suoi manuali personalizzati.
La memoria è condivisa tra l'applicazione e la libreria, non tra le applicazioni e le librerie anche se queste si chiamano allo stesso modo.
X.exe utilizza Y.dll ma non dovrebbe avere niente a che fare con Z.exe che utilizza Y.dll.

[cdimauro]

Uomo di poca fede: Using Shared Memory in a Dynamic-Link Library

[ConteZero]

Ho abbandonato perché i post sono diventati troppo lunghi da leggere.
Ci tenevo solo a dire che i bug oramai vengono spesso usati per riconoscere una violazione di copyright
Ne sanno qualcosa quelli del Popcornhour, che hanno visto "smascherato" il loro media player come un implementazione "non free" di MPlayer proprio perché con determinati tipi di filmato c'erano dei difetti tipici di alcuni bug presenti (e mai risolti in quanto "poco importanti") nell'mplayer.

[trallallero]

Originariamente inviato da cdimauro

Uomo di poca fede: Using Shared Memory in a Dynamic-Link Library

Che questo sia possibile mi sembra buono, che sia il comportamento di default non tanto ...
Comunque sicuramente è possibile ma con la MS bisogna fare a modo suo e probabilmente questo modo non lo conosciamo. Quello che mi sembra strano è che ci sia ancora questa regola in ditta nonostante la presenza di esperti Windows (oddio, la nostra parte, gruppo communicazione, ha passato il test mentre la loro ... ehm ... progetto rinviato di 6 mesi per colpa loro, forse quell'"esperti" va un pò rivalutato )

[cdimauro]

Originariamente inviato da trallallero

Che questo sia possibile mi sembra buono, che sia il comportamento di default non tanto ...

Mumble. E perché? Per me è giusto che, di default, una DLL utilizzi lo spazio d'indirizzamento dell'applicazione che la usa.

In questo modo vengono completamente isolate le applicazioni, e la DLL usata soltanto per usufruire delle API che si porta dietro. Il vantaggio ulteriore è che il sistema è molto più stabile e sicuro.

Comunque sicuramente è possibile ma con la MS bisogna fare a modo suo e probabilmente questo modo non lo conosciamo.

Mi sembra anche normale: una DLL non è una shared library dei sistemi Unix.

Ogni s.o. ha le proprie peculiarità, che andrebbero conosciute e sfruttate.

Quello che mi sembra strano è che ci sia ancora questa regola in ditta nonostante la presenza di esperti Windows (oddio, la nostra parte, gruppo communicazione, ha passato il test mentre la loro ... ehm ... progetto rinviato di 6 mesi per colpa loro, forse quell'"esperti" va un pò rivalutato )

"Tu l'hai detto".

Anche perché, oggettivamente, se hai studiato il funzionamento delle DLL, son tutte cose che dovresti sapere (non dico a te, ma parlo degli "esperti").
Io quel link te l'ho recuperato in 2 secondi netti, ma perché sapevo già cosa cercare: ero sicurissimo che si poteva condividere memoria fra le DLL, perché anni fa qualcosina l'avevo studiata sull'argomento.

[ConteZero]

Originariamente inviato da cdimauro

Anche perché, oggettivamente, se hai studiato il funzionamento delle DLL, son tutte cose che dovresti sapere (non dico a te, ma parlo degli "esperti").
Io quel link te l'ho recuperato in 2 secondi netti, ma perché sapevo già cosa cercare: ero sicurissimo che si poteva condividere memoria fra le DLL, perché anni fa qualcosina l'avevo studiata sull'argomento.

Mi sono appena beccato una sassata in faccia
Perché fare una cosa così orribile come condividere la memoria fra diverse "istanze" della stessa DLL ?
Se c'è da gestire una risorsa non preemptable bisognerebbe usare un manager o qualcosa del genere... brrr, che brutta cosa che hai detto

[cdimauro]

Dipende dalle esigenze. Se serve condividerla, i mezzi ci sono, e sono meglio che niente.

Comunque, onestamente non m'è mai capitato. Si vede che sono fortunato, e le sassate per ora me le sono risparmiate.

[gugoXX]

Il codice di una DLL viene caricato una volta sola, anche se usata piu' volte da piu' programmi.
In questo senso la memoria e' condivisa. L'indirizzo fisico e' uguale, sono diversi gli indirizzi virtuali.
Ma immagino non steste parlando della memoria codice ma bensi' quella dato.

Comunque si'. Mi pare un po' off-topic.

Peraltro ultimamente ho dovuto installare Chrome perche' firefox e' affetto da rallentamenti senza senso. Si blocca e riparte all'improvviso. (Ho antivirus, ad-aware e compagnia danzante)

[trallallero]

@cdimauro:
Probabilmente parlo arabo allora perchè noi NON volevamo condividere memoria fra le DLL come ci si aspetta che faccia una dynamic link library caricata da un eseguibile.
Se vuoi che le applicazioni possano comunicare utilizzi shm (come facciamo noi), ipc o quello che vuoi, ma non certo mettendo di default la libreria condivisa.
A parte che non mi sembra il caso della MS perchè dal tuo link ho capito che lo devi specificare se vuoi condivisione, ma magari questa è una feature nuova. Perchè il nostro problema risale a 3 anni fa.

E comunque vedo che hai preso la palla al balzo
gli "esperti" li ho canzonati, è vero, ma sono comunque 3 ragazzi che hanno messo su una simulazione da paura (immagina 2 carroarmati virtuali che hanno una visione 3d dello scenario grazie ai proiettori - da gestire via software -, con tanto di specchietti retrovisori - un monitor per ogni specchietto da gestire via software - qualche finestrino - un monitor per ogni finestrino da gestire via software - aerei che passano - gestire l'audio, etc ...).

[ConteZero]

Originariamente inviato da gugoXX

Il codice di una DLL viene caricato una volta sola, anche se usata piu' volte da piu' programmi.
In questo senso la memoria e' condivisa. L'indirizzo fisico e' uguale, sono diversi gli indirizzi virtuali.
Ma immagino non steste parlando della memoria codice ma bensi' quella dato.

Comunque si'. Mi pare un po' off-topic.

Peraltro ultimamente ho dovuto installare Chrome perche' firefox e' affetto da rallentamenti senza senso. Si blocca e riparte all'improvviso. (Ho antivirus, ad-aware e compagnia danzante)

Si, il codice della libreria viene caricata una volta sulla memoria fisica, dopodiché le pagine che la contengono vengono mappate nello spazio d'indirizzamento dei progammi che la richiedono (che quindi possono accedere alle funzioni offerte tramite delle normalissime CALL).
Il punto è... perché una DLL dovrebbe avere un area dati SUA condivisa fra tutte le istanze ?
Una ragione plausibile è per gestire una risorsa non preemptable, ad esempio (beh, è un esempio) un driver stampante... ma a quel punto è più pratico usare un manager e mettere nella DLL solo l'interfaccia di comunicazione col manager stesso.
Ad occhio e croce sembra l'equivalente delle librerie dinamiche di linux + shm...

[cdimauro]

Originariamente inviato da trallallero

@cdimauro:
Probabilmente parlo arabo allora perchè noi NON volevamo condividere memoria fra le DLL come ci si aspetta che faccia una dynamic link library caricata da un eseguibile.
Se vuoi che le applicazioni possano comunicare utilizzi shm (come facciamo noi), ipc o quello che vuoi, ma non certo mettendo di default la libreria condivisa.
A parte che non mi sembra il caso della MS perchè dal tuo link ho capito che lo devi specificare se vuoi condivisione, ma magari questa è una feature nuova. Perchè il nostro problema risale a 3 anni fa.

No, è cosa abbastanza vecchia.

E comunque vedo che hai preso la palla al balzo
gli "esperti" li ho canzonati, è vero, ma sono comunque 3 ragazzi che hanno messo su una simulazione da paura (immagina 2 carroarmati virtuali che hanno una visione 3d dello scenario grazie ai proiettori - da gestire via software -, con tanto di specchietti retrovisori - un monitor per ogni specchietto da gestire via software - qualche finestrino - un monitor per ogni finestrino da gestire via software - aerei che passano - gestire l'audio, etc ...).

E però tu li chiami esperti, ma non sanno come funzionano le DLL... permettimi di bacchettarli.

Sul loro lavoro nulla da dire, ma non era questo in discussione, quanto le loro affermazioni sul funzionamento delle DLL.

[trallallero]

Originariamente inviato da cdimauro

Sul loro lavoro nulla da dire, ma non era questo in discussione, quanto le loro affermazioni sul funzionamento delle DLL.

Ok, domani lo chiedo direttamente con loro (gli "esperti").