Domanda C++ e i programmi in finestre...

Stato
Discussione chiusa ad ulteriori risposte.

Kepha

Utente Electrum
12 Aprile 2012
204
34
19
122
Salve ragazzi, non programmo in c++ da circa un anno (male, maliiiisssimo!) e sto cercando di riprendere i concetti fondamentali, le varie funzioni etc.
Però ho da sempre un dubbio: come faccio a creare programmi che sia possibile aprire in finestre su windows e non nella finestra dos?
C'è una libreria apposita o dovrei cominciare a pensare di cambiare linguaggio di programmazione (magari ce n'è uno più semplice su questo punto di vista).
Ah, uso codeblocks...
 
Ci sono librerie apposite per creare le GUI (es GTK+ o le Qt)
Oppure trovi dei tool(designer) appositi per fare le GUI da introdurre poi nei tuoi progetti.

Linguaggi come c#, VB.NET,
Java ti semplificano la vita sotto questo punto di vista

Sent from my LG-D802 using Tapatalk
 
Se vuoi facilitarti la vita(per creare GUI)ti consiglio Java,linguaggio molto potente,multipiattaforma e con uno strumento per la creazione di interfaccie grafiche davvero molto semplice da usare.

Inviato dal mio GT-I9195 utilizzando Tapatalk
 
  • Mi piace
Reazioni: Kepha
Però ho da sempre un dubbio: come faccio a creare programmi che sia possibile aprire in finestre su windows e non nella finestra dos?
Quello non è il DOS, ma semplicemente il prompt dei comandi. Una specie di emulatore di terminale fatto male. Il DOS è un vecchio sistema operativo, e non c'entra nulla.
Sotto Windows, è possibile creare interfacce grafiche sia utilizzando librerie esterne di terze parti (GTK+, QT, ecc.) sia utilizzando le Windows API. Windows infatti fornisce un intero set di API built-in nel sistema operativo per creare interfacce grafiche. Qui puoi trovare una guida alla creazione di interfacce grafiche con la WinAPI: http://www.winprog.org/tutorial/start.html La guida è ricca di esempi, tutti in C/C++.
Se invece vuoi usare altre librerie grafiche, ogni libreria ha la sua documentazione che puoi trovare sul web.

Se stai studiando questo per un qualche progetto per Windows allora ok. Ma se stai semplicemente studiando programmazione per interesse personale, ti consiglio fortemente di evitare la programmazione sotto Microsoft Windows e di iniziare invece a lavorare con Unix/Linux. Windows ti farà perdere molto tempo inutile. Per sapere perché, i testi come "How to become an hacker" e "The Art of Unix Programming" di Eric Raymond possono spiegartelo.
 
Ti serve una libreria per le gui, ti consiglio QT/Wx.
Ti sconsiglio lo studio delle gui sfruttando le api di windows poichè è abbastanza complesso
 
  • Mi piace
Reazioni: Kepha
Vi ringrazio tutti e 4.Credo che seguirò il consiglio di imparare il Java. Il c++ l'ho usato un anno fa solo a scopo didattico.
Non ho un progetto in mente, voglio solo imparare a creare programmi che posso far utilizzare a chiunque.
Una guida per Java?
 
Vi ringrazio tutti e 4.Credo che seguirò il consiglio di imparare il Java. Il c++ l'ho usato un anno fa solo a scopo didattico.
Non ho un progetto in mente, voglio solo imparare a creare programmi che posso far utilizzare a chiunque.
Una guida per Java?
Io non ti volevo indirizzare a questo linguaggio per forza. [emoji6]
Comunque io ho iniziato a imparare le basi(fino alla programmazione ad oggetti) con dei video tutorial, poi successivamente sono passato all'acquisto di un buon libro specifico a quello che volevo fare io,un manuale è comunque meglio rispetto a dei tutorial in quanto rimane fisicamente con te e puoi dargli un'occhiata anche mentre ti eserciti.
Comunque io,se fossi in te,darei un'occhiata anche al C++,con esso ci puoi fare progetti più in grande(videogiochi per esempio)...fai tu.


Inviato dal mio GT-I9195 utilizzando Tapatalk
 
  • Mi piace
Reazioni: Kepha
Salve ragazzi, non programmo in c++ da circa un anno (male, maliiiisssimo!) e sto cercando di riprendere i concetti fondamentali, le varie funzioni etc.
Però ho da sempre un dubbio: come faccio a creare programmi che sia possibile aprire in finestre su windows e non nella finestra dos?
C'è una libreria apposita o dovrei cominciare a pensare di cambiare linguaggio di programmazione (magari ce n'è uno più semplice su questo punto di vista).
Ah, uso codeblocks...
Ti consiglio anche io di evitare di lavorare sotto Microsoft Windows e di dedicarsi a qualcosa migliore "Linux/Unix"
 
Se stai studiando questo per un qualche progetto per Windows allora ok. Ma se stai semplicemente studiando programmazione per interesse personale, ti consiglio fortemente di evitare la programmazione sotto Microsoft Windows e di iniziare invece a lavorare con Unix/Linux. Windows ti farà perdere molto tempo inutile. Per sapere perché, i testi come "How to become an hacker" e "The Art of Unix Programming" di Eric Raymond possono spiegartelo.
Un riassunto per chi non ha letto questi libri?
 
  • Mi piace
Reazioni: RiperRotten
Io non ti volevo indirizzare a questo linguaggio per forza. [emoji6]
Comunque io ho iniziato a imparare le basi(fino alla programmazione ad oggetti) con dei video tutorial, poi successivamente sono passato all'acquisto di un buon libro specifico a quello che volevo fare io,un manuale è comunque meglio rispetto a dei tutorial in quanto rimane fisicamente con te e puoi dargli un'occhiata anche mentre ti eserciti.
Comunque io,se fossi in te,darei un'occhiata anche al C++,con esso ci puoi fare progetti più in grande(videogiochi per esempio)...fai tu.


Inviato dal mio GT-I9195 utilizzando Tapatalk

Ma comunque cerco un linguaggio di programmazione generale.Il c++ lo conosco poco. Forse lo approfondisco e intanto compro un buon manuale per java. Consigliate un buon libro?
 
Di evitare la programmazione sotto Microsoft Windows e di iniziare invece a lavorare con Unix/Linux in poche parole è una scelta saggia visto è molto migliore Linux.
Potrei anche essere d'accordo con la tua affermazione, ma io ho esplicitamente chiesto di motivarla.

BTW: Unix/Linux è un po' come dire DOS/Windows. Unix è un vecchio sistema operativo (closed source) da cui Linux prende ispirazione per alcuni concetti molto generali. Probabilmente quello che vorresti scrivere è GNU/Linux, ovvero kernel linux + GNU toolchain.

Ma comunque cerco un linguaggio di programmazione generale.Il c++ lo conosco poco. Forse lo approfondisco e intanto compro un buon manuale per java. Consigliate un buon libro?
http://www.inforge.net/xi/resources...i-linguaggi-di-programmazione-scripting.2455/
Con il tasto cerca ne trovi molte altre discussioni. Praticamente la metà delle domande che si fanno in queste sezioni riguardano la scelta del libro/manuale/guida o del linguaggio da cui partire.
 
  • Mi piace
Reazioni: CrashTest e Kepha
Un riassunto per chi non ha letto questi libri?
Windows è un prodotto che è designato per l'utente, non per lo sviluppatore. Si consideri ad esempio la metafora unificante di Unix "everything is a file" - Windows non ha niente di questo tipo, ogni cosa è vista come qualcosa di diverso e separato da tutte le altre cose: una stampante è una stampante, il monitor è un monitor, ecc. Unix a differenza cerca di astrarre ogni cosa nel singolo concetto di "file". Windows risulta sicuramente più chiaro e semplice ad un utente finale, ma non ad uno sviluppatore. Un programmatore Windows è infatti costretto a imparare funzioni API diverse, metodi diversi, ognuno che serve a fare una cosa diversa: quando il programmatore ha imparato a sviluppare un software che scriva su schermo ha imparato una cosa - quando dovrà invece stampare con la stampante, sarà costretto a ricominciare da capo e imparare altri metodi, altre funzioni. Sotto Unix/Linux, si può fare quasi ogni cosa semplicemente con "open", "read", "write" e "close". Una volta che il programmatore ha imparato a leggere e scrivere sui file, sa già fare tante cose.
Questa non è l'unica conseguenza della mancanza di metafore unificanti: queste metafore sopravvivono oltre le versioni dei sistemi operativi. "Everything is a file" di Unix esisteva già negli anni '70, quando Unix è stato creato - ed esiste ancora oggi. Windows, non avendo delle metafore centrali, ad ogni aggiornamento rende obsolete buona parte delle tecnologie sviluppate nel kernel - ogni nuova generazione Windows obbliga gli sviluppatori a imparare nuove cose, talvolta fondamentali, perché quelle vecchie sono state dichiarate obsolete e non più supportate.
Un altro esempio sono i socket: la programmazione di applicazioni che comunicano sulla rete è molto più complicata in Windows che in Unix, dove è semplice come scrivere e leggere su file.
A questo si può aggiungere che Windows non dispone di un vero e proprio terminale. La sua CLI è povera. La CLI è importante ad esempio per poter avere un linguaggio di scripting per l'amministrazione di sistema (si vedano bash e batch). Inoltre non è possibile, in modo facile, combinare tra loro i programmi: per far collaborare più programmi è necessario, su Windows, fare uso di complicate chiamate RPC o funzioni API. In Unix/Linux, è sufficiente scrivere/leggere stdout/stdin. Certo, non che sia impossibile in Windows, ma la CLI di Windows offre molto molto di meno. Windows da importanza all'interfaccia grafica. Questo porta anche allo sviluppo di programmi molto complessi, che cercando di "fare tutto" - software più instabili e utilizzabili solo dall'utente finale, non da altri software.
Anche altre scelte di design di Windows possono causare problemi: ad esempio il registro di sistema centralizzato. Un errore di un'applicazione che corrompe il registro può causare anche gravi danni. Inoltre, più il registro di sistema cresce, più pesante diventano le operazioni di accesso e scrittura.
Windows non ha un corretto sistema di gestione dei permessi: cosa che rende più difficile la sicurezza del sistema e anche delle applicazioni. Il programmatore perde molto tempo nel mettere in sicurezza il proprio software (e spesso neanche ce lo perde, il che è peggio).
Windows non segue un metodo adeguato per il 'versioning' delle librerie. Questo fa si che i programmi sono costretti ad utilizzare specifiche versioni delle librerie e, chi installa questi software, vede aggiornamenti (o downgrade) praticamente random delle librerie.
Lo stesso sistema operativo è più instabile: Microsoft pensa di ridurre la complessità di un kernel progettandolo come kernel ibrido o come micro-kernel. In realtà, in questo modo, si finisce esclusivamente per complicare ulteriormente il sistema - un kernel che ha tanti moduli che devono comunicare tra loro, anche se questi moduli sono molto più semplici che in un kernel monolitico, farli comunicare tra loro non è così facile. I comunissimi BSOD di Windows possono dimostrarlo.
Inoltre, il mondo Windows è dominato dal closed-source, a partire dal sistema operativo. è importante, per un programmatore, studiare anche il codice altrui per imparare. E magari modificarlo e migliorarlo. Oppure per non dover reinventare la ruota ogni volta che si presenta un problema. Su Linux è open pure il sistema operativo stesso. Se qualcosa non funziona, si può andare anche a vedere, direttamente nel codice, il perché. Su Windows... reverse engineering oppure ti affidi a Microsoft.
BTW: Unix/Linux è un po' come dire DOS/Windows. Unix è un vecchio sistema operativo (closed source) da cui Linux prende ispirazione per alcuni concetti molto generali. Probabilmente quello che vorresti scrivere è GNU/Linux, ovvero kernel linux + GNU toolchain.
Quando scrivo "Unix" o "Unix/Linux" parlo di cose che esistevano già in Unix e sono derivate in Linux. Linux ha preso molto da Unix.
Di evitare la programmazione sotto Microsoft Windows e di iniziare invece a lavorare con Unix/Linux in poche parole è una scelta saggia visto è molto migliore Linux.
Questa non è un'argomentazione molto forte. In realtà "migliore", bisogna vedere in cosa. Personalmente ritengo migliore Linux di Windows in tante cose, ma sicuramente non in tutte (è abbastanza difficile direi creare un sistema operativo che sia il peggiore in *ogni* cosa... bhé se si escludono i "sistemi operativi" in VB.NET degli script-kiddies di Sciax2). Imho però, è senz'altro migliore per uno sviluppatore.
 
@SpeedJack: su diversi punti non sono d'accordo, ma mi fa piacere avere una risposta completa piuttosto che una risposta che rimanda a risorse di una lunghezza improponibile per una semplice discussione da forum.
Se qualcuno fosse interessato a cosa (e perché) non sono d'accordo tra i punti da te elencati posso argomentare anch'io, altrimenti evito di andare off-topic.
 
@SpeedJack: su diversi punti non sono d'accordo, ma mi fa piacere avere una risposta completa piuttosto che una risposta che rimanda a risorse di una lunghezza improponibile per una semplice discussione da forum.
Se qualcuno fosse interessato a cosa (e perché) non sono d'accordo tra i punti da te elencati posso argomentare anch'io, altrimenti evito di andare off-topic.

Scrivi pure... Sono interessato

Sent from my LG-D802 using Tapatalk
 
Si consideri ad esempio la metafora unificante di Unix "everything is a file" - Windows non ha niente di questo tipo, ogni cosa è vista come qualcosa di diverso e separato da tutte le altre cose: una stampante è una stampante, il monitor è un monitor, ecc. Unix a differenza cerca di astrarre ogni cosa nel singolo concetto di "file". Windows risulta sicuramente più chiaro e semplice ad un utente finale, ma non ad uno sviluppatore. Un programmatore Windows è infatti costretto a imparare funzioni API diverse, metodi diversi, ognuno che serve a fare una cosa diversa: quando il programmatore ha imparato a sviluppare un software che scriva su schermo ha imparato una cosa - quando dovrà invece stampare con la stampante, sarà costretto a ricominciare da capo e imparare altri metodi, altre funzioni. Sotto Unix/Linux, si può fare quasi ogni cosa semplicemente con "open", "read", "write" e "close". Una volta che il programmatore ha imparato a leggere e scrivere sui file, sa già fare tante cose.
Un altro esempio sono i socket: la programmazione di applicazioni che comunicano sulla rete è molto più complicata in Windows che in Unix, dove è semplice come scrivere e leggere su file.

In Windows si tende a dire "everything is an object", anche se più precisamente si dovrebbe dire "every resource is an object": un file è un oggetto, così come un socket o un thread. Se vuoi comunicare
con quella risorsa richiedi un handle e hai potenzialmente qualcosa di più avanzato di un semplice stream di byte.

Hai detto che su Linux una volta che sai leggere e scrivere su file sai già fare molto, e hai fatto l'esempio della stampante. Bene, io non ho la minima idea su come usare la stampante. Tra tutte le cose
che bisogna fare, inviare i byte alla stampante è l'ultimo problema che mi pongo. A dire il vero su Linux c'è CUPS per astrarre le read/write sulla stampante e nessuno mi garantisce che la distro XYZ lo
utilizzi al posto di LPRng o chessò io, Windows invece ha il suo sistema (che piaccia o meno) per gestire questa cosa e il programmatore sa che usando quello va a botta sicura.

Per quanto riguarda l'esempio sui socket: su Linux hai read e write, mentre su Windows hai Readfile e WriteFile (notare cosa dice per il primo parametro: "A handle to the file or I/O device (for example, a file, file stream, physical disk, volume, console buffer, tape drive, socket, communications resource, mailslot, or pipe)". Non vedo questa gran differenza.
(Quando mi è capitato di usare i socket su Windows ho usato Boost.asio, quindi anche qui quello che ho detto vale per dei miei ragionamenti e non per esperienza diretta.)


Windows, non avendo delle metafore centrali, ad ogni aggiornamento rende obsolete buona parte delle tecnologie sviluppate nel kernel - ogni nuova generazione Windows obbliga gli sviluppatori a imparare nuove cose, talvolta fondamentali, perché quelle vecchie sono state dichiarate obsolete e non più supportate.

Windows tende a deprecare senza eliminare, pensa ad esempio ad "avvia questo programma in compatibilità con Windows 95" (che poi non so se quanto funzioni bene). Comunque sia avere qualcosa di nuovo e mettere da parte il vecchio non è necessariamente male, posso capire che è questione di punti di vista, ma ogni tanto capire di aver fatto uno sbaglio e riprogettare da zero non è un male.


A questo si può aggiungere che Windows non dispone di un vero e proprio terminale. La sua CLI è povera. La CLI è importante ad esempio per poter avere un linguaggio di scripting per l'amministrazione di sistema (si vedano bash e batch).

Ecco, a proposito di mettere da parte il vecchio per qualcosa di nuovo riprogettato da zero: Powershell.
Arrivata (credo) con Windows Vista ti da un linguaggio di scripting object-oriented decisamente più avanzato di batch, inoltre esistono implementazioni di bash con i vari tool di Linux. Sebbene anch'io preferisco di gran lunga Linux da questo punto di vista, da qui a dire che Windows non ha un vero e proprio terminale ce ne passa.


Anche altre scelte di design di Windows possono causare problemi: ad esempio il registro di sistema centralizzato. Un errore di un'applicazione che corrompe il registro può causare anche gravi danni. Inoltre, più il registro di sistema cresce, più pesante diventano le operazioni di accesso e scrittura.

Il registro di sistema di Windows lo possiamo grossomodo paragonare alle cartelle /etc e /var di Linux. Per scrivere sul registro mi risulta (?) che bisogna utilizzare delle funzioni fornite dal sistema operativo, se il registro si corrompe non è a causa del programma che lo modifica, ma della funzione fornita dal sistema operativo che non fa i dovuti controlli. Però non sono informato su come funzioni il registro di sistema, quindi non voglio parlare troppo a vanvera. La mia opinione è che il registro si corrompe perché Windows Registry Cleaner 2015 Ultimate Pro Cracked, che l'utente ha voluto installare fa più casini di quelli che risolve.
Se l'utente da i permessi ad un programma, non importa se sta usando Windows o Linux, questo programma può far danni. Il sistema di permessi di Windows è più sofisticato di quello di Linux (non necessariamente è un bene) anche perché la fascia di utenza è molto più vasta. Il principale vantaggio di Linux secondo me è proprio dovuto all'utenza, se il 90% del mercato desktop lo utilizzasse non sarebbe più così sicuro. Se obblighi l'utente comune a mettere una password ogni volta bisogna avviare qualcosa come amministratore, la prima cosa che fa è cercare di toglierla, anche solo il "clicka qui" di Vista è stato un fallimento completo.


Lo stesso sistema operativo è più instabile: Microsoft pensa di ridurre la complessità di un kernel progettandolo come kernel ibrido o come micro-kernel. In realtà, in questo modo, si finisce esclusivamente per complicare ulteriormente il sistema - un kernel che ha tanti moduli che devono comunicare tra loro, anche se questi moduli sono molto più semplici che in un kernel monolitico, farli comunicare tra loro non è così facile. I comunissimi BSOD di Windows possono dimostrarlo.

Col passare degli anni i microkernel e gli exokernel si sono rivelati la scelta migliore proprio perché ne migliorano la sicurezza e la stabilità, è esattamente l'opposto di quello che dici. Il punto è che la differenza tra kernel ibrido di Windows e kernel monolitico Linux è molto più sottile di quello che pensi, Torvalds l'aveva chiamata "trovata commerciale": i microkernel sono meglio, quindi diciamo che Windows è un ibrido. Ma in fin dei conti Windows è monolitico tanto quanto Linux, le caratteristiche ibride non sono così nette.


PS.
Ormai è da qualche anno che uso Linux e non uso Windows, se lo faccio è perché anche io lo ritengo migliore per l'utilizzo che ne faccio. Quello che ho scritto, l'ho scritto semplicemente per dire: anche Windows non è poi così male, anche dal punto di vista dello sviluppatore (basta citare alcuni software per rendersene conto).

PPS.
Vista l'ora non ho riletto, spero di aver scritto in un italiano leggibile e di aver detto poche cazzate.
 
Windows è un prodotto che è designato per l'utente, non per lo sviluppatore. Si consideri ad esempio la metafora unificante di Unix "everything is a file" - Windows non ha niente di questo tipo, ogni cosa è vista come qualcosa di diverso e separato da tutte le altre cose: una stampante è una stampante, il monitor è un monitor, ecc. Unix a differenza cerca di astrarre ogni cosa nel singolo concetto di "file". Windows risulta sicuramente più chiaro e semplice ad un utente finale, ma non ad uno sviluppatore. Un programmatore Windows è infatti costretto a imparare funzioni API diverse, metodi diversi, ognuno che serve a fare una cosa diversa: quando il programmatore ha imparato a sviluppare un software che scriva su schermo ha imparato una cosa - quando dovrà invece stampare con la stampante, sarà costretto a ricominciare da capo e imparare altri metodi, altre funzioni. Sotto Unix/Linux, si può fare quasi ogni cosa semplicemente con "open", "read", "write" e "close". Una volta che il programmatore ha imparato a leggere e scrivere sui file, sa già fare tante cose.
Questa non è l'unica conseguenza della mancanza di metafore unificanti: queste metafore sopravvivono oltre le versioni dei sistemi operativi. "Everything is a file" di Unix esisteva già negli anni '70, quando Unix è stato creato - ed esiste ancora oggi. Windows, non avendo delle metafore centrali, ad ogni aggiornamento rende obsolete buona parte delle tecnologie sviluppate nel kernel - ogni nuova generazione Windows obbliga gli sviluppatori a imparare nuove cose, talvolta fondamentali, perché quelle vecchie sono state dichiarate obsolete e non più supportate.
Un altro esempio sono i socket: la programmazione di applicazioni che comunicano sulla rete è molto più complicata in Windows che in Unix, dove è semplice come scrivere e leggere su file.
A questo si può aggiungere che Windows non dispone di un vero e proprio terminale. La sua CLI è povera. La CLI è importante ad esempio per poter avere un linguaggio di scripting per l'amministrazione di sistema (si vedano bash e batch). Inoltre non è possibile, in modo facile, combinare tra loro i programmi: per far collaborare più programmi è necessario, su Windows, fare uso di complicate chiamate RPC o funzioni API. In Unix/Linux, è sufficiente scrivere/leggere stdout/stdin. Certo, non che sia impossibile in Windows, ma la CLI di Windows offre molto molto di meno. Windows da importanza all'interfaccia grafica. Questo porta anche allo sviluppo di programmi molto complessi, che cercando di "fare tutto" - software più instabili e utilizzabili solo dall'utente finale, non da altri software.
Anche altre scelte di design di Windows possono causare problemi: ad esempio il registro di sistema centralizzato. Un errore di un'applicazione che corrompe il registro può causare anche gravi danni. Inoltre, più il registro di sistema cresce, più pesante diventano le operazioni di accesso e scrittura.
Windows non ha un corretto sistema di gestione dei permessi: cosa che rende più difficile la sicurezza del sistema e anche delle applicazioni. Il programmatore perde molto tempo nel mettere in sicurezza il proprio software (e spesso neanche ce lo perde, il che è peggio).
Windows non segue un metodo adeguato per il 'versioning' delle librerie. Questo fa si che i programmi sono costretti ad utilizzare specifiche versioni delle librerie e, chi installa questi software, vede aggiornamenti (o downgrade) praticamente random delle librerie.
Lo stesso sistema operativo è più instabile: Microsoft pensa di ridurre la complessità di un kernel progettandolo come kernel ibrido o come micro-kernel. In realtà, in questo modo, si finisce esclusivamente per complicare ulteriormente il sistema - un kernel che ha tanti moduli che devono comunicare tra loro, anche se questi moduli sono molto più semplici che in un kernel monolitico, farli comunicare tra loro non è così facile. I comunissimi BSOD di Windows possono dimostrarlo.
Inoltre, il mondo Windows è dominato dal closed-source, a partire dal sistema operativo. è importante, per un programmatore, studiare anche il codice altrui per imparare. E magari modificarlo e migliorarlo. Oppure per non dover reinventare la ruota ogni volta che si presenta un problema. Su Linux è open pure il sistema operativo stesso. Se qualcosa non funziona, si può andare anche a vedere, direttamente nel codice, il perché. Su Windows... reverse engineering oppure ti affidi a Microsoft.

Quando scrivo "Unix" o "Unix/Linux" parlo di cose che esistevano già in Unix e sono derivate in Linux. Linux ha preso molto da Unix.

Questa non è un'argomentazione molto forte. In realtà "migliore", bisogna vedere in cosa. Personalmente ritengo migliore Linux di Windows in tante cose, ma sicuramente non in tutte (è abbastanza difficile direi creare un sistema operativo che sia il peggiore in *ogni* cosa... bhé se si escludono i "sistemi operativi" in VB.NET degli script-kiddies di Sciax2). Imho però, è senz'altro migliore per uno sviluppatore.

Anche io ritengo molto migliore Linux come sistema operativo, volevo dire appunto questo.
 
Ultima modifica:
In Windows si tende a dire "everything is an object", anche se più precisamente si dovrebbe dire "every resource is an object": un file è un oggetto, così come un socket o un thread. Se vuoi comunicare
con quella risorsa richiedi un handle e hai potenzialmente qualcosa di più avanzato di un semplice stream di byte.

Precisamente.
Tutto è un oggetto e tutto è accessibile da un handle. Tutto.
Anche i processi purtroppo.

Questo è forse il problema principale di sicurezza di windows.
Mentre su Unix/Linux un processo viene visto quasi come un'entità sacra e inviolabile da qualunque altro processo suo pari (processi padre e relativa prole hanno qualche piccola differenza), su windows è tutto molto più friendly.
Basta un handle e possiamo fare ciò che vogliamo con il processo in esecuzione.
Ad esempio, ci basta sapere il nome di un FileMapping che un processo sta utilizzando e puf, otteniamo l'handle e puf, attraverso quello otteniamo accesso al FileMapping.
Su windows questo è considerato uno dei metodi di memory sharing e di comunicazione inter processo, ci sta, ma preferisco la visione Unix della questione, ovvero che un processo e le relative risorse allocate da/per quel processo siano inviolabili e inaccessibili da qualunque altro.

Senza contare tutte le infinite operazioni che un processo può effettuare su un'altro attraverso l'handle, fargli caricare dll, sapere per quanto tempo è stato eseguito, terminarlo, ottenere i suoi parametri di sicurezza..

Come ho appena detto, parametri di sicurezza. Ogni "oggetto" su windows ha i propri parametri di sicurezza settabili e configurabili, ma, come si vede tutti i giorni, nella pratica non è una cosa poi così efficace.
 
  • Mi piace
Reazioni: SpeedJack
Precisamente.
Tutto è un oggetto e tutto è accessibile da un handle. Tutto.
Anche i processi purtroppo.

Questo è forse il problema principale di sicurezza di windows.
Mentre su Unix/Linux un processo viene visto quasi come un'entità sacra e inviolabile da qualunque altro processo suo pari (processi padre e relativa prole hanno qualche piccola differenza), su windows è tutto molto più friendly.
Basta un handle e possiamo fare ciò che vogliamo con il processo in esecuzione.
Ad esempio, ci basta sapere il nome di un FileMapping che un processo sta utilizzando e puf, otteniamo l'handle e puf, attraverso quello otteniamo accesso al FileMapping.
Su windows questo è considerato uno dei metodi di memory sharing e di comunicazione inter processo, ci sta, ma preferisco la visione Unix della questione, ovvero che un processo e le relative risorse allocate da/per quel processo siano inviolabili e inaccessibili da qualunque altro.

Senza contare tutte le infinite operazioni che un processo può effettuare su un'altro attraverso l'handle, fargli caricare dll, sapere per quanto tempo è stato eseguito, terminarlo, ottenere i suoi parametri di sicurezza..

Come ho appena detto, parametri di sicurezza. Ogni "oggetto" su windows ha i propri parametri di sicurezza settabili e configurabili, ma, come si vede tutti i giorni, nella pratica non è una cosa poi così efficace.

In Windows si tende a dire "everything is an object", anche se più precisamente si dovrebbe dire "every resource is an object": un file è un oggetto, così come un socket o un thread. Se vuoi comunicare
con quella risorsa richiedi un handle e hai potenzialmente qualcosa di più avanzato di un semplice stream di byte.

Hai detto che su Linux una volta che sai leggere e scrivere su file sai già fare molto, e hai fatto l'esempio della stampante. Bene, io non ho la minima idea su come usare la stampante. Tra tutte le cose
che bisogna fare, inviare i byte alla stampante è l'ultimo problema che mi pongo. A dire il vero su Linux c'è CUPS per astrarre le read/write sulla stampante e nessuno mi garantisce che la distro XYZ lo
utilizzi al posto di LPRng o chessò io, Windows invece ha il suo sistema (che piaccia o meno) per gestire questa cosa e il programmatore sa che usando quello va a botta sicura.

Per quanto riguarda l'esempio sui socket: su Linux hai read e write, mentre su Windows hai Readfile e WriteFile (notare cosa dice per il primo parametro: "A handle to the file or I/O device (for example, a file, file stream, physical disk, volume, console buffer, tape drive, socket, communications resource, mailslot, or pipe)". Non vedo questa gran differenza.
(Quando mi è capitato di usare i socket su Windows ho usato Boost.asio, quindi anche qui quello che ho detto vale per dei miei ragionamenti e non per esperienza diretta.)




Windows tende a deprecare senza eliminare, pensa ad esempio ad "avvia questo programma in compatibilità con Windows 95" (che poi non so se quanto funzioni bene). Comunque sia avere qualcosa di nuovo e mettere da parte il vecchio non è necessariamente male, posso capire che è questione di punti di vista, ma ogni tanto capire di aver fatto uno sbaglio e riprogettare da zero non è un male.




Ecco, a proposito di mettere da parte il vecchio per qualcosa di nuovo riprogettato da zero: Powershell.
Arrivata (credo) con Windows Vista ti da un linguaggio di scripting object-oriented decisamente più avanzato di batch, inoltre esistono implementazioni di bash con i vari tool di Linux. Sebbene anch'io preferisco di gran lunga Linux da questo punto di vista, da qui a dire che Windows non ha un vero e proprio terminale ce ne passa.




Il registro di sistema di Windows lo possiamo grossomodo paragonare alle cartelle /etc e /var di Linux. Per scrivere sul registro mi risulta (?) che bisogna utilizzare delle funzioni fornite dal sistema operativo, se il registro si corrompe non è a causa del programma che lo modifica, ma della funzione fornita dal sistema operativo che non fa i dovuti controlli. Però non sono informato su come funzioni il registro di sistema, quindi non voglio parlare troppo a vanvera. La mia opinione è che il registro si corrompe perché Windows Registry Cleaner 2015 Ultimate Pro Cracked, che l'utente ha voluto installare fa più casini di quelli che risolve.
Se l'utente da i permessi ad un programma, non importa se sta usando Windows o Linux, questo programma può far danni. Il sistema di permessi di Windows è più sofisticato di quello di Linux (non necessariamente è un bene) anche perché la fascia di utenza è molto più vasta. Il principale vantaggio di Linux secondo me è proprio dovuto all'utenza, se il 90% del mercato desktop lo utilizzasse non sarebbe più così sicuro. Se obblighi l'utente comune a mettere una password ogni volta bisogna avviare qualcosa come amministratore, la prima cosa che fa è cercare di toglierla, anche solo il "clicka qui" di Vista è stato un fallimento completo.




Col passare degli anni i microkernel e gli exokernel si sono rivelati la scelta migliore proprio perché ne migliorano la sicurezza e la stabilità, è esattamente l'opposto di quello che dici. Il punto è che la differenza tra kernel ibrido di Windows e kernel monolitico Linux è molto più sottile di quello che pensi, Torvalds l'aveva chiamata "trovata commerciale": i microkernel sono meglio, quindi diciamo che Windows è un ibrido. Ma in fin dei conti Windows è monolitico tanto quanto Linux, le caratteristiche ibride non sono così nette.


PS.
Ormai è da qualche anno che uso Linux e non uso Windows, se lo faccio è perché anche io lo ritengo migliore per l'utilizzo che ne faccio. Quello che ho scritto, l'ho scritto semplicemente per dire: anche Windows non è poi così male, anche dal punto di vista dello sviluppatore (basta citare alcuni software per rendersene conto).

PPS.
Vista l'ora non ho riletto, spero di aver scritto in un italiano leggibile e di aver detto poche cazzate.

Windows è un prodotto che è designato per l'utente, non per lo sviluppatore. Si consideri ad esempio la metafora unificante di Unix "everything is a file" - Windows non ha niente di questo tipo, ogni cosa è vista come qualcosa di diverso e separato da tutte le altre cose: una stampante è una stampante, il monitor è un monitor, ecc. Unix a differenza cerca di astrarre ogni cosa nel singolo concetto di "file". Windows risulta sicuramente più chiaro e semplice ad un utente finale, ma non ad uno sviluppatore. Un programmatore Windows è infatti costretto a imparare funzioni API diverse, metodi diversi, ognuno che serve a fare una cosa diversa: quando il programmatore ha imparato a sviluppare un software che scriva su schermo ha imparato una cosa - quando dovrà invece stampare con la stampante, sarà costretto a ricominciare da capo e imparare altri metodi, altre funzioni. Sotto Unix/Linux, si può fare quasi ogni cosa semplicemente con "open", "read", "write" e "close". Una volta che il programmatore ha imparato a leggere e scrivere sui file, sa già fare tante cose.
Questa non è l'unica conseguenza della mancanza di metafore unificanti: queste metafore sopravvivono oltre le versioni dei sistemi operativi. "Everything is a file" di Unix esisteva già negli anni '70, quando Unix è stato creato - ed esiste ancora oggi. Windows, non avendo delle metafore centrali, ad ogni aggiornamento rende obsolete buona parte delle tecnologie sviluppate nel kernel - ogni nuova generazione Windows obbliga gli sviluppatori a imparare nuove cose, talvolta fondamentali, perché quelle vecchie sono state dichiarate obsolete e non più supportate.
Un altro esempio sono i socket: la programmazione di applicazioni che comunicano sulla rete è molto più complicata in Windows che in Unix, dove è semplice come scrivere e leggere su file.
A questo si può aggiungere che Windows non dispone di un vero e proprio terminale. La sua CLI è povera. La CLI è importante ad esempio per poter avere un linguaggio di scripting per l'amministrazione di sistema (si vedano bash e batch). Inoltre non è possibile, in modo facile, combinare tra loro i programmi: per far collaborare più programmi è necessario, su Windows, fare uso di complicate chiamate RPC o funzioni API. In Unix/Linux, è sufficiente scrivere/leggere stdout/stdin. Certo, non che sia impossibile in Windows, ma la CLI di Windows offre molto molto di meno. Windows da importanza all'interfaccia grafica. Questo porta anche allo sviluppo di programmi molto complessi, che cercando di "fare tutto" - software più instabili e utilizzabili solo dall'utente finale, non da altri software.
Anche altre scelte di design di Windows possono causare problemi: ad esempio il registro di sistema centralizzato. Un errore di un'applicazione che corrompe il registro può causare anche gravi danni. Inoltre, più il registro di sistema cresce, più pesante diventano le operazioni di accesso e scrittura.
Windows non ha un corretto sistema di gestione dei permessi: cosa che rende più difficile la sicurezza del sistema e anche delle applicazioni. Il programmatore perde molto tempo nel mettere in sicurezza il proprio software (e spesso neanche ce lo perde, il che è peggio).
Windows non segue un metodo adeguato per il 'versioning' delle librerie. Questo fa si che i programmi sono costretti ad utilizzare specifiche versioni delle librerie e, chi installa questi software, vede aggiornamenti (o downgrade) praticamente random delle librerie.
Lo stesso sistema operativo è più instabile: Microsoft pensa di ridurre la complessità di un kernel progettandolo come kernel ibrido o come micro-kernel. In realtà, in questo modo, si finisce esclusivamente per complicare ulteriormente il sistema - un kernel che ha tanti moduli che devono comunicare tra loro, anche se questi moduli sono molto più semplici che in un kernel monolitico, farli comunicare tra loro non è così facile. I comunissimi BSOD di Windows possono dimostrarlo.
Inoltre, il mondo Windows è dominato dal closed-source, a partire dal sistema operativo. è importante, per un programmatore, studiare anche il codice altrui per imparare. E magari modificarlo e migliorarlo. Oppure per non dover reinventare la ruota ogni volta che si presenta un problema. Su Linux è open pure il sistema operativo stesso. Se qualcosa non funziona, si può andare anche a vedere, direttamente nel codice, il perché. Su Windows... reverse engineering oppure ti affidi a Microsoft.

Quando scrivo "Unix" o "Unix/Linux" parlo di cose che esistevano già in Unix e sono derivate in Linux. Linux ha preso molto da Unix.

Questa non è un'argomentazione molto forte. In realtà "migliore", bisogna vedere in cosa. Personalmente ritengo migliore Linux di Windows in tante cose, ma sicuramente non in tutte (è abbastanza difficile direi creare un sistema operativo che sia il peggiore in *ogni* cosa... bhé se si escludono i "sistemi operativi" in VB.NET degli script-kiddies di Sciax2). Imho però, è senz'altro migliore per uno sviluppatore.
Ma quello che io mi domando alla fin fine è:

Se io programmo su Linux un determinato software... questo software sará accessibile solo dagli utenti Linux, no? E siccome gli utenti Linux sono circa il 20% in tutto il mondo... sticazzi, programmo su Windows, no?
 
Se io programmo su Linux un determinato software... questo software sará accessibile solo dagli utenti Linux, no? E siccome gli utenti Linux sono circa il 20% in tutto il mondo... sticazzi, programmo su Windows, no?
20%? Magari... Il mercato desktop è tipo 7-8% Mac OS, 2-3% Linux e 90% Windows.
Questo è il principale motivo per cui chi sviluppa videogiochi se ne sbatte altamente di tutto ciò che non è Windows, ultimamente le cose stanno cambiando, ma è presto per parlare.

Se vuoi vendere il tuo programma, programma su Windows. Se non vuoi vendere il tuo programma inizia a chiederti dove sta l'utenza del tuo software: è vero che Windows ha il 90% del mercato, ma è altrettanto vero che gran parte dell'utenza è formata da gamers e utenti casual che se lo trovano preinstallato nel computer. Se il tuo software non ha come target questo genere di utenza, allora già vale la pena farsi qualche domanda.

Comunque il nostro era un discorso molto più generale, da programmatori e non da economisti. Se non devo tirare su i soldi me ne sbatto di quello che fanno gli altri, sono perfettamente in grado di scegliere il sistema operativo che voglio usare e se faccio un tool lo faccio principalmente per me (anche perché non c'è garanzia che gli altri lo useranno).

PS.
Sì, non esiste solo l'utenza desktop. Ma visto che nell'OP si parlava di interfacce grafiche suppongo che il focus sia su questa.
 
  • Mi piace
Reazioni: CrashTest
Ma quello che io mi domando alla fin fine è:

Se io programmo su Linux un determinato software... questo software sará accessibile solo dagli utenti Linux, no? E siccome gli utenti Linux sono circa il 20% in tutto il mondo... sticazzi, programmo su Windows, no?
Linux attualmente ha solo circa il 7% del mercato Desktop (è stato più o meno sempre in lenta crescita). Ha invece più dell'80% del mercato Server e più del 60% del mercato Mobile con Android.
Il punto è che si può parlare di produzione o di apprendimento: bel primo caso, il sistema operativo dipende da ciò che si vuole produrre; nel secondo caso, imho, conviene Linux.
Inoltre c'è anche la discussione su chi sopravvivrà nel futuro. Non sono pochi quelli che pensano che gli unici software in grado di vivere veramente a lungo sono quelli free & open source mentre i software proprietari durano poco. Windows negli ultimi anni ha perso una buona fetta del suo mercato cedendola a Mac OS X e Linux.
Quindi, non è cosi facile: se si impiegano 20 anni a imparare a programmare bene per Windows e poi questo muore, sono anni praticamente buttati. Inoltre Linux non sarà attualmente molto importante sul Desktop, ma nel mercato server (e se si considera anche Android, pure sul mobile) è dominante - molte aziende richiedono di saper programmare in ambiente linux, oppure non assumono.
 
  • Mi piace
Reazioni: CrashTest
Quando si parla di embedded e di elettronica saper programmare è quasi equivalente a saper programmare su linux, windows non si può nemmeno prendere in considerazione. Nessuno mai si sognerebbe di produrre un oggetto nuovo che necessiti di un sistema operativo, senza linux, almeno per 2 ragioni: 1. linux è l'unico sistema operativo completamente personalizzabile, 2. linux è gratis.
Se io devo produrre un palmare per le pizzerie ad esempio, non ho scelta. O uso linux o dovrò pagare una licenza per ogni terminale, e questo influirebbe praticamente per il 100% del costo, il che sarebbe inaccettabile. Senza contare che anche le architetture hardware per linux sono spessissimo meno costose.
Ma a parte questo: la bravura della Microsoft è stata quella di pubblicizzarsi e di creare innovazione al momento giusto. queste due cose insieme creano una sorta di dipendenza, dalla quale con difficoltà si esce. Ed è lo stesso tipo di dipendenza psicologica che sta da anni creando la Apple.
Ma io credo che questo abbia una fine, perchè se gli utenti desktop sapessero che su un portatile che costa 300€, 60€ potrebbero risparmiarle senza perdere nè in prestazioni nè in usabilità (anzi forse il contrario), le cose cambierebbero, e infatti stanno cambiando.
 
  • Mi piace
Reazioni: SpeedJack
Stato
Discussione chiusa ad ulteriori risposte.