PB kann alles?

[Kristel]

Ansonsten: Möglich ist (fast) alles. Die Frage ist, ob es in einer anderen Sprache nicht leichter ist.

Jo, das "(fast)" kannste aber weglassen. Denn PB untersützt ja Inline Assembler und wie wir alle wissen ist mit Assembler alles zu programmieren.

Ein Betriebssystem kannst Du trotzdem nicht mit PB-InlineASM
oder !DirectASM programmieren

Nix gegen dich, aber meiner Meinung nach müsste es doch gehen.
Man muss ja nicht das OS ins PB programmieren, man kann auch
einfach Inline Assembler einsetzen und kein bischen PB verwenden.
Trotzdem kann man grade noch so sagen, dass es mit PB geschrieben wurde,
weil ja der Compiler von PureBasic verwendet wurde.
Oder steh ich jetzt total auf dem Schlauch, wenn ich sage das jedes
Programm(auch Betriebssystem) aus Maschienencode besteht und der
ja als Inline Assembler in PB integriert ist. Wenn ja erklär mir bitte,
warum ich theoretisch kein OS mit PB machen könnte. Das niemand
der noch einiger Maßen klar im Kopf ist das macht, ist mir schon klar.

[MVXA]

irgendwie, hast du auf ne bizarre art und weise recht
man könnt sogar PB stückweise verwenden. z.b. kann man if konstruktionen verwenden. nur sollte man strings nicht verwenden. da beißt es sich

[Lars]

Nein, das geht so nicht.

Erstens ist es natürlich seltsam, reinen ASM Code zu schreiben, der Quasi
nur durchgereicht wird und das dann als PB zu verkaufen. Das wäre noch
schöner, als in PB einen C++ Compiler zu basteln, dann den C++ Code
vom PB Compiler compilieren zu lassen und es PB zu nennen

Und zum Thema ASM, man muss wohl bei der Kompilierung von
Betriebssystemen einiges compilertechnisches Beachten, was der PB ASM
Compiler natürlich nicht tut (jemand andere kann da bestimmt präzisere
Infos zu geben, aber ich hoffe doch, dass ich das Prinzip richtig
verstanden und dargelegt habe )

[Danilo]

Nix gegen dich, aber meiner Meinung nach müsste es doch gehen.

Es geht nicht. Probier es, und Du wirst bald sehen woran
es scheitert.

Ich habe früher über mehrere Jahre OS-Entwicklung "studiert"
(d.h. mich damit intensiv beschäftigt) und ich kann Dir dies alles
sicherlich nicht hier erklären. Da könnte ich auch ein Buch schreiben
"Warum ist es keine gute Idee mit PureBasic ein OS zu schreiben?"
und es dann verkaufen (und Milliarden dabei einsacken ).

Was Du hier versuchst ist allerdings alles nur theoretisch,
und ich verstehe Deine Denkweise ganz gut. PB produziert
trotzdem weiterhin Win32 Executable unter Windows und ist
abhängig vom Win32-Loader. Nach dem POST wird der MBR
geladen und dieser lädt dann das OS. Das ist das erste Problem:
Du bist im 16-bit RealMode. Von PB genausowenig unterstützt
wie von FASM/Win32 (bedenke: Assembler ist nicht gleich Assembler!).
Lässt man den Bootloader weg bist Du danach immernoch im
RM16, was nicht unterstützt wird. Von da aus mußt Du in den
PM wechseln und mußt erstmal den kompletten Win32-Loader
inkl. Import-, Alloc- und Reloc-System nachbilden.
Kompiliere doch mal eine leere (!) PB-EXE und schau Dir Diese
mal mit meinem PE-Viewer an. Dann siehst Du mal so ungefähr
welche Sachen von Windows Du nachprogrammieren mußt,
bis erstmal der Ladevorgang abgeschlossen ist.
Das ganze ist mit PB nicht möglich.

Wenn Du dann soweit bist sehen wir weiter und schauen uns
an ob Du mit PB den Kernel weiterführen kannst...

[Kristel]

(jemand andere kann da bestimmt präzisere Infos zu geben,
aber ich hoffe doch, dass ich das Prinzip richtig verstanden und dargelegt habe )

Nein, hab ich nicht verstanden so wie du es erklärt hast.

@Danilo Ich glaube ich weiß jetzt ungefähr, warum es rein technisch
nicht machbar ist mit PB ein OS zu coden. Habs zwar immer noch nicht
so richtig begriffen, aber ich werd es mir in Zukunft so erklären, dass
alles der Compiler den Code zu "Windowscode" macht und er daher nicht
als ein eigenständiges OS zu gebrauchen ist.

Nur beantworte mir eine Frage.
Währe es theoretisch möglich ein OS mit PB und seinem Inline
Assembler zu coden (ohne auf die Zeit oder den Aufwand einzugehen ) ?

Da könnte ich auch ein Buch schreiben
"Warum ist es keine gute Idee mit PureBasic ein OS zu schreiben?"
und es dann verkaufen (und Milliarden dabei einsacken ).

Du bringst einen immer auf so gute Ideen

[Deeem2031]

@Kristel: Nein, geht nich. PB produziert 32-bit Code und ein Bootloader (welcher in jedem OS sein muss) ist 16-bit Code.
Da kannste in den Editor hämmern was du willst, PB mag 16-bit nich.

[Zaphod]

ausserdem produziert pb windows executables, auch wenn du das ganze programm in assembly schreibst. wenn du ein os in assembly schreiben wolltest, müßtest du also auch dafür einen anderen assembler bemühen.

[PureBaser]

Abgesehen davon:

Wer ein OS schreiben will, ganz egal welche Programmiersprache, müsste im Forum jede Frage mit links beantworten, die Rechner- sowie PC- und CPU-Architektur von den Anfängen bis in die Zukunft wissen (d.h. er fängt heute an, veraltetetes zu lernen). Ne Menge Hardwarekenntnisse braucht er natürlich auch (IRQ,E/A-Ports,NTFS-System ectl.) doch dass alles führt zu

[MVXA]

es ist möglich mit PB ein OS zu schreiben, man muss halt nur etwas tricksen. z.b. muss man den ASM code von PB halt etwas modifizieren und dann nochmal mit FASM manuel kompilieren.

ein umfangreiches Tut zu OS programmierung findet man unter www.lowlevel.net.tc

[Danilo]

Wer ein OS schreiben will, ganz egal welche Programmiersprache,
müsste im Forum jede Frage mit links beantworten,

Wer ein OS schreiben will muß sich doch nicht mit PB-Bugs
oder dem WinAPI auskennen. Derjenige muß auch nicht
wissen wie man denn nun mit Milkshape Objekte für die
alte PB-OGRE Version erstellt.

die Rechner- sowie PC- und CPU-Architektur von den Anfängen
bis in die Zukunft wissen (d.h. er fängt heute an, veraltetetes zu lernen).

Wieso veraltetes Wissen? Dein heutiger PC funktioniert
heute noch genauso wie ein 8086, 286er und 386er.

Was mit jedem Schritt dazukam sind Erweiterungen.
Auch die Rechner die Du in näherer Zukunft nutzen wirst
(aufbauend auf AMD64) verwenden das gleiche Prinzip und
bauen auf den 80x86 auf.

Ne Menge Hardwarekenntnisse braucht er natürlich auch
(IRQ,E/A-Ports,NTFS-System ectl.)

Das NTFS-Dateisystem braucht man da überhaupt nicht
zu kennen.

doch dass alles führt zu

...besserem Verständniss für das System auf dem man
programmiert.
Wer das System kennt, auf dem er codet, ist sicherlich
ein besserer Programmierer.

Selbst das LowLevel-Wissen über den Real- und ProtectedMode
ist kein dummes Zeug. Das gilt genauso auch für Linux und
Windows auf x86, und wenn man das System kennt, dann
kann man eben auch besser programmieren und weiß bei
Fehlern woran es liegt.

Je mehr man weiß, desto mehr kann machen. Wenn Du
nur QBASIC und PB kennst sitzt Du dann erstmal ziemlich
dumm da wenn Dein Programm in bestimmten Situationen
einfach crasht. Wenn Du aber das System 'Windows' kennst,
kommst Du schon ein bissl weiter.

Ich kann beim programmieren eben mehr machen wenn
ich ASM und die CPU-Architektur kenne.

Wenn Du ein Bildbearbeitungsprogramm + Filter schreibst
ist das schön.
Wenn bei meinem Bildbearbeitungsprogramm die Filter alle
5 mal schneller abgearbeitet werden, dann ist der User
sicherlich zufriedener als wenn er dauernd 10 Sekunden
warten muß.

Ein Fenster öffnen und "Hallo Welt" reinmalen kann jedes Kind.
Einen virtuellen Gerätetreiber für CDROMs coden aber nicht,
genauso wie einen Emulator für irgend ein System.
Das können nur Leute die was drauf - und das entsprechende
Wissen haben.


Je mehr man weiß, desto mehr Möglichkeiten hat man.
Jemand mit "veraltetem Wissen" kann dann halt mehr
und bessere Sachen machen als Du...