Systemprogrammierung macht man in beiden Fällen mit C, da sollte es einige Ähnlichkeiten zwischen den Systemen geben und wenn man genau schaut, sieht man die auch. Aber auf den ersten Blick sehen die entsprechenden C-Programme sehr verschieden aus. Das überrascht nun wieder, da doch eigentlich mit der Programmiersprache C auch die libc standardisiert ist und das sogar einigermaßen eingehalten wird. Leider ist die libc gerade im betriebssystemnahen Bereich mehr oder weniger auf die Schnittmenge vieler Systeme zugeschnitten und stellt einiges an Funktionalität der darunter liegenden Betriebsysteme nicht zur Verfügung. So kann man vieles generisch programmieren, aber es gibt doch immer wieder Bereiche, in denen es vorteilhaft oder sogar fast zwingend notwendig ist, eine betriebssystemspezifische Implementierung zu wählen.
Rein optisch sieht man den Unterschied sofort. Die typischen Win32/Win64-Programme verwenden schon Funtionsnamen mit Camel-Case und großen Anfangsbuchstaben und bevorzugt sehr lange Namen für Funktionen, Variablen, Konstanten und Macros und sehr lange Parameterlisten. So werden die MS-Windowsprogramm lang, aber man kann wenigstens oft sehen, was in etwa gemeint ist. Letztlich muss man aber die Konzepte verstanden haben und Zugriff auf eine Funktions- und API-Referenz haben, ob das nun Man-Pages oder die Webseite einer großen Firma ist, ist sekundär. Eigentlich ist dieser Unterschied auch nicht so wichtig, weil man sich an andere Schreibweisen für die konzeptionell gleiche Sache schnell gewöhnen kann. Ärgerlich ist nur, dass man wirklich alles zweimal schreiben muss. In der Praxis wird man vielleicht die I/O- und IPC-Funktionalität, die die Software benötigt, an der man arbeitet, in einer oder mehreren Bibliotheken behandeln, wohlgemerkt spezifisch das, was man braucht und nicht eine generische Verallgemeinerung beider APIs, die nie fertig und nie richtig gut wird. Die restliche Programmlogik kann man vielleicht generisch gestalten.
Es gibt auch Möglichkeiten, unter MS-Windows mehr oder wenigeer viele der unter Posix (Linux, Unix, MacOSX, etc.) bekannten Funktionen unter MS-Windows zu benutzen. Mit cygwin bekommt man die meisten, das ist sozusagen so eine generische Schicht, aber auch die nativen Win32/Win64-Bibliothken enthalten oft über das geforderte Minimum hinaus Funktionen, die so typischerweise unter Posix üblich sind, z.B. open(), close(), read() und write().
Möglichkeiten zur Generierung von Nebenläufigkeit mit Prozessen und Threads sind in beiden Systemen vorhanden, aber auch hier mit subtilen semantischen Unterschieden, die es einem schwer machen können. Interprozesskommunikation haben beide Systeme und man kann natürlich auch recht vie l mit TCP/IP-lösen, was dann generisch ist.
Die bekannte Thematik mit „/“ vs. „\“ als Datei-Pfad-Trennzeichen kann man dagegen leicht lösen, indem man konsequent „/“ verwendet. Das verstehen die Win32- und Win64-API-Funktionen gut.
Die leidige Problematik mit den Zeilenwecheln mit ctrl-M ctrl-J vs nur Ctrl-J ist auch nicht so schlimm, wie man meint. Man kann eine Datei unter MS-Windows binär anlegen und dann wird das Ctrl-M nicht eingefügt. Und über weite Strecken werden beide Konventionen auf beiden Systemen problemlos verstanden und können entsprechend eingesetzt werden. Sinnvoll ist nur, dass man das definiert und sich auf einen Weg einigt.
