Plattform- & sprachunabhängige Bibliothek

Es gibt 12 Antworten in diesem Thema. Der letzte Beitrag () ist von MrLee.

    Plattform- & sprachunabhängige Bibliothek

    Weiss jemand, wie es möglich ist, eine plattform- & sprachunabhängige Bibliothek zu erstellen? Wenn man nur für Windows programmiert geht dies über DLLs. Allerdings funktionieren DLLs natürlich weder auf MAC noch auf Linux.
    Ich möchte also eine Code schreiben, den jeder unabhängig von seinem OS und seiner Programmiersprache benutzen kann. Das dies nicht ohne Neukompilierung geht ist ja klar, aber was ist der allgemeine Weg? Kann mir jemand Stichwörter geben, nach denen ich suchen muss?
    Programmieren willl ich in C++
    Das sind (für mich) beides keine zufriedenstellenden Möglichkeiten. Skriptsprachen sind nicht geeignet, da ich etwas recht rechenintensives implementieren möchte und mit .NET geht aus dem gleichen Grund nicht. Ausserdem sind mir die Möglichkeiten etwas zu kompliziert. Geht das wirklich nicht mit C++?
    Natürlich geht das in C++. Brauchst halt nen Windows Rechner mit ner Virtual Machine auf der du Linux aufsetzt und mit `make` und einer Makefile den C++ Code auf Linux compilst. Dann hast du 2 Dateien, eine DLL und eine SO.

    ~ Chris
    To make foobar2000 a real random music player, I figured out the only way to achieve this is to use Windows Media Player.

    At some point in time, you recognize that knowing more does not necessarily make you more happy.
    Ok, ich weiss, dass ich mit fast jeder Programmiersprache unter Windows auf eine .DLL zugreiffen kann. Aber ich habe noch nie gehört, dass man z.B. unter Linux und Java auf eine Datei mit der Endung .so zugreiffen kann. Funktioniert das wirklich?
    Ich weiß nur das es bei CS:S für Server einmal eine .DLL und eine .SO Datei gibt, die jeweils für Windows / Linux ist. Ich habe meinen C++ Code einfach auf beiden Systemen compiled und fertig, und ich weiß nur, dass es funktioniert ;)

    ~ Chris
    To make foobar2000 a real random music player, I figured out the only way to achieve this is to use Windows Media Player.

    At some point in time, you recognize that knowing more does not necessarily make you more happy.
    .so (Shared Objects) sind sowas wie .DLLs unter Windows.
    Plattformunabhängige Binaries kannst du eigentlich nur mit Java erstellen - da musst du dann am Zielsystem über "Umwege" gehen, um den Code auszuführen (Java eben), DLLs in der Form sind nicht möglich.
    Wenn du lediglich eine DLL brauchst, die sich auf den diversen Systemen kompilieren lässt, kannst du ruhig C bzw. C++ nehmen. Wenn keine API-Aufrufe drin sind, ist das ganze eigentlich unbedenklich, ansonsten musst du die betroffenen Teile für jede Plattform schreiben und über Makros die "richtigen" Auswählen. Der Präprozessor schmeißt dann das raus, was nicht hin gehört. predef.sourceforge.net/preos.html
    z.B.

    Quellcode

    1. #IF _WIN32
    2. // hier den windows code
    3. #ENDIF
    Klar funktioniert das. Wenn du dir CygWin installierst, kannst du dir die VM auch sparen.
    Vielleicht findest du ja einen Crosscompiler, der auf W32 Linux Binaries erstellen kann, dann steht der .SO nix mehr im Wege.

    cygwin.org/cygwin/
    de.wikipedia.org/wiki/Crosscompiler
    de.wikipedia.org/wiki/GNU_Compiler_Collection
    sdcc.sourceforge.net/
    de.wikipedia.org/wiki/MinGW

    Ansonsten, wenn es auch was anderes als C++ sein darf und trotzdem nativ laufen soll:
    Pascal:
    freepascal.org/
    lazarus.freepascal.org/
    wiki.lazarus.freepascal.org/Screenshots

    FreeBasic:
    de.wikipedia.org/wiki/Freebasic
    de.wikibooks.org/wiki/FreeBasic

    und noch bequemer:
    de.wikipedia.org/wiki/PureBasic

    Ansonsten:
    seit Mono solle es kein Problem sein, eine unter Windows mit .NET erstellte DLL auch unter Linux zu benutzen.
    Bekannte Beispiele: SQLite.net und SDL.net
    Ich habe beide auf Windows XP SP3 und Ubunut im Einsatz (mit Monodevelop).
    Pascal ist imho beinahe tot. Das hat damals den Kampf gegen C verloren und lebt quasi nurnoch wegen Delphi weiter ...

    PureBasic ist eher für Programme als für DLLS gemacht, ist nicht Open Source (falls das relevant ist) und ich hab keinen Plan, wie's da mit OS-API aussieht.

    Bei FreeBasic hab ich auch keinen Plan, wie's mit OS-API aussieht.

    SDL und Sqlite sind aber sicherlich nicht in Mono geschrieben. Das ist beides in C geschrieben und beiden haben (nur) Wrapper für Mono.
    Der Nachteil an Mono im DLL-Bereich ist ganz einfach, dass die Binaries die da rauskommen keine .SOs sind, sondern .net-DLLs und diese können somit nicht einfach in jedem Programm verwendet werden.

    SDL is written in C, but works with C++ natively, and has bindings to several other languages, ...
    PureBasic ist für vieles geeignet - ich verwende das schon lange genug. Die OS-API kann vollständig genutzt werden.
    Gleiches gilt für FreeBasic.

    Ich habe bei SQLite und SDL dezitiert auf SQLite.NET und SDL.NET verwiesen und nie behauptet, dass die ursprünglichen Libs in einer CLI/CLR-Sprache verfasst sind.

    Der Nachteil an Mono im DLL-Bereich ist ganz einfach, dass die Binaries die da rauskommen keine .SOs sind, sondern .net-DLLs und diese können somit nicht einfach in jedem Programm verwendet werden.
    Da gebe ich dir vollkommen recht. Ich wollte lediglich darauf hinweisen. Immerhin sind wir in einem Forum, welches mit .Net zu tun hat - was wäre naheliegender, als den Topicstarter darauf hinzuweisen, dass er nicht unbedingt auf andere Sprachen/Systeme ausweichen muss und VB.net weiterhin für DLLs verwenden kann, sofern er auch auf anderen Plattformen in .net-Land verweilen will.
    Wie siehts mit Makros (Pre-processor IFs) bei den beiden Basics aus?
    Können beide. Besonders mit PureBasic ist es sehr leicht, plattformübergreifend zu programmieren, da es mit den "CompilerIfs" sehr einfach ist, zu entscheiden, welcher Code für welche Plattform kompiliert wird.

    In Sache SQLite und SDL hab ich mich wohl verlesen.
    Kann jedem passieren, macht ja nix. Technisch gesehen hast du ja recht.