Diese Betriebssysteme wurden nicht offiziell als POSIX-kompatibel zertifiziert, halten sich aber an den Großteil der Standards:

* Nucleus RTOS
* FreeBSD[4]
* GNU/Linux (die meisten Distributionen - siehe LSB)
* NetBSD
* OpenBSD
* SkyOS
* Syllable
* VSTa
* NT-Kernel:
o Windows NT (außer optionale POSIX-Features)[5]
o Windows 2000 Server oder Professional mit Service Pack 3 oder höher (Unter Nutzung von Microsoft SFU 3.5). Um POSIX-konform zu sein, müssen optionale Features von Windows NT und Windows Server aktiviert werden[6]
o Windows XP Professional mit Service Pack 1 oder höher (Unter Nutzung von Microsoft SFU 3.5)
o Windows Server 2003 (Unter Nutzung von Microsoft SFU 3.5)
o Windows Vista (die Enterprise und Ultimate Editionen enthalten das Microsoft Windows Services for UNIX Subsystem für UNIX Anwendungen)

Wäre das möglich? Oder gibt es vielleicht sogar ein laufendes Projekt?
DAs wär och was tolles und net immer olle WinAPI.

posix ist nicht toll! denk' doch nur mal an solche scheusslichen sachen wie 'pthreads' oder wie prozesse 'geforkt' werden. das kann winapi alles viel besser.

<°)))o><

nanu, den Fisch hab ich schonmal gesehen. ps: Dieser thread ist ernst gemeint.

Wikilesen schrieb:

Weitgehend POSIX-konform [Bearbeiten]

Diese Betriebssysteme wurden nicht offiziell als POSIX-kompatibel zertifiziert, halten sich aber an den Großteil der Standards:

* Nucleus RTOS
* FreeBSD[4]
* GNU/Linux (die meisten Distributionen - siehe LSB)
* NetBSD
* OpenBSD
* SkyOS
* Syllable
* VSTa
* NT-Kernel:
o Windows NT (außer optionale POSIX-Features)[5]
o Windows 2000 Server oder Professional mit Service Pack 3 oder höher (Unter Nutzung von Microsoft SFU 3.5). Um POSIX-konform zu sein, müssen optionale Features von Windows NT und Windows Server aktiviert werden[6]
o Windows XP Professional mit Service Pack 1 oder höher (Unter Nutzung von Microsoft SFU 3.5)
o Windows Server 2003 (Unter Nutzung von Microsoft SFU 3.5)
o Windows Vista (die Enterprise und Ultimate Editionen enthalten das Microsoft Windows Services for UNIX Subsystem für UNIX Anwendungen)

Thx für die ausführliche Antwort. Aber ich meinte eigentlich, dass man posix code eifnach 1:1 auf windows kompilieren könnte und dann ausführen. zB sockets etc. ja gut WINSOCK is sehr posix ähnlich aber nicht 100%. Dadurch muss man da mit dem preprozessordirektiven rumfrickeln.

Das wäre doch toll, wenn der cdoe protabler wäre.

Undertaker schrieb:

h3t schrieb:

Wäre das möglich? Oder gibt es vielleicht sogar ein laufendes Projekt?
DAs wär och was tolles und net immer olle WinAPI.

posix ist nicht toll! denk' doch nur mal an solche scheusslichen sachen wie 'pthreads' oder wie prozesse 'geforkt' werden. das kann winapi alles viel besser.

Hast du denn Ahnung von POSIX? Was soll denn scheußlich an pthread udn fork sein? na gut, bin selber kein fan von pthread aber dafür mag ich fork umso mehr.
Es gibt doch nichts einfacheres als einmal eine funkmtion fork() aufzurufen OHNE JE>GLICHE ARGUMENTE und schon hat man einen neuen thread :). Mit WinAPI ist deis deutlich umständlicher. Und bevor jemand auf die idee kommt einen WinAPI vs POSIX flame zu starten: lasst es. Wäre es überhaupt im interesse von MS WinAPI posix kompatibler zu machen? Das wäre doch wirklich schön. Einfach Quellcode auf windows neukompilieren udn alles läuft

Na aber fork() (in der POSEX API) erstellt ja ein neuen prozess
Da ist nurnoch IPC und keione poiter, variablen etc.

Schonmal was von pipe() gehört ? ist auch verdammt einfach zu benutzen.

POSIX sei dank.

Ja ist das nicht toll, und dann wundern wenns langsam läuft!

Undertaker schrieb:

h3t schrieb:

Wäre das möglich? Oder gibt es vielleicht sogar ein laufendes Projekt?
DAs wär och was tolles und net immer olle WinAPI.

posix ist nicht toll! denk' doch nur mal an solche scheusslichen sachen wie 'pthreads' oder wie prozesse 'geforkt' werden. das kann winapi alles viel besser.

Hast du denn Ahnung von POSIX? Was soll denn scheußlich an pthread udn fork sein?

das waren nur beispiele. schau dir mal an, was mit 'native threads' unter win alles möglich ist, und dann vergleich' es mit der popeligen 'pthread' API.
'fork' ist auch so'n ding. dass ein prozess sich selbst startet, ist meistens ein absoluter sonderfall. genauso 'exec', tauscht den aktuellen prozess gegen einen neuen aus, auch ein sonderfall im 'wirklichen leben'
winapi ist für sowas alles viel brauchbarer --> http://msdn2.microsoft.com/en-us/library/ms684847.aspx

IMO ist Threading mit WinAPI doof und genauso doof mit pthreads - nur aus anderen Gründen

warum nennst du die Gründe nicht?

Komm nicht mit Code Kompatibel, mehr als kleine Spielzeug Programme aka Client/Server etc. kriegt man eh nicht hin und da reicht die alte Variante,
wenn es Komplexer wird, wie Webcam capturen, bilder komprimieren und versenden aka DirectX etc. ist POSIX nur noch Überflüssiger Code.
Wenn ich ein umfangreiches Windows Programm schreibe, kann ich mit POSIX null anfangen, alles andere ist Kinderkram.

hustbaer schrieb:

IMO ist Threading mit WinAPI doof und genauso doof mit pthreads - nur aus anderen Gründen

warum nennst du die Gründe nicht?

WinAPI: keine Condition Variablen, keine "Deleter" für TLS, ...

pthreads: pthread_cond_timedwait/... nehmen ein absolutes Timeout, kein multiple Join, viel zuviele "optional features" die man dynamisch abfragen muss wenn man sie braucht, ...

WinAPI: keine Condition Variablen, keine "Deleter" für TLS, ...

doch: http://msdn2.microsoft.com/en-us/library/ms682052.aspx
früher gab's die nicht. wahrscheinlich hat m$ sie eingebaut, damit man olle unix-anwendungen leichter portieren kann, denn eigentlich sind cond. variablen überflüssig unter windoows.

Und für unnötig halte ich die nicht gerade. Condition-Variablen sind deswegen toll, weil dumme/unerfahrene User damit einfach weniger Fehler machen als mit Mutex + Event (man kann z.B. nicht den Fehler machen die Mutex wegzulassen bzw. zu "vergessen" bzw. "wegzuoptimieren"). Klar kann man die Mutex immer noch falsch locken, Multithreading bleibt halt schwer, nur ein klein wenig weniger schwer

Klar kann man Condition-Variablen über Events (mit einigem Aufwand) simulieren, aber wer will das schon? Der Code der dabei rauskommt (der Code der die simulierten Condition-Variablen implementiert, nicht der der sie verwendet) ist entweder falsch oder saulangsam oder zumindest "etwas tricky".

(und ja, wenn man nur "signal_one" braucht dann ist es ganz einfach sich mit Events was selbst zu basteln, bloss ist "signal_all" auch manchmal sehr praktisch)