Compilare c sotto Windows

[Andreak]

Salve è da poco che programmo in c sotto linux , però abbiamo fatto un applicazione client server, che mi piacerebbe tanto farla girare anche sotto windows , ho provato a compilarla così a ghiaccio senza modificare una linea di codice con "code-block" sotto win macon scarsi risultati, dato che l'applicazione che abbiamo fatto utilizza questa roba

#include <stdio.h>                /* perror() */
#include <stdlib.h>               /* atoi() */
#include <sys/types.h>
#include <sys/socket.h>
#include <unistd.h>               /* read() */
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>

e alcuni di questi header non vengono trovati sapete come aiutarmi...

[cionci]

perror e atoi sono in stdlib.h read la dovresti trovare in io.h...

Devi usare degli #ifdef LINUX e mettere dentro gli header presenti solo su Linux...e #ifdef WIN32 e mettere dentro gli header presenti solo su windows...

[71104]

non puoi compilare un programma Linux TCP/IP sotto Windows: le librerie dei sockets sono simili, ma diverse; al max puoi usare come dice cionci delle #ifdef per mettere codice specifico per Windows e per Linux. Su Windows devi includere winsock.h (sempre che tu abbia il PSDK).

[cionci]

Comunque a parte la WSAStartup, se vengono usate le funzioni standard non ci sono problemi... Ad esempio bisogna usare send e recv per le operazioni sui socket, invece di read e write...

[71104]

Originariamente inviato da cionci

Comunque a parte la WSAStartup, se vengono usate le funzioni standard non ci sono problemi... Ad esempio bisogna usare send e recv per le operazioni sui socket, invece di read e write...

eh be, qualche differenza sostanziale ci sta però: oltre alla WSAStartup e WSACleanup (e ovviamente al fatto che per la notifica non puoi usare le finestre e i messaggi di Windows ^^) considera che ad es. la socket su Windows restituisce un valore di tipo SOCKET, mentre mi pare che su Linux restituisce un intero: questo comporta che se si verifica un errore in Windows il risultato è 0 (handle nullo), mentre su Linux mi sembra che fosse diverso (le funzioni originali restituiscono 0 se non c'è nessun errore), ma non ricordo com'era.
alla fine si, si risolve tutto con #ifdef, ma non è tanto banale

[cionci]

Per il tipo di ritorno non ci sono problemi...con un #define SOCKET int sei al riparo da qualsiasi problema... Per l'errore è lo stesso discorso:

#ifdef WIN32
#define SOCKET_CREATE_ERROR INVALID_SOCKET
#else
#define SOCKET_CREATE_ERROR -1
#endif

Poi tra l'altrol'unica differenza è che l'handle ritornato è unsigned...altrimenti il valore era -1 anche per quello (INVALID_SOCKET è definito come ~0)...