Der Neue

[Theo Gottwald]

Hi Theo, habe vor 2 Tagen eine "private Nachricht" wegen Deinem Anliegen an Stan geschickt - bisher ohne Antwort.

Danke, Norbert.

[Theo Gottwald]

Hallo Jürgen,
wie wärs du machst aus dem Ding ein Community-Project und gibst den Koordinator?
Dann könnten Andere zum Beispiel an einem Linker oder Code-Teilen des Compilers arbeiten.
Das könnte alles beschleunigen.

[Peter Salomon]

@Norbert #029
Wenn ich mir das richtig übersetzt habe, ist JK noch im alpha-Stadium, d.h. bei Weitem noch nicht an den Funktionsumfang von PBWin10 mit über 1400 Befehlen herangekommen.
Als Einzelkämpfer mit diversen Nebenverpflichtungen kann das noch Jahre dauern, bis da was Brauchbarens rauskommt. An einem hilfreichen User-Kontakt ist er offensichtlich auch nicht interessiert - wobei in der Altersgruppe wie ich man eigentlich immer hocherfreut über jeglichen Kontakt ist.

@Theo #31
Deinen Vorschlag kann ich nur begrüßen - obwohl, warum sollte man das Rad neu erfinden, wo doch alles schon da ist.
Wir sollten "nur" PBWin in den Status von OpenSource überführen und der User-Gemeinde das weitere Updaten überlassen ...
Die Frage ist halt - wie könnte das geschehen ohne Kontakt zu PowerBASIC Inc.? Ob die an einer solchen Lizensierung je interessiert sein werden?
Die andere Möglichkeit an den Quellcode heranzukommen ist Reengineering, wobei mir hierbei die Rechte-Problematik nicht geläufig ist.

Wenn PBWin durch Jürgen K. von Grund auf neu programmiert wird, sollte wenigstens das Referenz-HB sozusagen als "Pflichtenheft" zur Grundlage genommen werden. Ansonsten sehe ich den Anspruch der "fast" 100% Kompatibilität kaum erreichbar.

Grüsse aus Ahrensfelde

Peter Salomon
www.ps-blnkd.de

[Norbert Spoerl]

Hi Peter,

nimm es mir nicht übel, doch ich muß Dir leider sagen, dass Du mit Deinem letzten Beitrag ziemlich daneben liegst.

- Das mit dem OpenSource ist im offiziellen Forum ausdiskutiert -> no Chance!!!
- An den PB-Quellcode herankommen -> wurde probiert -> no Chance!!!

Das Thema wurde hoch und runter intensiv von den ASM Spezies diskutiert. Und auch der jetzige Eigentümer von den PB-Quellen wurde kontaktiert. Im Endeffekt ist der Quellcode von dem ASM-Genie Bob Zale so hochkomplex/kompliziert angelegt, dass er von einem anderen nicht weiter entwickelt werden kann. Und der Eigentümer hat auch kein Interesse an der Weitergabe des Quellcodes.

- "Als Einzelkämpfer mit diversen Nebenverpflichtungen kann das noch Jahre dauern ..." -> JKBasic sollte eigentlich in diesem Sommer fertig sein (SDK-Programming!!!). Ein Umzug mit Haussanierung kam dazwischen. Ziel ist nun Ende des Jahres. Ich kann bereits jetzt damit programmieren.
- "Referenz-HB sozusagen als "Pflichtenheft ..." -> Das war doch von Anfang an die Intension von JK, PB nahe zu 100% umzusetzen. In PB gibt es aus Kompabilitätsgründen einige alte Befehle. Die werden nicht mit umgesetzt. Z.B. MAKDWD und MAKLNG - es gibt nur noch MAK(..,..,..). Daher das >nahezu< bei den 100%.

Ich wollte hier nur kundtun, dass es sich lohnt, noch einige Monate zu warten, bevor man kurzfristig auf eine andere Sprache umsteigt. Und mehr werde ich jetzt zu dem Thema nicht mehr sagen.

Gruß
Norbert 

[Peter Salomon]

@Norbert #33

Danke für Deine Infos, aber wieso sollte ich mit meinem Beitrag "ziemlich daneben liegen"?
Daß das Thema PBWin -> OpenSource im offiziellen PB-Forum diskutiert wurde, ist mir leider entgangen. Die kurze Zeit wo ich dort gelegentlich reingeschaut habe, habe ich davon nichts gefunden. Mir ist nur damals (Frühjahr 2025), daß Adam Drake schrieb, daß er an der 64Bit-Portierung von PBWin arbeitet und daß es wegen der "unsäglichen" INTEL-Doku äußerst schwierig ist.
Wegen des Themas "Zukunft von PBWin und ggf. OpenSource" wollte ich mich ja dort anmelden - ist aber nichts mehr draus geworden ...
Nun ist das Forum abgeschaltet und man kann nichts mehr nachlesen, oder hast Du ggf. Beiträge gesichert?

Das Reengineering bei ~900kB Compiler und ~1,4MB IDE kann doch mit den heutigen Werkzeugen, z.B. IDA oder GHIDRA sicherlich lösbar sein.
Übrigens gibt es in der PB-Codesammlung sogar einen Diassembler - mal schauen, ob und wie der funktioniert.
Zunächst will ich mal versuchen die exe meines kleinen Testprogramms (GUI, OK und Abbrechen-Bottum) rückzuübersetzen.
Einen Assembler2BASIC-Converter habe ich allerdings noch nicht gesehen ...

Grüsse aus Ahrensfelde

Peter Salomon
www.ps-blnkd.de

[Theo Gottwald]

Hallo Norbert und Peter,

wir wollen hier nicht zu streng sein, Norbert. Peter ist neu bei uns und zeigt großes Engagement. Wenn er noch ein paar Jahre warten kann, hat er gute Chancen, dass die KI das Reengineering vollständig eigenständig durchführt. Bitte bedenke jedoch: PowerBasic ist ein 32‑Bit-Compiler, während zukünftig mindestens 64‑Bit erforderlich sein werden. Soweit ich weiß, arbeitet Jürgen an einem 32/64‑Bit-Compiler. Das scheint mir die erste Hoffnung zu sein, dass wir eine Lösung erhalten, bei der die PowerBasic-Syntax weitgehend erhalten bleibt.

Die KI entwickelt sich weiter; wenn du sie nutzt, würde ich jedoch das Pferd anders herum aufsetzen. Soweit ich weiß, hat Jürgen noch keinen wirklich guten Linker: er verwendet etwas von Microsoft oder Ähnlichem. Er benötige eigenständige Linker und Assembler, die auch eigenen Code verarbeiten können. Ich würde lieber damit anfangen, als ein völlig neues Projekt zu starten – nur als Tipp.

Heutzutage lässt sich so eine Aufgabe relativ leicht mit KI erledigen, wenn man die Zeit dafür hat. Man kann die KI einfach die großen Unterschritte entwerfen lassen, zum Beispiel den gesamten Plan. Nehmen wir den Linker: Was muss er können? Lässt du dir die benötigten Programmteile auslisten, kannst du diese von der KI designen lassen.

Ein Problem ist, dass das wahrscheinlich schon 64‑Bit sein muss, weil bei 32‑Bit ein Limit bei den Executables von 2 oder 4 GB besteht – das reicht in Zukunft vermutlich nicht mehr. Also muss irgendwann auf 64‑Bit umgestellt werden, und jetzt scheint der richtige Zeitpunkt dafür.

PowerBasic ist zwar nicht schlecht, aber es ist noch nicht kaputt. Du kannst es weiterhin problemlos nutzen. Erstens: du könntest einen Pre‑Compiler für PowerBasic entwickeln, der viele Features nach PowerBasic plus Inline‑Assembler umsetzt. Dafür benötigst du wahrscheinlich nur einen neuen Editor und das wäre eine Möglichkeit, PowerBasic weiterleben zu lassen – allerdings bleibt es ein 32‑Bit-Produkt.

Dass Adam Dreck behauptet, er wolle eine 64‑Bit-Portierung machen, halte ich für sehr gewagt. Ich glaube nicht, dass daraus etwas Nützliches entsteht. Bob Zähl war ein Assembler‑Genie und konnte PowerBasic entwickeln; Adam Dreck kennt sich gut mit Steuern aus und vielleicht weiß er inzwischen auch, wie er seine Gesundheit besser in den Griff bekommt. Er ist jedoch nicht in der Lage, genialen Assembler-Code zu schreiben. Ein solches Produkt, basierend auf PowerBasic, würde mehr Fehler haben als Vorteile bringen. Dafür brauchst du wirklich spezielle Personen mit speziellen Fähigkeiten. Ich vermute, dass selbst die KI sich im Moment schwer tun würde, diesen Code weiterzuentwickeln.

PowerBasic ist nicht die Basis für einen Source‑Code – selbst wenn du ihn hättest, wäre das problematisch. Stattdessen könntest du einen Editor erstellen, den PowerBasic-Compiler als Backend nutzen und unter der Haube PowerBasic-Code sowie PowerBasic‑Inline‑Assembler-Code generieren. Definiere deine eigene Sprache: so kannst du jederzeit die Beschränkungen der PowerBasic-Syntax umgehen.

Wenn ich viel Zeit hätte, würde ich das auch machen. Das Problem bleibt jedoch: kein 64‑Bit-Unterstützung. Hier kommt Jürgen (und vielleicht auch Charles) ins Spiel; Charles hat ebenfalls einen sehr guten Compiler entwickelt. Dieser wäre ein geeignetes Backend für dich: wenn du wirklich einen PowerBasic-Compiler erstellen willst, könntest du den Compiler von Charles übernehmen – wir haben sogar den Source‑Code. Du änderst einfach den Code so, dass er statt seiner eigenen Syntax die PowerBasic-Syntax kompiliert. Das wäre viel einfacher. Der Compiler von Charles kann fast alles und müsste wahrscheinlich kaum angepasst werden.

Denke lieber in diese Richtung und vergesse alles, was mit Disassembler usw. zu tun hat. Die PowerBasic-Quellcode‑Dateien sind nicht wirklich Open Source; selbst wenn du sie disassemblierst, hast du keine Rechte daran. Lass das lieber sein und überlege dir eine andere Strategie.

[Norbert Spoerl]

Hallo,

in Post 33 schrieb ich: >>>Und mehr werde ich jetzt zu dem Thema nicht mehr sagen.<<<
Darum, und weil ich Peter nicht verärgern will, habe ich auf seinen letzten Beitrag nicht reagiert.
Theo hat das ganz gut beschrieben. Es bringt nichts, sich mit Bobs ASM-Code herumzuschlagen. Adam Drake hatte Zugriff auf den Quelltext - nutze ihm aber Null. Sein Versprechen, einen PB-Nachfolger zu kreieren hat er schon vor längerer Zeit kassiert.
Ich finde den Ansatz von JK sehr gut, da 1. praktikabel, 2. ausbaufähig und 3. zukunftssicher, weil er die Weiterentwicklung der möglichen verwendbaren Compiler anderen überläßt, z.B. MS.
Als 1. Zeile des Quellcodes steht entweder #compiler jk-basic 32 oder #compiler jk-basic 64, den Rest macht die IDE, um 32 oder 64 bit Ausführcode zu erstellen. Natürlich müssen von 32 auf 64 bit einige Variablendeklarationen angepaßt werden. Was unter 32 bit als DWORD ging, muß in einigen Fällen (z.B. Handles) bei 64 bit auf 8 Bytes breite Variablen umgestellt werden (XWORD, XLONG).
Warum wird die ganze Zeit über Alternativen zu PB diskutiert, und warum haben schon Viele das Schiff verlassen? Doch nicht weil PB keine guten Funktionsumfang hat. Hauptsächlich darum, weil die Zukunft in Richtung 64 bit versperrt war. JK eröffnet die Zukunft für die Programmierer, die ihre PB-Quellcodes mit wenig Aufwand auf 64 bit heben wollen. 

Gruß

[Theo Gottwald]

Ja, das sehe ich auch so, Norbert.
Hab mir gestern zum Spaß so ein paar Videos auf Youtube angeschaut wie Compiler programmiert werden.
Es gibt eine ganze Menge davon.
Man braucht immer noch ein seht großen Esstisch und viel Papier um die genaue Syntax jedes Befehls aufzuzeichnen.
Wenn man es richtig machen will.
Die Meisten modernen Compiler verwenden eine Tokenisierung die in einem Zug auch als Syntaxcheck verwendet wird.

Man kann das aus Spass machen, es geht  so:

Compiler Design

Aber man muss wissen dass es schon jede Menge davon gibt.
Und an vielen arbeitet ein ganzes Team Experten.

D.h. man kann nur eine Nische belegen und man wird immer den aktuellen Trends hinterherlaufen.
Das wird also kein finanzieller Erfolg aber es kann Spass machen denn man kann Elemente einbauen die man persönlich gut findet oder benötigt.

Ich habe ja mit dem SPR auch so ein Scripting-System und da habe ich nun "Auto-Increment Variablen" eingebaut.
Das sind Variablen die sich incrementieren wenn sie angefasst werden.

Irgendwann baue ich auch noch ein dass man Variablen ein Unterprogramm geben kann, das ausgeführt wird, wenn die Variable angefasst wird.

So Sachen kann machen, wenn man ein eigenes System hat und überall reingreifen kann.

Ein komplettes System aus Compiler, Assembler und Linker - nur für x64 - würde meiner Meinung nach mehr als 1 Jahr Arbeit kosten. Wenn man jedoch die Funktionen einfach aus einer Runtime DLL aufruft und die Kernelement auf die Speicherverwaltung beschränkt kann man sowas machen.

Dann kommt aber immer noch die
- Dokumentation,
- das Testing
und das ist natürlich mit KI jetzt einfacher aber kostet noch Mal mindestens genau soviel Zeit wie die Implementierung.
Viele denken mit der Implementierung ist es getan, nein das ist nur die halbe Miete.
Wenn es nicht perfekt dokumentiert und getestet ist, ist es eigentlich noch nicht fertig.

Von daher wäre es für Jürgen natürlich super wenn du  Norbert zum Beispiel das Testing machst.
Dann bräuchte er noch jemand der das Ding dokumentiert. Das würde Ihm enorm viel Zeit sparen.

PS: Falls hier aus dem Forum jemand den SPR testen möchte, auch da freue ich mich über Tester.
Man kann damit sehr spezielle Anwendungen machen, genau genommen AddOns zu bestehenden Programmen,
 dieses hier zum Beispiel.
Beispielscript Blenderbar

[Zlatko Vid]

Mit vollem Respekt vor dem Autor von PowerBasic
einfach ... die Zeiten ändern sich
und PowerBasic ist ein veraltetes Produkt
und der Held, der es wirklich aus der Erde geschafft hat
ist Charles, der Oxygen Basic entwickelt.
In vielen Dingen ähnelt PowerBasic.
Warten auf einen neuen PowerBasic-ähnlichen Compiler
Ich verschwende nur Zeit.
aber das bin nur ich...

[Charles Pegge]

OxygenBasic wurde von Grund auf neu entwickelt, beginnend mit Maschinencode. Ich begann im Jahr 2008 und arbeitete mindestens 12 Jahre lang vollzeit daran.

Wenn Compiler deine Leidenschaft sind, lohnt sich der Aufwand auf jeden Fall, andernfalls bist du herzlich eingeladen, OxygenBasic als Ressource zu nutzen. Es wird komplett mit selbst-kompilierendem Quellcode geliefert.

[Peter Salomon]

@Charles Pegge #39
Es erfreut mich außerordenlich, daß Du immer noch an Deinem "OxygenBASIC" arbeitest.
Schon vor einiger Zeit - bevor ich auf PowerBASIC kam, wollte ich mir das mal anschauen. Aber weder der Download der chm.-Datei noch der Programm-Zip waren zu gebrauchen - mit 127kB offensichtlich "beschädigt".
Die Ablage in Grithub ist für mich zwar sehr gewöhnungsbedürftig, aber beim heutigen Download sieht das etwas anders aus. Das "OxygenBasic_Manual.chm" (136kB) ist jetzt lesbar und auch in die Zip (6MB) konnte ich schon mal "hineinsehen".
Obwohl ich im Manual keinen Hinweis auf COM - mein hauptsächlichstes Interessengebiet - gefunden habe, ist in den Beispielen alles Mögliche vorhanden - auch COM. - Das muss ich mir im Detail noch ansehen ...
Sehr begrüßenswert ist natürlich die Möglichkeit auch 64Bit-Programme erzeugen zu können.

Wie sieht es mit der notwendigen IDE (Editor/Debugger) aus?
Ist Dein "OxygenBASIC" OpenSource oder ein kommerzielles Produkt?
Eine deutsche Version wäre auch sehr angenehm - ja, ich weiß - alle Leute lieben englisch!

Grüsse aus Ahrensfelde

Peter Salomon
www.ps-blnkd.de