Welche OS-API ist am schönsten?



  • Alle sind hässlich. Manche sogar potthässlich.



  • volkard schrieb:

    was würdest du sagen auf die frage, was der schönste Pullover ist?

    Das ist der Pullover den ich gerade trage 😃 😉

    SideWinder schrieb:

    @kingruedi: Nein POSIX und OS/2 sind zwei eigene Sub-Systeme. So wie Win32 ein Sub-System von WinNT ist.

    MfG SideWinder

    Das OS/2- und POSIX-subsystem sind aber über das win32-subsystem implementiert, jedoch kann ein Programm immer nur eines der subsystems verwenden.
    Ein Programm welches das OS/2- oder das POSIX-subsystem verwendet kann allerdings keine win32-Funktionen aufrufen.



  • volkard schrieb:

    bsd ist schweineeffizient im grundlegenden tcp-handling uhd kann mit dem uniformed memory handling oder wie das heißt, die deine daten geben ohne andauernd zu kopieren (hab ich so gehört, bin nicht sicher). also top speed, wo die anderen os'e einfach grundlegende probs haben und nicht darüberhinaus kommen.

    http://bulk.fefe.de/scalability/

    A-I/O haben denke ich mittlerweile alle OSs (also auch Linux und es würde mich wundern, wenn Windows so etwas nicht hätte).

    Was aber unter Linux extrem cool ist, ist sendfile um unnötiges hin und her kopieren zwischen Speicherbereichen zu vermeiden (so kann man direkt ein handle innerhalb des Kernel Spaces kopieren).

    Aber das ist mittlerweile alles OT 🙂



  • kingruedi schrieb:

    Was aber unter Linux extrem cool ist, ist sendfile um unnötiges hin und her kopieren zwischen Speicherbereichen zu vermeiden (so kann man direkt ein handle innerhalb des Kernel Spaces kopieren).

    scheint auf win das hier zu sein:
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/transmitfile_2.asp



  • Hi,
    naja. Was ich unter schön definiere ist, das die API einem das Programmieren nicht zu schwer machen soll. Zig Parameterübegaben oder nichtssagende Funktionennamen sind z.B. ein dickes Minus.

    Liebe Grüße
    Real



  • SirLant schrieb:

    Das OS/2- und POSIX-subsystem sind aber über das win32-subsystem implementiert, jedoch kann ein Programm immer nur eines der subsystems verwenden.
    Ein Programm welches das OS/2- oder das POSIX-subsystem verwendet kann allerdings keine win32-Funktionen aufrufen.

    Ein Programm das das OS/2 Subsystem verwendet *ist* ein OS/2 Programm. Windows stellt keine OS/2 APIs zur Verfügung, es stellt (oder stellte, ist glaube ich seit Win2K nicht mehr vorhanden) eine Laufzeitumgebung zur Verfügung die es ermöglicht native OS/2 Programme unter Windows laufen zu lassen. Allerdings deckt diese nur die uralten 16-Bit Teile von OS/2 ab, womit nur OS/2-Konsolenprogramme lauffähig sind.

    Umgekehrt stellt OS/2 tatsächliche einen Haufen Win32-APIs zur Verfügung (Open32), was das Portieren von Windows-Anwendungen auf OS/2 erleichtern sollte. Open32 ist einfach eine DLL, die die Win32-APIs auf die OS/2-APIs mappt. Das heisst hier kann man tatsächlich in einem nativen OS/2-Programm Win-APis verwenden.



  • volkard schrieb:

    kingruedi schrieb:

    Was aber unter Linux extrem cool ist, ist sendfile um unnötiges hin und her kopieren zwischen Speicherbereichen zu vermeiden (so kann man direkt ein handle innerhalb des Kernel Spaces kopieren).

    scheint auf win das hier zu sein:
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/transmitfile_2.asp

    Ja (wobei sendfile generell mit allen Deskriptoren verwendbar ist. Auch Datei->Datei Socket->Datei Socket->Socket etc.).

    Aber das können wir ja mal gleich zum API Vergleich nutzen

    Linux:

    ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);
    

    Windows:

    typedef struct _OVERLAPPED {
      ULONG_PTR Internal;
      ULONG_PTR InternalHigh;
      DWORD Offset;
      DWORD OffsetHigh;
      HANDLE hEvent;
    } OVERLAPPED;
    
    typedef struct _TRANSMIT_FILE_BUFFERS {
      PVOID Head;
      DWORD HeadLength;
      PVOID Tail;
      DWORD TailLength;
    } TRANSMIT_FILE_BUFFERS;
    
    BOOL TransmitFile(
      SOCKET hSocket,
      HANDLE hFile,
      DWORD nNumberOfBytesToWrite,
      DWORD nNumberOfBytesPerSend,
      LPOVERLAPPED lpOverlapped,
      LPTRANSMIT_FILE_BUFFERS lpTransmitBuffers,
      DWORD dwFlags
    );
    

    *hehehe*



  • Und was ist jetzt flexibler??



  • Ich denke nicht, dass eine API flexibler ist, dadurch das man einer Funktion die Funktionalität von weiteren Funktionen unterordnet.

    Was ist wohl intuitiver?
    1.

    write(sock,"header",6);
    off_t n=5;
    sendfile(file,sock,&n,10);
    write(sock,"tail",4);
    
    TRANSMIT_FILE_BUFFERS buf;
    buf.Head="header";
    buf.HeadLength=6;
    buf.Tail="tail";
    buf.TailLength=4;
    OVERLAPPED ov;
    ov.Internal=0;
    ov.InternalHigh=0;
    ov.Offset=5;
    ov.OffsetHigh=0;
    ov.hEvent=0;
    TransmitFile(sock,file,10,0,&ov,&buf,0);
    

    Ich finde ersteres eindeutig lesbarer und verständlicher, wenn man beide APIs nicht kennt.

    (btw. der Code ist ungetestet)



  • Hallo Leute!

    Ich habe laaange für BeOS in C++ programmiert und muss sage diese OO-API von BeOS war wirklich toll.
    Ich hab übrigends immer noch eine BeBox im Keller stehen.

    mfg



  • frenki schrieb:

    SirLant schrieb:

    Das OS/2- und POSIX-subsystem sind aber über das win32-subsystem implementiert, jedoch kann ein Programm immer nur eines der subsystems verwenden.
    Ein Programm welches das OS/2- oder das POSIX-subsystem verwendet kann allerdings keine win32-Funktionen aufrufen.

    Ein Programm das das OS/2 Subsystem verwendet *ist* ein OS/2 Programm. Windows stellt keine OS/2 APIs zur Verfügung, es stellt (oder stellte, ist glaube ich seit Win2K nicht mehr vorhanden) eine Laufzeitumgebung zur Verfügung die es ermöglicht native OS/2 Programme unter Windows laufen zu lassen. Allerdings deckt diese nur die uralten 16-Bit Teile von OS/2 ab, womit nur OS/2-Konsolenprogramme lauffähig sind.

    Eine API x ist doch immer eine Laufzeitumgebung für Programme die x verwenden, oder worin liegt da bei dir der Unterschied kann dir da gerade nicht ganz folgen.



  • @SirLant
    Eine API ist keine Laufzeitumgebung, sondern definiert einfach nur die programmiertechnische Schnitstelle zu etwas. In dem Fall hier die _direkte_ Schnitstelle zum Betriebssystem. 🙄



  • Ja das ist mir auch klar, aber was ist an einer Laufzeitumgebung dann anderst? Dort hab ich ja auch einfach ne API welche so aufgebaut ist wie auf dem Originalsystem und diese API ist ja auch nur ne Schnittstelle zum OS.

    Sorry, vielleicht bin ich gerade auch nur schwer von Begriff, aber mir leuchtet es im Moment einfach nicht ein 😕



  • alter Hase schrieb:

    Hallo Leute!

    Ich habe laaange für BeOS in C++ programmiert und muss sage diese OO-API von BeOS war wirklich toll.
    Ich hab übrigends immer noch eine BeBox im Keller stehen.

    mfg

    Kannst ja weiterschreiben. Such mal nach Zeta im Internet.

    Liebe Grüße
    Real



  • SirLant schrieb:

    Eine API x ist doch immer eine Laufzeitumgebung für Programme die x verwenden, oder worin liegt da bei dir der Unterschied kann dir da gerade nicht ganz folgen.

    Der Unterschied in diesem Fall ist, dass OS/2 ein anderes Executable-Format verwendet als Windows. OS/2 verwendet Liniear Executable (LX). Windows Portable Executable (PE). Die OS/2-Laufzeitumgebung von Windows kann die LX-Executables laden und ausführen.



  • Eine Laufzeitumgebung ist einfach mehr, als eine API. Laufzeitumgebung könnte man vielleicht als Zusammenfassung der zur Laufzeit des Programmes existierenden ABIs zusammen fassen.

    Real schrieb:

    Kannst ja weiterschreiben. Such mal nach Zeta im Internet.

    Da reicht auch Fernseher anmachen und RTL-Shop gucken 😉



  • vielleicht ganz interessant:

    http://www.sysinternals.com/ntw2k/info/ntdll.shtml

    In Windows NT the Native API, its system call interface, is hidden from programmers behind higher level APIs such as Win32, OS/2, POSIX or DOS/Win16.


Anmelden zum Antworten