Ich bin regelrecht erstaunt. Als ich deinen Post las, dachte ich spontan "da muss es doch zigtausend Sachen in Google geben", hab kurz selber nachgeschlagen - und auf die Schnelle nichts in einer Form entdeckt, was ordentlich Auskunft gegeben hätte.
Zum ersten Punkt (Unterschied zwischen FreePascal 1.1 und 2.0) kann ich dir nichts sagen, da ich noch nie mit FreePascal gearbeitet habe.
Aber zum zweiten Punkt (aus einem DOS-Programm ein Windows-Programm machen), da habe ich durchaus etwas zu erzählen.
Ich habe es schon oft erlebt (und erlebe es teils noch immer), dass sich Chef und/oder Programmierer denken "wir machen mal aus unserem alten DOS-Tool irgendwie ein Windowsprogramm". Dummerweise war es dann fast immer das "irgendwie", was zum Genickbruch führte. Denn die Programmierung unter Windows unterscheidet sich
erheblich von der DOS-Programmierung.
Ich lasse mal so "Kleinigkeiten" wie verändertes Speichermanagement (DOS: 16 Bit, Windows: 16-64 Bit) weg und gehe zu etwas Greifbarerem:
- Wenn du eine Taste drückst, was passiert dann? Unter DOS? Unter Windows (als Beispiel sei mal Windows XP angenommen)?
Klar, unter DOS werden entweder irgendwelche Zeichen in der Kommandozeile erscheinen oder das gerade laufende Programm reagiert halt entsprechend auf den Tastendruck. Unter Windows ist das schon wieder ganz anders. Denn da ist von Anfang an gar nicht sicher gestellt, wo der Tastendruck überhaupt empfangen wird. Kümmert sich Windows selbst darum? Oder das gerade aktive Programm? Oder eines, das im Hintergrund läuft? Und bloß weil du ein Programm in einem Fenster laufen siehst, heisst das noch lange nicht, dass dieses das derzeit aktive Programm von Windows ist.
- Wie sollen Ausgaben des Programms dargestellt werden?
Unter DOS werden überwiegend einfach entsprechende Buchstaben an die Standardausgabe geschickt und fertig.
Unter Windows... tja, an welche Position sollen denn die Ausgabezeichen geschickt werden? 100/100? 200/350? Oder ist das Fenster gerade inaktiv und nicht sichtbar und die "Ausgabe" muss im Hintergrund aktualisiert werden? Und in welcher Schrift darf es denn sein? Tahoma? Arial? MS Serif?
Unter DOS laufen Programme normalerweise einzeln (von irgendwelchen Treibern im Hintergrund mal abgesehen). Dein Programm läuft und Tastatur, Maus und Bildschirm werden diesem Programm "zugeordnet". Das Programm erledigt seine Aufgabe, kehrt dann zu DOS zurück und du kannst wieder in DOS arbeiten.
Unter Windows wird ein völlig anderer Mechanismus verwendet. Während "normale" DOS-Tools meist im Textbildschirm (80x25) ablaufen, funktioniert Windows schon mal grundsätzlich nur im Grafikmodus. Das verändert schon einmal die Ausgabe ganz gewaltig. Jetzt gibt es nicht mehr von DOS vorgegebene Zeichenmatrizen, die auch von DOS gemütlich Zeile für Zeile auf den Bildschirm gebracht werden, sondern unter Windows ist das Programm selber dafür verantwortlich,
jeden einzelnen Pixel, der zu einem Buchstaben gehört, in der richtigen Farbe an die richtige Stelle zu pinseln. Natürlich ist das eine irrsinnige Arbeit. Und um diese zu erleichtern gibt es eben u.a. die WinAPI. Mit der hast du ein paar Funktionen, die du aufrufen kannst und die dir diese Arbeit erleichtern.
Es geht aber noch weiter.
Unter DOS läuft normal immer nur ein Programm. Unter Windows sind es viele, die gleichzeitig laufen. Außerdem verwendet Windows ein Nachrichtensystem, das in dieser Form in DOS völlig unbekannt ist. Windows ist (aus Programmierersicht gesehen) ein ziemlicher Schreihals. Ständig rufen Betriebssystem, Treiber und Programme sich gegenseitig Botschaften zu und eine der wichtigsten Aufgaben von Windows ist die Verwaltung dieser Botschaften. So eine Windowsnachricht kannst du dir durchaus wie eine Mini-Email vorstellen (das hilft imho beim Verständnis): Die Nachricht läuft über einen bestimmten Kanal, hat einen Adressaten, einen "Betreff" und evtl. noch weitere Informationen.
So könnte eine Nachricht z.B. lauten:
Kanal: WM_BROADCAST, d.h. die Nachricht wird quer durch ganz Windows "geschrien".
Adressat: Notepad
Betreff: "Datei öffnen"
Zusatz: "C:\fubar.txt"
Auf der anderen Seite hockt nun Notepad und lauscht auf die Nachrichten, die da hin- und herfliegen. Jetzt bekommt es über den Broadcast-Kanal mit, dass es angesprochen wird, kapiert, dass es eine Datei öffnen soll, schaut nach dem Dateinamen, der auch vorhanden ist und versucht, die Datei zu öffnen. Während Notepad das alles macht, hält aber nicht der Rest von Windows gespannt den Atem an und wartet ab, ob Notepad Erfolg hat oder nicht, nein, das fröhlihe Nachrichtendurcheinanderschreien geht derweil weiter.
Und spätestens hier hat ein reines DOS-Programm bereits ausgespielt. Denn für ein DOS-Programm stellen sich folgende Probleme:
- Das DOS-Programm weiss gar nicht,
dass es die Nachrichtenkanäle gibt und hat auch keine Ahnung, wie es auf Nachrichten lauschen kann.
- Der "Name" der DOS-Programms ist Windows völlig unbekannt, es kann also nicht von Windows adressiert werden.
- Wenn schon die Nachrichten dem DOS-Programm unbekannt sind, dann sind es die Befehle und Zusatzinformationen in den Nachrichten erst recht.
Das DOS-Programm kann gar nicht mit Windows "reden" und bekommt daher von Windows auch keinen Speicher zur Verfügung gestellt, keine Tastatureingaben, keine Mauseingaben, keine Möglichkeit, irgendwelche Ausgaben zu fabrizieren etc.pp.
Natürlich liesse sich deinem Programm mittels entsprechender Verwendung der WindowsAPI all dies beibringen. Dann könntest du auch einen schicken Rahmen um dein Programm zeichnen, mit Buttons zum Maximieren und Minimieren und dergleichen. Dazu kann ich sagen, dass dies vor 20 Jahren so üblich war und sich sehr schnell als dermaßen umständlich, aufwändig und redundant erwies, dass relativ rasch sogenannte "Frameworks" oder "Rahmenwerke" entstanden und gleichzeitig die sog. "visuelle Programmierung". Die Rahmenwerke kapseln die Windows API noch etwas weiter ab. Statt eines
Code:
MakeWindowRect;
PlaceWindow(10, 10);
SetBorderColor(Grey);
SetCharColor(Black);
SetCharSize(11);
SetBackgroundColor(LightGrey);
PaintWindow(10, 10);
...
konnte - sinngemäß - einfach gesagt werden:
Code:
MakeWindow(10, 10, Colors.Windows);
Das da oben ist natürlich alles Pseudocode, aber ich hoffe er macht ein bisschen deutlich, weshalb die Programmierung mit der WinAPI extrem umständlich ist und unter Windows normal ein Framework verwendet wird.
Damit man aber nicht in jedem Pascalprogramm erst laaaangwierig rumschreiben musste (MakeWindow; ShowWindows; MoveWindowTo...), entstand u.a. - tadaa! - Delphi. Ja, ja, an dieser Stelle werden sofort die Puristen mit Objektorientierung, Object Pascal usw. usf. kommen, dieses Feld überlasse ich denen.
Was für dich jetzt im Moment relevant sein dürfte ist dies:
Wenn du dein Pascal-Programm
nur mit Hilfe der WinAPI zu einem Windowsprogramm koventieren willst, dann viel Glück. Da wirst du dich ziemlich einlesen müssen, als Googlesuchbegriffe würde ich verwenden: "Pascal", "WinAPI", "-Deplhi".
Ansonsten kannst du es mal mit diesem Link versuchen:
Delphi Praxis. Gestestet habe ich ihn noch nicht, ob er noch aktuell ist, aber wenn nicht dort, dann gibt es anderswo kostenfreie bzw. Test-Delphiversionen von Borland selbst. Mit denen kannst du dann den ganzen Windows-Rahmen für dein Programm schaffen und dann die Funktionalität deines Programms selbst entsprechend übertragen.
Nachtrag:
Woah, guten Morgen und so. Hier im Delphi-Forum selbst sind ja noch sticky threads, in denen steht, wo du freie Delphi-Versionen herbekommst.
