Welche Programmiersprache für welches Projekt?

Ich setzte mich in letzter Zeit ziemlich fest mit Programmiersprachen auseinander und wundere mich gleichzeitig auch immer wieder, wieviele es davon eigentlich gibt. Gerade die hohe Anzahl bereitet mir Mühe. Da ich wirklich gewillt bin, zu programmieren, habe ich jetzt einfach nur noch das Problem, mit welcher Sprache?
Denn ich habe nur wenig Lust, nach 1 1/2 Jahren hartes Erlernen von C++ zu merken, dass meine Ziele gar nicht damit verwicklicht werden können bzw. dass das nicht die geeigntste Programmiersprache dafür ist. Deshalb wollte ich einmal fragen (und ich hoffe den Thread gabs nicht schonmal), welche Projekte mit welcher Sprache am besten verwirklicht werden können?
Ich weiss sehr wohl, dass sich die Frage nicht einfach mit 2 - 3 Worten beantworten lässt, aber ich denke mal, dass jede Sprache in einer gewissen Hinsicht ihre Vor- und Nachteile hat, weshalb sie für bestimmte Vorhaben speziell gut, oder eben weniger gut geeignet ist (z.B. in der Geschwindigkeit des auszuführenden Codes etc.).
Ich wäre euch einfach dankbar, wenn ich mir in eurem Beitrag vielleicht einfach eure Erfahrung, oder euer Wissen über die geläufigsten, und am häufig auftretensten Sprachen (C++, Java, Delphi usw.) kurz erklärt, nennt, für was sie am besten geeignet wären (oder wo sie am häufigsten anzutreffen sind. Z.B. C++ bei Spielen...), und wenn es geht auch noch, warum :).

Ich hoffe ihr versteht in etwa, was ich meine. Ansonsten bin ich natürlich jedem dankbar, der mir seine Erfahrungen mitteilt ;)

Mfg Biosfear

Gabs schon hundert mal. Das könnte dir helfen.

Zitat:

---

Zitat von DFYX

Gabs schon hundert mal. Das könnte dir helfen.

---

Das tut`s aber nicht wirklich, denn das Lesen des verlinkten Threads war das Erste, was ich vor ungefähr 6 Monaten, als ich das erste mal das Programmierforum betrat, getan habe. Und speziell auf einzelne Programmiersprachen wird dort meiner Ansicht nach nicht eingegangen.
Ausserdem habe ich die "Suche" benutzt und bin auf ehrlich gesagt kein Ergebniss (schon gar nicht 100) gestossen, dass näher auf die verschiedenen Programmiersprachen eingeht, und nicht nur auf Spiele- bzw. MMORPGProgrammierung abzielt.
Versteh mich jetzt bitte nicht falsch, aber es war nicht meine Absicht, ein Thread zu erstellen, und zu fragen, welche Programmiersprache ich für Spiele, oder für MMORPGs (ich nehme jetzt mal an, das hast du versehentlich so verstanden) verwenden soll, der dann mit fünf Wörtern beantwortet werden kann. Ich dachte eigentlich eher daran, dass Leute, die Erfahrung mit den einzelnen Sprachen haben, mir vielleicht sagen können, für welche Projekte ich die einzelnen Sprachen verwenden kann/sollte, da vielleicht nicht jede Programmiersprache aufgrund ihrer Geschwindigkeit beispielsweise nicht für Spiele verwendet werden sollte (etc.). Klar, am besten kann man das beurteilen, wenn man das selbst ausprobiert, aber da liegt gerade mein Problem: C++, Java, Delphi und Co. zu lernen, und dann zu entscheiden, welche Sprache für meine Wünsche die beste ist, wäre mir irgendwie halt doch zu anstrengend :).
Trotzdem danke für deine Antwort ;)!

Mfg Biosfear

Naja es stimmt schon, dass jede Programmiersprache ihre Vor und Nachteile hat und sich für gewisse Dinge besser eignen als für andere.

Aber ich finde es ist eigentlich egal, mit welcher Sprache man anfängt, da die Grundlagen (damit meine ich die Grundideen) der Programmierung ziemlich gleich sind (Ausnahme Unterschied Sequentielle Programmierung und Objektorientierte Programmierung).

Ich fand es ganz gut, eine Prograsprache der OOP und eine seq. Sprache gleichzeitig zu lernen, so sieht man gleich welche Sprache (oder besser welche Sprachenart) sich besser für welche Bereiche eignet.

Letzten Endes hängt es von den eigenen Vorlieben (oder denen des Kunden) ab, welche Sprache man benutzt.

Also an der Uni haben wir bisher hauptsächlich Java als OOP und C als seq. Sprache verwendet. Nur damit du mal ne Vorstellung hast.

Zitat:

---

Zitat von Fowler

Ich fand es ganz gut, eine Prograsprache der OOP und eine seq. Sprache gleichzeitig zu lernen, so sieht man gleich welche Sprache (oder besser welche Sprachenart) sich besser für welche Bereiche eignet.

Letzten Endes hängt es von den eigenen Vorlieben (oder denen des Kunden) ab, welche Sprache man benutzt.

Also an der Uni haben wir bisher hauptsächlich Java als OOP und C als seq. Sprache verwendet. Nur damit du mal ne Vorstellung hast.

---

Man könnte auch C++ lernen, wo man sowohl rein sequentiell als auch stark objektorientiert arbeiten kann.

Oder als OOP-Sprache Ruby, das die einzige mir bekannte rein objektorientierte Sprache ist (Java hat immer noch diese ekligen Primitivtypen).


Mal sehen...

Programmiersprachen

Assembler ist dann sinnvoll, wenn es auf Geschwindigkeit absolut ankommt. Du bist damit zwar absolut unportabel und mußt alles von Hand machen, aber in Sachen Geschwindigkeit ist es schwer, handoptimierten Assemblercode zu übertreffen.

C bietet sich an, wenn man schnelle Programme schreiben, sich aber nicht mit Assember herumschlagen will. Außerdem kann man so relativ schnellen, portablen Code schreiben. Dummerweise kennt C keine Objekte und überläßt viel Arbeit dem Programmierer, was es erlaubt, jede Menge wirklich unsicheren Kram zu machen.

C++ ist C mit OOP-Erweiterungen. Zwar ist C++ um den Faktor 5 langsamer als C (weil OOP eine Sprache langsam macht), es ist aber immer noch ziemlich schnell. Auch C++ bietet sich an, wenn man portablen Code schreiben will. Mit C++ ist es etwas schwerer, kaputten Code zu schreiben als mit C, aber es ist immer noch möglich, was unter anderem der komplett manuellen Speicherverwaltung zu verdanken ist.

Java hat den Vorteil, daß man es einmal schreibt und dann das fertig kompilierte Programm überall laufen lassen kann, wo es eine Java-VM gibt. Der Nachteil ist, daß men eben nur in Java-Bytecode kompiliert, der interpretiert werden muß, was Java um den Faktor 4 langsamer macht als C++ (und um den Faktor 20 langsamer als C). Java nimmt dem Programmierer viel Arbeit ab und ist sehr strikt, was sowohl Vorteil als auch Nachteil sein kann. Eines der Designziele von Java ist es, das Schreiben von kaputtem Code zu erschweren. Java setzt OOP voraus.
Für die Entwicklung von portablen GUI-Anwendungen könnte Java besser geeignet sein als C(++), weil die meisten C++-GUI-Toolkits Probleme haben, sich auf allen Plattformen gut zu integrieren - im Gegensatz zu Swing, Javas Toolkit.

Microsoft Visual Basic 6 - VB6 ist extrem gut geeignet, um schnell GUI-Anwendungen hochzureißen, aber es ist eben ein interpretiertes Basic und hat alle damit verbundenen Nachteile. Außerdem ist es absolut unportabel und erfordert eine Runtime, um unter Windows lauffähig zu sein.

Skriptsprachen

PHP ist besondrs für den Einsatz auf Webservern geeignet, da die meisten Hostingangebote PHP-Unterstützung mit einschließen. Für den Einsatz als Shellskript ist PHP an sich auch geeignet, es hat aber mitunter eine recht lange Ladezeit, wenn der Interpreter das erste mal gestartet wird. Seit Version 5 unterstützt PHP auch OOP.

Ruby ist eine rein objektorientierte Sprache: Alles ist ein Objekt. Das erlaubt es Ruby, einige sehr elegante Konstrukte zu haben; allgemein ist Ruby so aufgebaut, daß es leicht zu lernen ist. Ruby hat mit irb einen sehr nützlichen interaktiven Interpreter und der normale Interpreter braucht keine lange Anlaufzeit.

Delphi
Es ist sehr Einfach Programme mit GUIs zu entwickeln. Eigenet sich sehr gut für Programme, für Spiele eher weniger (auch wenn andere das anders sehen).
Nachteil? Die Exen werden recht groß, wenn man die VCL (also dieses einfache Setzen der Komponenten) benutzt, da dann sehr viel in die Exe mirreinkompilt wird. Eine einfache Fensteranwendung die nur ein Fenster anzeigt ist schon um die 300 kb groß (lässt sich aber mit UXP sehr gut verkleinern).

PureBasic:
Gut geeignet für schnell mal ein kleines 2D-Spielchen erstellen, Grafik-, 3D-Sprite-, Sound-, Videofunktionen, alles dabei was man für kleine Spiele braucht.
Für Anwendungsentwicklung die schnell und unkompliziert, dafür nicht so effektiv wie die von Delphi oder VB6 sein soll, ist PB auch gut geeignet. Direkter WinAPI support, Befehle können inline eingegeben werden ohne vorher irgendwelche Libraries laden zu müssen.
Eine großzahl der Funktionen sind portabel auf Windows, Linux und neuerdings auch MacOS (Betaphase) sowie Amiga, was aber nicht wirklich entscheident sein sollte.
Ist in der Entwicklungsphase, Funktionen und deren Arbeitsweisen können sich leicht ändern, neue Funktionen und GUI-Objekte kommen noch hinzu, Bugs sind leider noch reichlich vorhanden. Direkter Kontakt mit dem Entwicklerteam im englischsprachigen Forum.
PureBasic braucht keine externen runtime libraries und erzeugt dennoch extrem kleine Exe-Dateien binnen weniger Sekunden kompilierzeit. (Einfache Programme sind < 10 KB, GUI-Anwendungen auch meist < 100 KB).
(Der Compiler ist übrigens in C + Assembler geschrieben worden, die IDE in PureBasic selbst).

Blitz Basic:
Eine Basic Sprache, die speziell für die Entwicklung von Spielen gemacht wurde. Sie ist sehr einfach und schnell zu erlenen. Mittlerweile gibt es vier Versionen:

Blitzbasic 2D - nur für 2D Spiele. Gibt es nicht mehr zu kaufen.
Blitzbasic 3D - für 2D und 3D Spiele.
BlitzPlus - nur für 2D und GUI unterstützung.
Blitzmax - für Windows, Linux und Macintosh.

Es gibt ein deutsches Forum (www.blitzforum.de) und eine eine große deutsche Onlinehilfe, in der alle Befehle erklärt und mit Beispielen veranschaulicht werden (www.blitzbase.de).
www.blitzbasic.com ist die offizielle Hompage von Blitzbasic.

Ok, vielen Dank Leute, genau so hab ich mir das in etwa vorgestellt ;)!
Was mich aber auch noch interessieren würde:
C++ ist doch die bei (professionellen) Spielen am meisten anzutreffende Programmiersprache, oder?
Wenn ich mich gerade auch mit dem Thema Java oder Delphi auseinandersetzte; wo treffe ich die am meisten an? (C++ -> Spiele, Delphi -> ?, Java -> ?). Da Java um das vierfache langsamer ist als C++ wahrscheindlich weniger bei Spielen, aber ich habe bis jetzt nur wenige Programme angetroffen, die mit Java geschrieben wurde (oder ich weiss es wie gesagt nicht).

Da ist noch etwas kleines:
Vorhin bin ich hier im Forum auch noch kurz auf einen anderen Thread gestossen, bei dem ich folgendes gelesen habe:

Zitat:

---

Zitat von Jesus_666

Manchmal macht es echt Spaß, ein Java-User zu sein. ^_^ (Um das jetzt weniger flamig klingen zu lassen: Java ist zwar eine Kante aufwendiger als C++, hat für sowas (im Thread ging es um Bilder) aber schon fertige Klassen dabei. C++ ist für den Einsteiger übersichtlicher, hat aber eine bedeutend kleinere Standardbibliothek.)

---

Bis jetzt dachte ich immer, C++ ist einer der kompliziertesten Programmiersprachen? Java soll noch aufwendiger sein?
Auch das C++ für Einsteiger übersichtlicher sein soll, ist mir irgendwie neu, oder ist das nur im Bezug auf Bilder, die angezeigt werden sollte, gemeint?


Aber danke an euch!

Mfg Biosfear

Java kenn ich nicht aber von C/C++ kann man sagen, dass es nicht unbedingt einen Anfängerfreundlichen Ruf hat, was dahinter steckt, keine Ahnung. Ich hab zuvor Pure Basic gelernt und danach C/C++ angefangen. Daher weiß ich nun nicht, ob das Verständnis für die Sache auch gekommen wär, wenn ich direkt C/C++ angefangen hätte. Probier es aus!
Aber die komplizierteste Sprache ist es sicher nicht. Probier mal BrainFuck aus, naja, es gibt nur wenige Befehle was es eigentlich unkompliziert macht, aber damit komplexe Dinge zu schreiben ist kompliziert, da man wenig machen kann außer Speicherbereiche verschieben und sowas... Und Assembler ist imo auch komplizierter als C/C++, auch weniger lesbar auf den ersten Blick.

Zu den Bildern: Funktionen für Bilder, Grafiken allgemein oder GUI gibt es in C/C++ überhaupt nicht. Dazu muss man auf andere Bibliotheken zurückgreifen, weche sich in C/C++ einbinden lassen.
Ich quote mal mich selbst:

Zitat:

---

Ich empfehle da die WinAPI zum Start. Diese benutzt die sogenannte GDI zum Anzeigen von Grafiken. Wenn du also in dein Programm die WinAPI einbaust, kannst du Befehle der GDI nutzen um Bitmaps in einem Fenster auszugeben. Das Fenster auf Vollbild zu legen ist auch möglich, was dann die Optik eines Spieles hätte, wenn man alle Ränder und Buttons ausblendet.
Wie man die WinAPI einbindet, erklären zahlreiche Bücher über die WinAPI oder einige Online-Tutorials. Such mal per google danach. Soviel kann ich verraten, du brauchst dazu die Header-Datei <windows.h> sowie im Linker musst du gdi32 linken (wenn du den Linker/Compiler verwendest, der bei Dev-C++ dabei ist). Die main() Funktion entfällt dabei, dafür gibt es eine WinMain()-Funktion. (Alles nachzulesen in der Win32.hlp Datei, der Hilfedatei für die WinAPI. (Google wird die sicher finden))

Ansonsten beibt zu sagen, dass man, bevor man die WinAPI verwenden will, zumindest die Grundkenntnisse von C (die WinAPI ist eher mit C-Code zu vergleichen als mit C++) beherrschen sollte. Also Sachen wie Pointer, Variablentypen, Arrays, Schleifen, If und Switch, halt alle Dinge die so ein typisches Tutorial wie dieses hier behandelt: http://tutorial.schornboeck.net/inhalt.htm

---

Entnommen aus dem Beitrag "Bilder in C++".

Java hat vor allem den Vorteil, dass ein und die selbe Binärdatei auf beinahe jedem Computer, unabhängig von Prozessorarchitektur und Betriebssystem lauffähig ist. Selbst auf Handies, wenn man gewisse Einschrängungen beachtet.

Was die Sache mit den Grafiken angeht: Im Kern können Java und C/C++ gar nichts, außer den Grundrechenarten, nicht mal einen Text in der Konsole ausgeben. Für alles andere müssen Bibliotheken eingebunden werden, die die Befehle bereitstellen. Der Unterschied ist, dass in Java alle wichtigen Bibliotheken (An die hundert, wenn ich mich recht erinnere) dabei sind und man damit auch davon ausgehen kann, dass sie auf jedem Computer, wo Java läuft auch laufen (Hadies mal ausgenommen, die haben einen abgespeckten Bibliothekensatz) Diese Bibliotheken sind zu 100% Plattformunabhängig, während bei C/C++ nur einige wenige Standardbibliotheken auf allen Systemen zur Verfügung stehen. So bietet Java für GUIs einheitlich die Bibliotheken java.awt.* und java.swing.* an, während bei C/C++ unter Windows häufig die WinApi verwendet wird, die aber unter keinem anderen Betriebssystem läuft. Umgekehrt kann Windows nichts mit den Bibliotheken für Linux anfangen. Es gibt zwar immer wieder einige Versuche, eine entsprechende C/C++ Bibliothek zu schreiben, die je nach Betriebssystem auf den entsprechenden Standardbibliotheken basiert. Allerdings sind diese Bibliotheken nicht immer vollständig. Ähnlich geht es in anderen Bereichen wie Netzwerk und 3D Grafik zu (Wobei da OpenGL relativ Plattformunabhängig ist)

Zitat:

---

Zitat von Biosfear

Ok, vielen Dank Leute, genau so hab ich mir das in etwa vorgestellt ;)!
Was mich aber auch noch interessieren würde:
C++ ist doch die bei (professionellen) Spielen am meisten anzutreffende Programmiersprache, oder?
Wenn ich mich gerade auch mit dem Thema Java oder Delphi auseinandersetzte; wo treffe ich die am meisten an? (C++ -> Spiele, Delphi -> ?, Java -> ?). Da Java um das vierfache langsamer ist als C++ wahrscheindlich weniger bei Spielen, aber ich habe bis jetzt nur wenige Programme angetroffen, die mit Java geschrieben wurde (oder ich weiss es wie gesagt nicht).

---

Java dürfte nach C++ die zweithäufigste Sprache in der Anwendungsentwicklung sein. Ding wie Verwaltungs- und Finanzsoftware werden häufig in Java geschrieben. Außerdem gibt es noch die Applets - kleine Java-Programme, die im Browser laufen. Dummerweise kann man da nur eine uralte Version von Java (1.1, vielleicht sogar 1.2) benutzen, weil die Browser mit neuerem Kram nicht gut klarkommen.

Zitat:

---

Da ist noch etwas kleines:
Vorhin bin ich hier im Forum auch noch kurz auf einen anderen Thread gestossen, bei dem ich folgendes gelesen habe:

Bis jetzt dachte ich immer, C++ ist einer der kompliziertesten Programmiersprachen? Java soll noch aufwendiger sein?
Auch das C++ für Einsteiger übersichtlicher sein soll, ist mir irgendwie neu, oder ist das nur im Bezug auf Bilder, die angezeigt werden sollte, gemeint?

---

Java ist an sich wie C++, nur strenger (selbst Operationen, bei denen unter Umständen Präzision verloren gehen könnte, werden vom Compiler als Fehler betrachtet) und sehr stark objektorientiert. Das Konzept der objektorientierten Programmierung muß man an sich beherrschen, wenn man mit Java vernünftig arbeiten will - bei C++ kann man auch rein prozedural bleiben.

Man vergleiche die Implementierungen von Hello World:

Code:

---

C++:
#include <iostream>

int main()
{
 std::cout << "Hello, world!" << endl;
}



Java:
class HelloWorld
{
 public static void main (String args[])
 {
  System.out.println("Hello, World!");
 }
}

---

Zitat:

---

Zitat von DFYX

Ähnlich geht es in anderen Bereichen wie Netzwerk und 3D Grafik zu (Wobei da OpenGL relativ Plattformunabhängig ist)

---

Naja, für Netzwerkkram kann man SDL/net benutzen, das AFAIK unter Windows und *nix läuft. Und OpenGL ist voll portabel. OpenGL-Code, der unter Windows geschrieben wurde, läuft auch unter OS X.

Zitat:

---

OpenGL-Code, der unter Windows geschrieben wurde, läuft auch unter OS X.

---

Gabs da nicht mal Probleme, weil OS X und *nix nicht mit dem Vollbildmodus klarkommen? Meine da was im Hinterkopf zu haben.

Zitat:

---

Zitat von DFYX

Gabs da nicht mal Probleme, weil OS X und *nix nicht mit dem Vollbildmodus klarkommen? Meine da was im Hinterkopf zu haben.

---

Man braucht unter *nix/X11 Schreibzugriff auf ein bestimmtes Gerät, um in den Vollbildmodus zu kommen. Bei modernen Linux-Distros ist X aber schon so konfiguriert, daß alle User darauf zugreifen können.
Unter OS X habe ich bisher bei keinem Spiel irgendwelche Probleme bemerkt.

Zitat:

---

Zitat von Ynnus

Und Assembler ist imo auch komplizierter als C/C++, auch weniger lesbar auf den ersten Blick.

---

Naja, eigentlich ist eine Assemblersprache nicht viel schwerer als die gängigen Hochsprachen, vielleicht sogar noch etwas einfacher. Die Assembler-Grundlagen zu lernen ist IMHO nicht so schwer wie beispielsweise die C++-Grundlagen zu lernen. Aber mit Assembler erreicht man eben nicht so schnell etwas. Ich würde also sagen: Assembler selbst ist nicht sonderlich schwer, aber es ist schwer mit Assembler große Programme zu schreiben. Obwohl man mit Assembler ja auch auf Schnittstellen wie die WinAPI oder DirectX bzw. OpenGL zugreifen kann. Es ist zwar meistens ein vielfaches des Hochsprachen Codes nötig, aber das Programm ist im Endeffekt doch meistens kleiner und schneller.
Für zeitkritische oder hardwarenahe Routinen bietet sich Assembler wirklich an. Direkt die Prozessorenbefehle einzutippen ist natürlich auch nicht schlecht. ;) Aber unter Linux AFAIK etwas schwerer - dank Dateiformat. Unter Windows reicht ja die Endung meistens schon aus.
Btw, Jesus, wieso kommt Assembler in deiner Auflistung vor den Programmiersprachen?

freundliche Grüße, Rolus

[QUOTE=Rolus]Direkt die Prozessorenbefehle einzutippen ist natürlich auch nicht schlecht. ;) Aber unter Linux AFAIK etwas schwerer - dank Dateiformat. Unter Windows reicht ja die Endung meistens schon aus.[/code]
So, dann schreib' mal den Text "Hallo Welt" in eine Textdatei und häng' .exe an den Dateinamen an. Du erhältst kein ausführbares Programm.
Linux hat ein anderes Format für ausführbare Dateien (ELF; Windows benutzt PE), aber das macht das Erstellen von ausführbaren Programmen nicht komplizierter.

Zitat:

---

Btw, Jesus, wieso kommt Assembler in deiner Auflistung vor den Programmiersprachen?

---

Weil ich beim Editieren nicht aufgepaßt habe.

Zitat:

---

Zitat von Jesus_666

So, dann schreib' mal den Text "Hallo Welt" in eine Textdatei und häng' .exe an den Dateinamen an. Du erhältst kein ausführbares Programm.
Linux hat ein anderes Format für ausführbare Dateien

---

Hm, ich habe "Prozessorenbefehle" geschrieben und nicht ASCII-Text.
Wenn ich die Prozessorenbefehle in eine Datei schreibe (den auszugebenden ASCII Text natürlich auch) und das ganze *.exe nenne, bekomme ich eine ausführbare Datei. Also für ein einfaches HelloWorld wäre der Code in hexadezimaler schreibweise:

Code:

---

BA 08 01 B4 09 CD 21 C3 48 61 6C 6C 6F 20 57 65 6C 74 24

---

Erläuterung: BA füllt das DX-Register mit dem folgenden 16-Bit Wert 0108, was der Offset-Adresse des auszugebenden String entspricht. B4 füllt das AH-Register mit dem folgenden Wert 09, weil wir die Funktion 9 des Dos-Interruptes aufrufen wollen. CD 21 ruft nämlich den Dos-Interrupt 21h auf, der einen $-terminierten String ausgibt. C3 ist der Rücksprungbefehl - hier wird das Programm beendet und es geht zurück zu Windows. Der Rest ist der $-terminierte ASCII Code von "Hallo Welt" (48=H bis 74=t) natürlich alles in Hexadezimalschreibweise, damit man es mit einem Hexeditor als *.exe speichern kann und ein ausführbares Programm bekommt (ein sehr kleines HelloWorld - das schafft man mit C nie).
Man kann unter Windows also einfach Prozessorenbefehle in eine Datei schreiben, dieser die richtige Endung geben und ausführen ohne dass man sich an irgendein Dateiformat halten muss. Und ich meine, dass das unter Linux nicht geht - aber probiert habe ich es noch nicht. Wäre aber quasi der gleiche Code, bloß dass man statt Dos-Interrupts natürlich Linux System Calls verwenden sollte.

freundliche Grüße, Rolus

Das sollte unter Linux auch gehen. Anstatt die Datei umzubennen macht man sie einfach ausführbar. (chmod +x datei)

Okay, vielleicht gehts auch nicht. xD

Zitat:

---

Zitat von Rolus

Hm, ich habe "Prozessorenbefehle" geschrieben und nicht ASCII-Text.
Wenn ich die Prozessorenbefehle in eine Datei schreibe (den auszugebenden ASCII Text natürlich auch) und das ganze *.exe nenne, bekomme ich eine ausführbare Datei. Also für ein einfaches HelloWorld wäre der Code in hexadezimaler schreibweise:

[...]

Man kann unter Windows also einfach Prozessorenbefehle in eine Datei schreiben, dieser die richtige Endung geben und ausführen ohne dass man sich an irgendein Dateiformat halten muss. Und ich meine, dass das unter Linux nicht geht - aber probiert habe ich es noch nicht. Wäre aber quasi der gleiche Code, bloß dass man statt Dos-Interrupts natürlich Linux System Calls verwenden sollte.

freundliche Grüße, Rolus

---

Und das funktioniert genau deshalb, weil Windows nicht ausschließlich nach der Dateiendung sieht. Was du schreibst ist eine COM-Datei und Windows weiß das (bei ausführbaren Dateien bestimmt Windows anhand des Inhalts der ersten paar Bytes, um welches Format es sich handelt. Beispielsweise ist bei 9x command.com in Wirklichkeit eine PE und wird auch als solche ausgeführt).

Wie Dingsi schon angemerkt hat hängt die Ausführbarkeit einer Datei unter Linux nur davon ab, ob sie richtig gechmodet ist.
Ob man den Code direkt ausführen kann ist fraglich - als Linux entwickelt wurde was COM schon dermaßen obsolet, daß es im Kernel AFAIK keine Unterstützung dafür gibt. Es sollte aber ziemlich einfach sein, ein Skript zu schreiben, das beliebigen Code im ELF einwickelt.
Falls der Kernel noch mit Unterstützung für a.out kompiliert wurde könnte es auch sein, daß man so relativ einfach seinen Code ausführen kann - aber ich bin mir da nicht sicher.

Zitat:

---

Zitat von Dingsi

Okay, vielleicht gehts auch nicht. xD

---

Nö, bei mir auch nicht.

Zitat:

---

Zitat von Jesus_666

Wie Dingsi schon angemerkt hat hängt die Ausführbarkeit einer Datei unter Linux nur davon ab, ob sie richtig gechmodet ist.

---

Kann ich irgendwie nicht bestätigen. Klar, man kann Shellskripte einfach durch Rechtevergabe ausführbar machen, aber 'binary files' .. ? Lasse mich natürlich gerne eines Besseren belehren, da ich mich wie gesagt unter Linux noch nicht großartig damit auseinandergesetzt habe. Naja, ich mag COM-Dateien. Trotzdem würde mich interessieren, was du daran auszusetzen hast (denn ich nehme mal an, wenn COM-Dateien für Linux obsolet sind, siehst du das genauso ;)). Ich persönlich finde es halt interessant die Befehle in eine (COM-)Datei zu schreiben. Unter Linux hatte ich das Vergnügen bislang noch nicht.

freundliche Grüße, Rolus

Zitat:

---

Zitat von Rolus

Nö, bei mir auch nicht.

Kann ich irgendwie nicht bestätigen. Klar, man kann Shellskripte einfach durch Rechtevergabe ausführbar machen, aber 'binary files' .. ?

Zitat:

---

Ah. Ich dachte, du beziehst dich darauf, daß Windows Dateien mit der .exe-Endung als ausführbar betrachtet.

---

Naja, ich mag COM-Dateien. Trotzdem würde mich interessieren, was du daran auszusetzen hast (denn ich nehme mal an, wenn COM-Dateien für Linux obsolet sind, siehst du das genauso ;)). Ich persönlich finde es halt interessant die Befehle in eine (COM-)Datei zu schreiben. Unter Linux hatte ich das Vergnügen bislang noch nicht.

---

Die Nachteile von COM-Dateien sind, daß sie sehr primitiv und für moderne Software kaum geeignet sind - kein Wunder, immerhin wurden sie für CP/M und das erste 8 bit-DOS entwickelt. Beispielsweise können COM-Dateien nicht größer als 56280 Byte sein.
Unter Windows sind COM-Dateien nur deshalb noch ausführbar, weil Microsoft die Abwärtskompatibilität heilig ist; für moderne Softwareentwicklung hat das Format keine Bedeutung. Linux verwendet schlicht ein neueres Format und war nie zu COM-Dateien kompatibel, weshalb es wenig Sinn macht, Abwärtskompatibilität einzuführen.

COM-Dateien sind schlicht ein Relikt aus alten Zeiten, so wie der ISA-Bus oder der DIN-Stecker für Tastaturen. Für die Lowlevel-Entwicklung sind sie irrelevant, da man normalerweise sowieso in Assembly schreibt - das direkte Schreiben von Maschinencode ist extrem selten geworden, zumindest auf PC-Plattformen.