Programmazione in C: Unix vs Windows

[Vexem]

Salve a tutti.

Devo effettuare un progetto universitario in C, spesso si tratta della gestione di un database, e il sistema automatico di assegnazione chiede su quale piattaforma verrà svolto il programma.
So che la maggioranza degli studenti ha fatto il progetto su piattaforma Unix, ma quali sono gli effettivi svantaggi/vantaggi e le eventuali differenze ?

Ovviamente, so che cambierebbero tutte le System Call.

Voi cosa consigliereste ?

[AnonimoVeneziano]

Salve a tutti.

Devo effettuare un progetto universitario in C, spesso si tratta della gestione di un database, e il sistema automatico di assegnazione chiede su quale piattaforma verrà svolto il programma.
So che la maggioranza degli studenti ha fatto il progetto su piattaforma Unix, ma quali sono gli effettivi svantaggi/vantaggi e le eventuali differenze ?

Ovviamente, so che cambierebbero tutte le System Call.

Voi cosa consigliereste ?

Io consiglierei di non usare le system calls per esempio :p

Le system calls del sistema operativo sono l'interfaccia di piu' basso livello che hai a disposizione per programmare e bisognerebbe usarle solo se strettamente necessario e non si necessita portabilita'

Dipende dal progetto che ti daranno, ma in gran parte dei casi puoi usare delle librerie multi-piattaforma per fare la maggior parte delle cose, anche per GUI.

Il multithreading e' una di quelle cose che storicamente e' meno multi-piattaforma, ma se usi PThread (per cui c'e' una implementazione su Win32) dovresti comunque cavartela.

L'unica cosa che potrebbe darti grattacapi che mi viene in mente e' se devi usare i Socket per accedere la rete a basso livello. L'interfaccia di socket di Windows e Unix sono abbastanza diverse e, a meno di usare una qualche libreria di astrazione, potrebbe essere una delle differenze piu' evidenti. Non sono aggiornato pero' sull'esistenza o meno di tale libreria.

[pabloski]

Salve a tutti.

Devo effettuare un progetto universitario in C, spesso si tratta della gestione di un database, e il sistema automatico di assegnazione chiede su quale piattaforma verrà svolto il programma.
So che la maggioranza degli studenti ha fatto il progetto su piattaforma Unix, ma quali sono gli effettivi svantaggi/vantaggi e le eventuali differenze ?

Ovviamente, so che cambierebbero tutte le System Call.

Voi cosa consigliereste ?

Visto il tipo di progetto, non cambia assolutamente niente. Il vantaggio e' che ti alleni a programmare per i sistemi Unix/Posix, che sono diffusissimi in ogni dove nell'ambito lavorativo.

Le syscall non sono affar tuo, in quanto tu dialoghi con la libc e non col kernel.

La differenza sta semmai nell'uso di specifiche funzioni che esistono su Unix ma non su Windows ( fork ad esempio ).

Ma le funzioni di base sono standardizzate e supportate dalla libc, per cui saranno ugualmente utilizzabili in entrambi gli ambienti.

Se parliamo poi di database, dovrai per forza usare una libreria esterna che sara' al 99% presente su entrambi gli ambienti.

Al massimo la grafica ( se c'e' nel tuo caso ) puo' crearti problemi. Ma anche in questo basta usare librerie grafiche multipiattaforma.

[Vexem]

Io consiglierei di non usare le system calls per esempio :p

Le system calls del sistema operativo sono l'interfaccia di piu' basso livello che hai a disposizione per programmare e bisognerebbe usarle solo se strettamente necessario e non si necessita portabilita'

Dipende dal progetto che ti daranno, ma in gran parte dei casi puoi usare delle librerie multi-piattaforma per fare la maggior parte delle cose, anche per GUI.

Il multithreading e' una di quelle cose che storicamente e' meno multi-piattaforma, ma se usi PThread (per cui c'e' una implementazione su Win32) dovresti comunque cavartela.

L'unica cosa che potrebbe darti grattacapi che mi viene in mente e' se devi usare i Socket per accedere la rete a basso livello. L'interfaccia di socket di Windows e Unix sono abbastanza diverse e, a meno di usare una qualche libreria di astrazione, potrebbe essere una delle differenze piu' evidenti. Non sono aggiornato pero' sull'esistenza o meno di tale libreria.

Visto il tipo di progetto, non cambia assolutamente niente. Il vantaggio e' che ti alleni a programmare per i sistemi Unix/Posix, che sono diffusissimi in ogni dove nell'ambito lavorativo.

Le syscall non sono affar tuo, in quanto tu dialoghi con la libc e non col kernel.

La differenza sta semmai nell'uso di specifiche funzioni che esistono su Unix ma non su Windows ( fork ad esempio ).

Ma le funzioni di base sono standardizzate e supportate dalla libc, per cui saranno ugualmente utilizzabili in entrambi gli ambienti.

Se parliamo poi di database, dovrai per forza usare una libreria esterna che sara' al 99% presente su entrambi gli ambienti.

Al massimo la grafica ( se c'e' nel tuo caso ) puo' crearti problemi. Ma anche in questo basta usare librerie grafiche multipiattaforma.

Grazie mille ad entrambi.
Fortunatamente non devo implementare l'interfaccia grafica mentre quasi sicuramente farò uso di socket.

Ho provato un paio di IDE su Ubuntu (codeblocks ed eclipse) ed entrambe funzionano malissimo causando continui freeze.
Credo che ripiegherò su Geany.
Ho già programmato in C su Windows e mi trovavo benissimo su CLion

[pabloski]

Ho provato un paio di IDE su Ubuntu (codeblocks ed eclipse) ed entrambe funzionano malissimo causando continui freeze.
Credo che ripiegherò su Geany.
Ho già programmato in C su Windows e mi trovavo benissimo su CLion

Curioso che freezano. CLion c'e' anche per Linux. Inoltre puoi usare CodeLite, Netbeans, Anjuta, Qtcreator e anche Geany ovviamente.

Mi azzardo a proporre Vim. Tuttavia e' un editor/IDE da prendere in considerazione per il futuro, dato che la curva di apprendimento e' molto ripida. Ma una volta che s'impara a padroneggiarlo e' semplicemente imbattibile, nonche' cross-platform ed estremamente leggero.

[Vexem]

Curioso che freezano. CLion c'e' anche per Linux. Inoltre puoi usare CodeLite, Netbeans, Anjuta, Qtcreator e anche Geany ovviamente.

Mi azzardo a proporre Vim. Tuttavia e' un editor/IDE da prendere in considerazione per il futuro, dato che la curva di apprendimento e' molto ripida. Ma una volta che s'impara a padroneggiarlo e' semplicemente imbattibile, nonche' cross-platform ed estremamente leggero.


Grazie, li proverò tutti.

Per inciso, mi è arrivata ora la specifica via mail: si tratta di un'applicazione client server gestibile in concorrenza o in sequenza

Spero che Unix sia stata la scelta migliore :asd:

[pabloski]

E' una semplice applicazione client-server. Peraltro non richiede nemmeno che il server usi il multithreading.

Alla fin fine si tratta di usare stdio e i socket. L'unica parte incompatibile con Windows ( in minima parte oltretutto ) sono i socket.

[Vexem]

E' una semplice applicazione client-server. Peraltro non richiede nemmeno che il server usi il multithreading.

Alla fin fine si tratta di usare stdio e i socket. L'unica parte incompatibile con Windows ( in minima parte oltretutto ) sono i socket.
Suppongo quindi che la mia ansia riguardo le System Call fosse ingiustificata.
Strano, nel corso ne abbiamo parlato parecchio.

[pabloski]

Suppongo quindi che la mia ansia riguardo le System Call fosse ingiustificata.
Strano, nel corso ne abbiamo parlato parecchio.

Cosa intendi esattamente per syscall? Nel gergo s'intende quelle funzioni messe a disposizione dal kernel. Tali funzioni non vengono mai usate dai programmi utenti, ma solo ed esclusivamente dalla libc.

Se poi per syscall il tuo professore ha inteso anche parte delle funzioni della libc, allora e' un altro paio di maniche.

Nel secondo caso ci sono alcuni elementi di differenza tra gli Unix e Windows:

1. fork non esiste in Windows
2. i socket presentano delle differenze
3. posix non e' supportato da windows 8 in su

A cio' aggiungiamo che tutto cio' che non e' previsto dalla libc ( la grafica ad esempio ) e' implementato in maniera completamente diversa dai vari OS.

[Vexem]

Cosa intendi esattamente per syscall? Nel gergo s'intende quelle funzioni messe a disposizione dal kernel. Tali funzioni non vengono mai usate dai programmi utenti, ma solo ed esclusivamente dalla libc.

Se poi per syscall il tuo professore ha inteso anche parte delle funzioni della libc, allora e' un altro paio di maniche.

Nel secondo caso ci sono alcuni elementi di differenza tra gli Unix e Windows:

1. fork non esiste in Windows
2. i socket presentano delle differenze
3. posix non e' supportato da windows 8 in su

A cio' aggiungiamo che tutto cio' che non e' previsto dalla libc ( la grafica ad esempio ) e' implementato in maniera completamente diversa dai vari OS.
Si, la fork la considera come una syscall.

fork, wait, exec, nice...

[pabloski]

Si, la fork la considera come una syscall.

fork, wait, exec, nice...

La ragione e' che quelle sono sia syscall che funzioni della libc.

In Linux hai:

- fork -> clone
- wait -> wait
- exec -> execve
- nice -> nice
- exit -> _exit

E cosi' via.

Cio' non toglie che quelle funzioni le trovi nelle libc di tutti i sistemi posix compatibili. Il problema e' che in Windows molto di quelle non ci sono.

[Vexem]

La ragione e' che quelle sono sia syscall che funzioni della libc.

In Linux hai:

- fork -> clone
- wait -> wait
- exec -> execve
- nice -> nice
- exit -> _exit

E cosi' via.

Cio' non toglie che quelle funzioni le trovi nelle libc di tutti i sistemi posix compatibili. Il problema e' che in Windows molto di quelle non ci sono.
Quindi le chiamate della libc funzionano come intermediari?
Suppongo che in questo modo non metto mano direttamente sul kernel

In ogni caso ho optato per piattaforma Unix, visto che mi sembra la più usata.

[pabloski]

Quindi le chiamate della libc funzionano come intermediari?


Lo scopo per cui e' nata la libc e' proprio quello. E' l'unica ad avere titolo a chiamare le syscall del kernel. La ragione e' ovviamente che il kernel puo' cosi' cambiare le syscall come gli piace, senza che cio' renda inutilizzabili le applicazioni utente.

[Vexem]

Lo scopo per cui e' nata la libc e' proprio quello. E' l'unica ad avere titolo a chiamare le syscall del kernel. La ragione e' ovviamente che il kernel puo' cosi' cambiare le syscall come gli piace, senza che cio' renda inutilizzabili le applicazioni utente.
Chiarissimo, grazie mille!