Binaerkompatibilitzaet wirst du ohnehin nicht haben. Das heisst, dass fuer jedes System ohnehin eigene ausfuehrbare Dateien erzeugen musst. Zum anderen ist natuerlich Pascal Plattforumunabhaengig. Genau so wie jede Sprache auf allen Plattformen laeuft, wo es fuer sie Compiler bzw Interpreter gibt.
--
Das ist mir schon klar (auser es gibt Emulatoren/ Schnittstellen die eben die Programme abspielen können). Aber mit Pascal alleine dürfte man nicht sonderlich weit kommen - ich warte erstmal ab bis Ferien sind.Zitat von Ineluki
--«Wir können alles schaffen, wir brauchen nur genug dressierte Affen» - infinite monkey theorem
Mit Java hat man weitgehende Binärkompatibilität. Zugegeben, Java ist von barocker Komplexität und manchmal muß man für einfache Aufgaben durch Reifen springen, aber in Sachen Portabilität ist Java ganz weit vorne.
Ansonsten kommt man an C/C++ nicht vorbei. Dotnet/Mono ist sehr begrenzt zwischen Windows und Linux portabel (solange du im Wesentlichen alle Windows-Standardklassen vermeidest und GTK installierst), läuft aber AFAIK sonst nirgends. Objective-C läßt sich zwar auf allen großen Plattformen kompilieren, ist aber nur für die Apple-Welt relevant. Python und sonstige Skriptsprachen können zwar oft GUIs, sind aber nur für Linux interessant.
Wenn man portable GUI-Anwendungen schreiben will ist GTK übrigens nicht unbedingt die erste Wahl - der Anwender muß erstens immer noch GTK bei sich installieren und zweitens neigen GTK-Anwendungen dazu, unter Windows nicht hundertprozentig wie Windows-Anwendungen auszusehen. Das gilt auch für Qt.
In Sachen portable GUIs dürfte wxWidgets unübertroffen sein - für Windows kompiliert greift es auf GDI zurück, für Linux auf GTK und für OS X auf Carbon. Damit kriegst du auf jeder Plattform ein sehr natives Look-and-Feel. Allerdings gibt es AFAIK für wxW keine guten freien RAD-IDEs (im Gegensatz zu beispielsweise Qt oder FLTK).
Wenn die Softtware auch unter MacOS laufen soll hast du im Wesentlichen die Wahl zwischen Java und C++/wxWidgets. Anders dürfte es schwer werden, ein gutaussehendes Programm hinzukriegen. (Kommt mir nicht mit GTK und Qt. Auf dem Mac sind GTK und Qt derb häßlich.)
FLTK verdient eine Sondererwähnung: Es macht deinen Code minimal größer, läuft auf vielen Plattformen und kommt mit einer brauchbaren RAD-IDE, dafür ist es allerdings auch pottenhäßlich. Also, so richtig. Windows 95 war schöner.
Rendert Qt nicht inzwischen auch ueber die nativen Widgets? Ich meine, mal irgendwo gelesen zu haben, dass das in einer der neueren Versionen eingebaut wurde.
Ja, an sich schon. Aber alle Programme in DarwinPorts/Fink/Portage wollen das X11-Qt als Dependency. Und den ganzen Kram ohne jegliches Paketmanagement von Hand zu bauen ist seit Jahren selbst für Linux-User unter der Würde.
Oder du stellst in den Kerneloptionen ein, daß er MISC-Binaries ausführt und stellst für dein Format einen Handler (also im Wesentlichen eine VM) bereit. Auf die Weise kann man beispielsweise PEs direkt an Cedega durchreichen.
@Pascal: Warum nicht? Pascal nimmt zwar an Beliebtheit immer weiter ab und ich bevorzuge C-artige Syntaxen, aber ansonsten...
@Mono: Okay, Mono läuft unter OS X auch, aber ich denke, man muß letztenendes doch wieder über GTK oder wxW gehen - Kram wie WinForms ist ja nicht ansatzweise portabel.
Dann hat man das Problem, daß Mono/Dotnet das gleiche Grundprinzip wie Java verfolgt, also zu Bytecode kompiliert und JIT in Maschinencode übersetzt wird. Ergo hat man in etwa die gleiche Performanz wie mit Java.
Übrigens ist die Sprachvielfalt nicht unbedingt ein wichtiges Argument für Dotnet - es gibt schon mehrere Sprachen wie Nice oder Groovy, die zu Java-Bytecode kompiliert werden.
Wobei ich anmerken muss, dass an der unterstützung der WinForms bereits gearbeitet wird. Wie die letztendlich dann auf dem Bildschirm aussehen werden, sprich ob natives Look and Feel usw. weiß ich jetzt aber nicht.
Was zum Teil daran liegt, dass Linux keine Dateien ohne bestimmtes, ausführbares Format (COM-Dateien) zulässt. Würde Linux/UNIX diese Dateien auch zulassen, und wenn der Programmierer direkt die Hardware anspricht, wären gleiche Programme (ein und dieselbe Datei) die unter diesen verschiedenen System gleich laufen, durchaus möglich. Ist zwar viel LowLevel-Arbeit, aber beispielsweise für Virenprogrammierer wäre es eventuell ganz praktisch.
freundliche Grüße, Rolus
Ich kenn mich da net so aus, aber wäre es dann vielleicht nicht möglich, beim Installationsprozess das Unix/Linux System so zu verändern, dass es solche Dateien und somit eine Datei für beide System zulässt? Oder wäre das (a) nicht möglich, da man unix/linux dazu neu kompilieren müsste oder (b) wieder zu hardwareplattformabhängig?
Dafür müsstest du den Teil des Kernels umschreiben, der für die Ausführung von ausführbaren Dateien zuständig ist: Also ja.
Alternativ könnte man die COM-Dateien in irgendeinem Emulator oder einer virtuellen Maschine laufen lassen, keine Ahnung ob es irgendwas schlankes dafür gibt.
Du kannst im Protected Mode (Nachfolger des Realmode [16 Bit], kein Speicherschutz ...) nicht einfach so eben auf die Hardware zugreifen. Die sogenannten BIOS-Interrupts sind im PM nicht verfügbar, deshalb werden im PM auch Treiber für alles mögliche gebraucht, im RM übernimmt das zum Großteil das BIOS (allerdings sind die Treiber halt sehr viel leistungsfähiger). Und die Ports zum ansteuern der Hardware werden im PM auch nur für den Kernel zugängig, Programme laufen im "Ring 3", der Kernel im "Ring 0" d.h. der Speicher/Hardware-Schutz des PMs lässt es auf Hardware-Basis schon garnicht zu das sowas geht. So können Programme nur auf allgemeine Sachen wie jumps, schreiben in bestimmte speicherabschnitte, if's (<- Hardware abhängig) und eben auf Betriebssystem-Interne Sachen zugreifen. So ist es beinahe unmöglich ohne gigantische Anpassungen Com bzw. Exe Dateien nativ unter Linux laufen zu lassen, aber das wollte ja eh keiner, denn der freie POSIX Betriebssatz ist um einiges besser und eben auch portabler als die WinAPI.
Berechtigungen
Zitieren