Hallo zusammen!
Ich bin neu hier und ein Fan von PowerBASIC für Windows.
Für die Vorgeschichte müsste ich etwas ausholen, weil es "um 1000 Ecken" geht.
Der Einfachheit halber kann das hier nachgelesen werden: ->
https://www.mikrocontroller.net/topic/574459#new
Es ist ein ellenlanger Thread, wo ich mit meinem TO nur niedergemacht wurde und fast niemand sich die Mühe gemacht hat auch nur ansatzweise mal in die über 2000 Seiten Doku zu schauen.
Wie ich dort schon schrieb, hat die 10er Version von PBWin nur noch sehr wenig mit BASIC zu tun und umso mehr ich mich durch die Doku übersetzenderweise gequält habe, umso mehr bin ich von diesem einzigartigen Programmierwerkzeug überzeugt.
In meinen weiteren Postings im o.g. Thread hatte ich dann erklärt, warum und wieso ich eigentlich auf PowerBASIC gekommen bin.
Einige ganz kleine, aber grundlegende Versuche habe ich schon machen können, aber das eigentliche Vorhaben - die COM-Schnittstelle von TurboCAD bedienen zu können, steht noch aus.
Zwischenzeitlich hatte ich versucht mich im Original PowerBASIC-Forum anzumelden, aber das ist bis heute in der Schwebe, d.h. die Authetifizierung durch den Admin ist immer noch nicht erfolgt.
Auch der direkte Kontakt zu Gary Beene war letztendlich nicht erfolgreich.
So bin ich sehr froh nun hier gelandet zu sein - und auch noch in deutsch schreiben zu können!
So viel für heute.
Grüsse aus Ahrensfelde (bei Berlin)
Peter Salomon
www.ps-blnkd.de
Hallo Peter,
willkommen im Forum.
Wir haben die deutsche Ecke und es gab hier und da auch mal einen der das genutzt hat (Peter Weiss war wohl der letzte).
Alle anderen Forumsteilnehmer die mir gerade einfallen sprechen nur english oder spanisch.
Hallo zusammen!
nun ist die Urlaubszeit vorbei und ich bin in der Zwischenzeit nicht untätig gewesen.
Nachdem ich mir begeistert die >2000Seiten-Doku zu PBWin10 "reingezogen" und übersetzt hatte, ist mir nun auch noch das Referenz-Handbuch von 2023 "zugeflogen". Auch dazu bin ich am übersetzen, weil es dann (für mich) einfacher ist damit zu arbeiten.
Leider ist mir nicht bekannt welches "Beiwerk" der damalige Distributor Kirschbaum-Software -> http://www.powerbasic.de/index.althtm (http://www.powerbasic.de/index.althtm) beim Vertrieb der PowerBASIC-Produkte für den deutsch-sprachigen Raum dabei hatte. Dessen HP ist nur noch als Start-Seite online, alles Weitere ist leer!
Außer meinem aktuellen Problem mit der COM-Technologie - die hoffentlich (so sieht's jedenfalls momentan aus) mit PBWin10 lösbar sein wird, will ich versuchen mal die Unterschiede bei der Compilierung mit VB und PBWin10 herauszubekommen, um die Effizienz besser bewerten zu können. Bisher sind mir leider nur Behauptungen bekannt ...
Wenn weitere Ergebnisse vorliegen, werde ich wieder berichten.
So viel für heute.
Grüsse aus Ahrensfelde (bei Berlin)
Peter Salomon
www.ps-blnkd.de (https://www.ps-blnkd.de)
Hallo Peter,
jetzt sind wir bald die Einzigen hier - aus Deutschland auf jeden Fall.
Schau Mal der letzte Post war davor am 7.8. und das ist bald ein Monat her.
Das hoffe ich nicht, daß wir die einzigsten sind, die noch wohlwollend PBWin gegenüberstehen.
Die Bezeichnung "PowerBASIC" will ich nicht mehr verwenden, weil die 10er Version kaum noch was mit BASIC zu tun hat.
Seit meiner intensiven Beschäftigung damit bin ich immer mehr zur Überzeugung gekommen, daß man mit dem gigantischen Funktionsumfang (siehe Anhang - wie lade ich hier eine pdf-Seite oder ein Bild davon hoch?) und des sehr gut strukturierten Referenz-HB, was außerdem noch sehr verständlich geschrieben ist und demnächst auch in einer deutschen Fassung vorliegen wird, die meißten (meiner) Programmieraufgaben hoffentlich damit einfach zu lösen sind.
Sicherlich gibt es immer noch Wünsche - so z.B. die Erweiterung auf die 64Bit-Technik, die ja bereits von Adam Drake von PowerBASIC Inc. begonnen wurde.
Nachdem nun schon seit mehrenen Monaten deren HP auf "under construction" steht und nun auch das bis vor kurzem noch aktive Forum abgeschaltet wurde, kann man wohl davon ausgehen, daß das Management offenbar keinerlei Interesse mehr daran hat die Produkte der PowerBASIC-Familie wieder in ihre Verantwortung zu nehmen.
Deshalb erhebt sich jetzt die Frage - was machen wir nun aus dieser Situation?
Wenn jemand von den "Alten Hasen" (Gery Beene, Jose Roca) noch persönliche Verbindung z.B. zu Adam Drake hat, könnte man den Vorschlag unterbreiten die PowerBASIC-Produkte in den Status des "Open Source" zu überführen, um damit weiterhin die Betreuung durch die User-Gemeinde zu sichern.
Diesen Vorschlag wollte ich im orig. PowerBASIC-Forum unterbreiten - meine Anmeldung wurde aber schon nicht mehr angenommen ... jetzt ist der Grund auch ersichtlich.
Es wäre sehr verwerflich - Andere mögen eine andere Meinung dazu haben - wenn dieses geniale SW-Werkzeug auf Nimmerwiedersehen in der Versenkung verschwinden würde.
Mit PureBASIC soll es zwar eine Alternative geben, aber wenn man aber dessen Funktionsumfang ansieht - obwohl es auch dort einen Inline-Assembler geben soll, fehlt die besonders interessante COM-Unterstützung.
Wir werden sehen, wie sich die Dinge weiter entwickeln ...
So viel für heute.
Grüsse aus Ahrensfelde (bei Berlin)
Peter Salomon
www.ps-blnkd.de (https://www.ps-blnkd.de)
Hallo Peter, ich bringe dich mal auf den neuesten Stand! 📢 Von Drake ist keine Rede mehr – denn die Drakes haben ihre Steuerberatungsfirma samt der zugehörigen Software verkauft. Die neue Firma in den USA hat keinerlei Bezug mehr zu Powerbasic; sie lässt lediglich das Forum weiterlaufen, übernimmt aber weder Administration noch Weiterentwicklung. Powerbasic kann nicht mehr gekauft werden und niemand, der damit zu tun hatte, besitzt den Quellcode. Erweiterungen sind somit nur noch in Eigenregie möglich – was ich persönlich sehr schade finde. 😕
Als Alternativen gibt es O2-Basic von Charles oder den Compiler von Jürgen Kühlwein, der Powerbasic sehr ähnlich ist und bereits kleinere Programme für 32- und 64-Bit kompiliert. Aufgrund eines Umzugs liegt dieses Projekt momentan jedoch auf Eis, und seit über einem Jahr gibt es keine Neuigkeiten. Jürgen hat jedoch signalisiert, dass er weiter daran arbeiten möchte. 💡
Zusammengefasst: Powerbasic wird wohl nicht mehr weiterentwickelt, und vermutlich gibt es niemanden mit Zugriff auf den Quellcode. Selbst erfahrenen Programmierern wäre es kaum möglich, den ursprünglich extrem komplexen und in Assembler geschriebenen Code zu pflegen. Falls du noch Fragen hast, poste sie gern hier! Beachte aber, dass Jose nur auf englischsprachige Beiträge antwortet. 💬
#Powerbasic #Softwareentwicklung #BasicCompiler #TechHistory #Alternativen #Programmieren #SoftwareNews #Coder #ITCommunity #Assembler #Forum #Quellcode 🖥�💻🛠�❗🔎🇩🇪✨🤓🙏💬
𝐻𝑒𝑙𝑙𝑜 𝑃𝑒𝑡𝑒𝑟, 𝑙𝑒𝑡 𝑚𝑒 𝑏𝑟𝑖𝑛𝑔 𝑦𝑜𝑢 𝑢𝑝 𝑡𝑜 𝑑𝑎𝑡𝑒! ?? 𝑇𝘩𝑒𝑟𝑒 𝑖𝑠 𝑛𝑜 𝑚𝑜𝑟𝑒 𝑡𝑎𝑙𝑘 𝑜𝑓 𝐷𝑟𝑎𝑘𝑒 - 𝑏𝑒𝑐𝑎𝑢𝑠𝑒 𝑡𝘩𝑒 𝐷𝑟𝑎𝑘𝑒𝑠 𝘩𝑎𝑣𝑒 𝑠𝑜𝑙𝑑 𝑡𝘩𝑒𝑖𝑟 𝑡𝑎𝑥 𝑐𝑜𝑛𝑠𝑢𝑙𝑡𝑎𝑛𝑐𝑦 𝑓𝑖𝑟𝑚 𝑎𝑛𝑑 𝑡𝘩𝑒 𝑎𝑠𝑠𝑜𝑐𝑖𝑎𝑡𝑒𝑑 𝑠𝑜𝑓𝑡𝑤𝑎𝑟𝑒. 𝑇𝘩𝑒 𝑛𝑒𝑤 𝑐𝑜𝑚𝑝𝑎𝑛𝑦 𝑖𝑛 𝑡𝘩𝑒 𝑈𝑆𝐴 𝑛𝑜 𝑙𝑜𝑛𝑔𝑒𝑟 𝘩𝑎𝑠 𝑎𝑛𝑦 𝑐𝑜𝑛𝑛𝑒𝑐𝑡𝑖𝑜𝑛 𝑤𝑖𝑡𝘩 𝑃𝑜𝑤𝑒𝑟𝑏𝑎𝑠𝑖𝑐; 𝑖𝑡 𝑚𝑒𝑟𝑒𝑙𝑦 𝑘𝑒𝑒𝑝𝑠 𝑡𝘩𝑒 𝑓𝑜𝑟𝑢𝑚 𝑟𝑢𝑛𝑛𝑖𝑛𝑔, 𝑏𝑢𝑡 𝑑𝑜𝑒𝑠 𝑛𝑜𝑡 𝑡𝑎𝑘𝑒 𝑜𝑣𝑒𝑟 𝑎𝑑𝑚𝑖𝑛𝑖𝑠𝑡𝑟𝑎𝑡𝑖𝑜𝑛 𝑜𝑟 𝑓𝑢𝑟𝑡𝘩𝑒𝑟 𝑑𝑒𝑣𝑒𝑙𝑜𝑝𝑚𝑒𝑛𝑡. 𝑃𝑜𝑤𝑒𝑟𝑏𝑎𝑠𝑖𝑐 𝑐𝑎𝑛 𝑛𝑜 𝑙𝑜𝑛𝑔𝑒𝑟 𝑏𝑒 𝑝𝑢𝑟𝑐𝘩𝑎𝑠𝑒𝑑 𝑎𝑛𝑑 𝑛𝑜 𝑜𝑛𝑒 𝑤𝘩𝑜 𝘩𝑎𝑑 𝑎𝑛𝑦𝑡𝘩𝑖𝑛𝑔 𝑡𝑜 𝑑𝑜 𝑤𝑖𝑡𝘩 𝑖𝑡 𝑜𝑤𝑛𝑠 𝑡𝘩𝑒 𝑠𝑜𝑢𝑟𝑐𝑒 𝑐𝑜𝑑𝑒. 𝐸𝑥𝑡𝑒𝑛𝑠𝑖𝑜𝑛𝑠 𝑎𝑟𝑒 𝑡𝘩𝑒𝑟𝑒𝑓𝑜𝑟𝑒 𝑜𝑛𝑙𝑦 𝑝𝑜𝑠𝑠𝑖𝑏𝑙𝑒 𝑜𝑛 𝑦𝑜𝑢𝑟 𝑜𝑤𝑛 - 𝑤𝘩𝑖𝑐𝘩 𝐼 𝑝𝑒𝑟𝑠𝑜𝑛𝑎𝑙𝑙𝑦 𝑡𝘩𝑖𝑛𝑘 𝑖𝑠 𝑎 𝑔𝑟𝑒𝑎𝑡 𝑝𝑖𝑡𝑦. ??
𝐴𝑙𝑡𝑒𝑟𝑛𝑎𝑡𝑖𝑣𝑒𝑠 𝑎𝑟𝑒 𝑂2-𝐵𝑎𝑠𝑖𝑐 𝑏𝑦 𝐶𝘩𝑎𝑟𝑙𝑒𝑠 𝑜𝑟 𝑡𝘩𝑒 𝑐𝑜𝑚𝑝𝑖𝑙𝑒𝑟 𝑏𝑦 𝐽ü𝑟𝑔𝑒𝑛 𝐾ü𝘩𝑙𝑤𝑒𝑖𝑛, 𝑤𝘩𝑖𝑐𝘩 𝑖𝑠 𝑣𝑒𝑟𝑦 𝑠𝑖𝑚𝑖𝑙𝑎𝑟 𝑡𝑜 𝑃𝑜𝑤𝑒𝑟𝑏𝑎𝑠𝑖𝑐 𝑎𝑛𝑑 𝑎𝑙𝑟𝑒𝑎𝑑𝑦 𝑐𝑜𝑚𝑝𝑖𝑙𝑒𝑠 𝑠𝑚𝑎𝑙𝑙𝑒𝑟 𝑝𝑟𝑜𝑔𝑟𝑎𝑚𝑠 𝑓𝑜𝑟 32- 𝑎𝑛𝑑 64-𝑏𝑖𝑡. 𝐻𝑜𝑤𝑒𝑣𝑒𝑟, 𝑡𝘩𝑖𝑠 𝑝𝑟𝑜𝑗𝑒𝑐𝑡 𝑖𝑠 𝑐𝑢𝑟𝑟𝑒𝑛𝑡𝑙𝑦 𝑜𝑛 𝘩𝑜𝑙𝑑 𝑑𝑢𝑒 𝑡𝑜 𝑎 𝑚𝑜𝑣𝑒, 𝑎𝑛𝑑 𝑡𝘩𝑒𝑟𝑒 𝘩𝑎𝑠 𝑏𝑒𝑒𝑛 𝑛𝑜 𝑛𝑒𝑤𝑠 𝑓𝑜𝑟 𝑜𝑣𝑒𝑟 𝑎 𝑦𝑒𝑎𝑟. 𝐻𝑜𝑤𝑒𝑣𝑒𝑟, 𝐽ü𝑟𝑔𝑒𝑛 𝘩𝑎𝑠 𝑠𝑖𝑔𝑛𝑎𝑙𝑒𝑑 𝑡𝘩𝑎𝑡 𝘩𝑒 𝑤𝑜𝑢𝑙𝑑 𝑙𝑖𝑘𝑒 𝑡𝑜 𝑐𝑜𝑛𝑡𝑖𝑛𝑢𝑒 𝑤𝑜𝑟𝑘𝑖𝑛𝑔 𝑜𝑛 𝑖𝑡. ??
𝑇𝑜 𝑠𝑢𝑚𝑚𝑎𝑟𝑖𝑧𝑒: 𝑃𝑜𝑤𝑒𝑟𝑏𝑎𝑠𝑖𝑐 𝑖𝑠 𝑝𝑟𝑜𝑏𝑎𝑏𝑙𝑦 𝑛𝑜 𝑙𝑜𝑛𝑔𝑒𝑟 𝑏𝑒𝑖𝑛𝑔 𝑑𝑒𝑣𝑒𝑙𝑜𝑝𝑒𝑑, 𝑎𝑛𝑑 𝑡𝘩𝑒𝑟𝑒 𝑖𝑠 𝑝𝑟𝑜𝑏𝑎𝑏𝑙𝑦 𝑛𝑜 𝑜𝑛𝑒 𝑤𝑖𝑡𝘩 𝑎𝑐𝑐𝑒𝑠𝑠 𝑡𝑜 𝑡𝘩𝑒 𝑠𝑜𝑢𝑟𝑐𝑒 𝑐𝑜𝑑𝑒. 𝐸𝑣𝑒𝑛 𝑒𝑥𝑝𝑒𝑟𝑖𝑒𝑛𝑐𝑒𝑑 𝑝𝑟𝑜𝑔𝑟𝑎𝑚𝑚𝑒𝑟𝑠 𝑤𝑜𝑢𝑙𝑑 𝘩𝑎𝑟𝑑𝑙𝑦 𝑏𝑒 𝑎𝑏𝑙𝑒 𝑡𝑜 𝑚𝑎𝑖𝑛𝑡𝑎𝑖𝑛 𝑡𝘩𝑒 𝑜𝑟𝑖𝑔𝑖𝑛𝑎𝑙𝑙𝑦 𝑒𝑥𝑡𝑟𝑒𝑚𝑒𝑙𝑦 𝑐𝑜𝑚𝑝𝑙𝑒𝑥 𝑐𝑜𝑑𝑒 𝑤𝑟𝑖𝑡𝑡𝑒𝑛 𝑖𝑛 𝑎𝑠𝑠𝑒𝑚𝑏𝑙𝑒𝑟. 𝐼𝑓 𝑦𝑜𝑢 𝘩𝑎𝑣𝑒 𝑎𝑛𝑦 𝑞𝑢𝑒𝑠𝑡𝑖𝑜𝑛𝑠, 𝑝𝑙𝑒𝑎𝑠𝑒 𝑝𝑜𝑠𝑡 𝑡𝘩𝑒𝑚 𝘩𝑒𝑟𝑒! 𝑁𝑜𝑡𝑒, 𝘩𝑜𝑤𝑒𝑣𝑒𝑟, 𝑡𝘩𝑎𝑡 𝐽𝑜𝑠𝑒 𝑜𝑛𝑙𝑦 𝑟𝑒𝑝𝑙𝑖𝑒𝑠 𝑡𝑜 𝐸𝑛𝑔𝑙𝑖𝑠𝘩 𝑙𝑎𝑛𝑔𝑢𝑎𝑔𝑒 𝑝𝑜𝑠𝑡𝑠. ??
#𝑃𝑜𝑤𝑒𝑟𝑏𝑎𝑠𝑖𝑐 #𝑆𝑜𝑓𝑡𝑤𝑎𝑟𝑒𝑑𝑒𝑣𝑒𝑙𝑜𝑝𝑚𝑒𝑛𝑡 #𝐵𝑎𝑠𝑖𝑐𝐶𝑜𝑚𝑝𝑖𝑙𝑒𝑟 #𝑇𝑒𝑐𝘩𝐻𝑖𝑠𝑡𝑜𝑟𝑦 #𝐴𝑙𝑡𝑒𝑟𝑛𝑎𝑡𝑖𝑣𝑒𝑠 #𝑃𝑟𝑜𝑔𝑟𝑎𝑚𝑚𝑖𝑛𝑔 #𝑆𝑜𝑓𝑡𝑤𝑎𝑟𝑒𝑁𝑒𝑤𝑠 #𝐶𝑜𝑑𝑒𝑟 #𝐼𝑇𝐶𝑜𝑚𝑚𝑢𝑛𝑖𝑡𝑦 #𝐴𝑠𝑠𝑒𝑚𝑏𝑙𝑒𝑟 #𝐹𝑜𝑟𝑢𝑚 #𝑆𝑜𝑢𝑟𝑐𝑒𝑐𝑜𝑑𝑒
Hallo Peter und Theo,
macht Euch keine Sorgen mehr wegen des Fortbestehens von PBWin. Gut, der Nachfolger wird anders heißen und im Inneren auch anders funktionieren, aber man kann mit dem Projekt von Jürgen Kühlwein die bekannte Syntax von PBWin weiter benutzen, compiliert zu 32 und 64 Bit Programmen, ähnlich kompakt wie das alte PB. Ich programmiere im SDK Stil. Zumindest da weiß ich, dass er wirklich auf der Zielgeraden ist. Ich habe einen eigenen, vielschichtigen Source erfolgreich compiliert. Wie weit er mit DDT ist, weiß ich nicht, wird aber bestimmt auch kommen. Es steckt seitens JK so viel Arbeit darin - es müssen tausende Stunden sein. Habt noch ein wenig Geduld und erspart Euch den Umstieg auf eine andere Alternative, wo Euch sicherlich mehr Aufwand bei der Transformation bestehender Programme entstehen wird.
Gruß
Norbert
QuoteHello Peter and Theo,
Don't worry about PBWIN's continued existence. Well, the successor will be called differently and work differently inside, but with Jürgen Kühlwein's project, you can continue to use the well -known syntax of PBWin, compiled 32 and 64 bit programs, as compact as the old PB. I program SDK style. At least then I know that he is really on the home stretch. I successfully compiled my own multi -layered source. I don't know how far it is with DDT, but will definitely come. There is so much work on the part of JK - it must be thousands of hours. Have a little patience and save you switching to another alternative, where you will certainly create more effort in the transformation of existing programs.
greeting
Norbert
and why waiting for alternative with different name
this must be fork of something ..my guess
so use what already exist ...and that is Oxygen basic
true .native 32/64 bit compiler
OR maybe is not good enough for you ?
hmmm
Hi Zlatko, deutsches Bord => deutsche Sprache!
yeah i learned deutsche sprache but i forget
𝐼𝑐𝘩 𝘩𝑜𝑓𝑓𝑒, 𝑑𝑢 𝑣𝑒𝑟𝑠𝑡𝑒𝘩𝑠𝑡 𝑑𝑎𝑠 𝑟𝑖𝑐𝘩𝑡𝑖𝑔, 𝑆𝑙𝑎𝑡𝑘𝑜. 𝑊𝑒𝑛𝑛 𝑖𝑐𝘩 𝑗𝑒𝑡𝑧𝑡 𝑒𝑖𝑛 𝑛𝑒𝑢𝑒𝑠 𝑃𝑟𝑜𝑔𝑟𝑎𝑚𝑚𝑖𝑒𝑟𝑝𝑟𝑜𝑗𝑒𝑘𝑡 𝑠𝑡𝑎𝑟𝑡𝑒𝑛 𝑤ü𝑟𝑑𝑒 𝑢𝑛𝑑 𝑤𝑖𝑟𝑘𝑙𝑖𝑐𝘩 𝑑𝑖𝑒 𝑏𝑒𝑠𝑡𝑒 𝑆𝑝𝑟𝑎𝑐𝘩𝑒 𝑤ä𝘩𝑙𝑒𝑛 𝑤𝑜𝑙𝑙𝑡𝑒, 𝑤ü𝑟𝑑𝑒 𝑖𝑐𝘩 𝑤𝑎𝘩𝑟𝑠𝑐𝘩𝑒𝑖𝑛𝑙𝑖𝑐𝘩 das (𝑃𝑟)𝑜2-𝐵𝑎𝑠𝑖𝑐 𝑣𝑜𝑛 𝐶𝘩𝑎𝑟𝑙𝑒𝑠 𝑛𝑒𝘩𝑚𝑒𝑛.
𝐸𝑠 𝑏𝑖𝑒𝑡𝑒𝑡 𝑡𝑜𝑙𝑙𝑒 𝐹𝑢𝑛𝑘𝑡𝑖𝑜𝑛𝑒𝑛 𝑢𝑛𝑑 𝑒𝑖𝑔𝑛𝑒𝑡 𝑠𝑖𝑐𝘩 𝑠𝑒𝘩𝑟 𝑔𝑢𝑡 𝑓ü𝑟 𝑑𝑖𝑒 𝐸𝑟𝑠𝑡𝑒𝑙𝑙𝑢𝑛𝑔 𝑣𝑜𝑛 𝐸𝑥𝑒-𝐷𝑎𝑡𝑒𝑖𝑒𝑛 – 𝑤𝑖𝑒 𝑒𝑠 𝑚𝑖𝑡 𝐷𝐿𝐿𝑠 𝑎𝑢𝑠𝑠𝑖𝑒𝘩𝑡, 𝑤𝑒𝑖ß 𝑖𝑐𝘩 𝑎𝑘𝑡𝑢𝑒𝑙𝑙 𝑛𝑖𝑐𝘩𝑡. 𝐴𝑢𝑐𝘩 𝑖𝑚 𝐵𝑒𝑟𝑒𝑖𝑐𝘩 𝑀𝑎𝑘𝑟𝑜𝑠 𝑖𝑠𝑡 es 𝑃𝑜𝑤𝑒𝑟𝐵𝑎𝑠𝑖𝑐 𝑘𝑙𝑎𝑟 ü𝑏𝑒𝑟𝑙𝑒𝑔𝑒𝑛.
𝐵𝑒𝑖 𝑠𝑒𝘩𝑟 𝑔𝑟𝑜ß𝑒𝑛 𝑏𝑒𝑠𝑡𝑒𝘩𝑒𝑛𝑑𝑒𝑛 𝑃𝑟𝑜𝑗𝑒𝑘𝑡𝑒𝑛 𝑚𝑖𝑡 𝑚𝑒𝘩𝑟𝑒𝑟𝑒𝑛 𝑀𝑒𝑔𝑎𝑏𝑦𝑡𝑒 𝑄𝑢𝑒𝑙𝑙𝑐𝑜𝑑𝑒 𝑘𝑎𝑛𝑛 𝑚𝑎𝑛 𝑗𝑒𝑑𝑜𝑐𝘩 𝑛𝑖𝑐𝘩𝑡 𝑒𝑖𝑛𝑓𝑎𝑐𝘩 𝑎𝑢𝑓 𝑒𝑖𝑛𝑒 𝑎𝑛𝑑𝑒𝑟𝑒 𝑃𝑟𝑜𝑔𝑟𝑎𝑚𝑚𝑖𝑒𝑟𝑠𝑝𝑟𝑎𝑐𝘩𝑒 𝑢𝑚𝑠𝑡𝑒𝑙𝑙𝑒𝑛.
𝐷𝑒𝑠𝘩𝑎𝑙𝑏 𝑏𝑙𝑒𝑖𝑏𝑒 𝑖𝑐𝘩 𝑏𝑒𝑖 𝑃𝑜𝑤𝑒𝑟𝐵𝑎𝑠𝑖𝑐, 𝑑𝑒𝑛𝑛 𝑑𝑒𝑟 𝐴𝑢𝑓𝑤𝑎𝑛𝑑, 𝑎𝑙𝑙𝑒𝑠 𝑎𝑢𝑓 𝑒𝑖𝑛𝑒 𝑎𝑛𝑑𝑒𝑟𝑒 𝑃𝑙𝑎𝑡𝑡𝑓𝑜𝑟𝑚 𝑤𝑖𝑒 (Pr)𝑂2-𝐵𝑎𝑠𝑖𝑐, 𝑃𝑎𝑠𝑐𝑎𝑙 𝑜𝑑𝑒𝑟 𝑒𝑖𝑛𝑒𝑛 𝑎𝑛𝑑𝑒𝑟𝑒𝑛 𝐶𝑜𝑚𝑝𝑖𝑙𝑒𝑟 𝑢𝑚𝑧𝑢𝑠𝑡𝑒𝑙𝑙𝑒𝑛, 𝑤ä𝑟𝑒 𝑒𝑖𝑛𝑓𝑎𝑐𝘩 𝑧𝑢 𝘩𝑜𝑐𝘩. 𝐸𝑠 𝑏𝑒𝑠𝑡𝑒𝘩𝑡 𝑎𝑘𝑡𝑢𝑒𝑙𝑙 𝑎𝑢𝑐𝘩 𝑘𝑒𝑖𝑛 𝑑𝑟𝑖𝑛𝑔𝑒𝑛𝑑𝑒𝑟 𝐺𝑟𝑢𝑛𝑑 𝑓ü𝑟 𝑒𝑖𝑛𝑒𝑛 𝑊𝑒𝑐𝘩𝑠𝑒𝑙.
𝑆𝑜𝑙𝑙𝑡𝑒 𝐽ü𝑟𝑔𝑒𝑛 𝑎𝑏𝑒𝑟 𝑒𝑡𝑤𝑎𝑠 𝘩𝑎𝑏𝑒𝑛, 𝑑𝑎𝑠 𝑘𝑜𝑚𝑝𝑙𝑒𝑥𝑒𝑛 𝑢𝑛𝑑 𝑔𝑟𝑜ß𝑒𝑛 𝑄𝑢𝑒𝑙𝑙𝑐𝑜𝑑𝑒 𝑒𝑏𝑒𝑛𝑓𝑎𝑙𝑙𝑠 𝑧𝑢𝑣𝑒𝑟𝑙ä𝑠𝑠𝑖𝑔 𝑘𝑜𝑚𝑝𝑖𝑙𝑖𝑒𝑟𝑒𝑛 𝑘𝑎𝑛𝑛, 𝑤𝑒𝑟𝑑𝑒 𝑖𝑐𝘩 𝑑𝑎𝑠 𝑎𝑢𝑓 𝑗𝑒𝑑𝑒𝑛 𝐹𝑎𝑙𝑙 𝑡𝑒𝑠𝑡𝑒𝑛. Ü𝑏𝑟𝑖𝑔𝑒𝑛𝑠: 𝑀𝑒𝑖𝑛 𝐶𝑜𝑑𝑒 𝑤𝑖𝑟𝑑 𝑚𝑖𝑡 𝑃𝑜𝑤𝑒𝑟𝐵𝑎𝑠𝑖𝑐 10 𝑣𝑜𝑛 𝑇𝑜𝑚 𝑖𝑛 ü𝑏𝑒𝑟 120 𝑆𝑒𝑘𝑢𝑛𝑑𝑒𝑛 𝑘𝑜𝑚𝑝𝑖𝑙𝑖𝑒𝑟𝑡 – 𝑑𝑎𝑠 𝑖𝑠𝑡 𝑠𝑐𝘩𝑜𝑛 𝑒𝑖𝑛𝑒 𝐿𝑒𝑖𝑠𝑡𝑢𝑛𝑔! 𝑀𝑎𝑙 𝑠𝑒𝘩𝑒𝑛, 𝑜𝑏 𝑎𝑛𝑑𝑒𝑟𝑒 𝑃𝑟𝑜𝑔𝑟𝑎𝑚𝑚𝑒 𝑑𝑎 𝑚𝑖𝑡𝘩𝑎𝑙𝑡𝑒𝑛 𝑘ö𝑛𝑛𝑒𝑛, 𝑑𝑒𝑛𝑛 𝑚𝑒𝑖𝑛 𝑃𝑟𝑜𝑗𝑒𝑘𝑡 𝑖𝑠𝑡 𝑤𝑖𝑟𝑘𝑙𝑖𝑐𝘩 𝑠𝑒𝘩𝑟 𝑘𝑜𝑚𝑝𝑙𝑒𝑥.
#𝑃𝑜𝑤𝑒𝑟𝐵𝑎𝑠𝑖𝑐 #𝑃𝑟𝑜2𝐵𝑎𝑠𝑖𝑐 #𝑃𝑟𝑜𝑔𝑟𝑎𝑚𝑚𝑖𝑒𝑟𝑢𝑛𝑔 #𝑆𝑜𝑓𝑡𝑤𝑎𝑟𝑒𝑒𝑛𝑡𝑤𝑖𝑐𝑘𝑙𝑢𝑛𝑔 #𝑄𝑢𝑒𝑙𝑙𝑐𝑜𝑑𝑒
Hallo Theo,
>>>
𝑆𝑜𝑙𝑙𝑡𝑒 𝐽ü𝑟𝑔𝑒𝑛 𝑎𝑏𝑒𝑟 𝑒𝑡𝑤𝑎𝑠 𝘩𝑎𝑏𝑒𝑛, 𝑑𝑎𝑠 𝑘𝑜𝑚𝑝𝑙𝑒𝑥𝑒𝑛 𝑢𝑛𝑑 𝑔𝑟𝑜ß𝑒𝑛 𝑄𝑢𝑒𝑙𝑙𝑐𝑜𝑑𝑒 𝑒𝑏𝑒𝑛𝑓𝑎𝑙𝑙𝑠 𝑧𝑢𝑣𝑒𝑟𝑙ä𝑠𝑠𝑖𝑔 𝑘𝑜𝑚𝑝𝑖𝑙𝑖𝑒𝑟𝑒𝑛 𝑘𝑎𝑛𝑛,...
<<<
Das wird auf jeden Fall funktionieren.
Bei der Compilierzeit wird keiner an PB herankommen. Ich liebe das blitzschnelle Compilieren von PowerBasic. Der Syntaxcheck (reine Stringarbeit) des Source ist sicherlich ein Zeiträuber. Vielleicht kann man Jürgen dazu überreden, den Syntaxcheck optional ausschalten zu können.
@Theo
Deutsches Board -> deutsche Sprache, ja und warum kann ich Post #10 mit "chinesischen Hiroglyphen" nicht lesen?
Sogar auf meinem Handy mit aktuellem BS nicht lesbar!
In Post #5 hattest Du ja noch freundlicherweise die "Übersetzung" beigefügt ...
Meine Frage in Post #4 "Wie lade ich hier was hoch"? wurde leider auch noch nicht beantwortet.
Oxygen habe ich mir schon angesehen, aber wenn man nicht mal eine (ausführliche) Doku findet, kann's mit der SW nicht weit her sein - von COM mal ganz zu schweigen.
Die wirklich sehr verständlich und sehr ausführlich geschriebene Doku zu den über 1200 Befehle umfassenden Sprachumfang von PowerBASIC in der genannten Beschreibung (>2000 S) und dem Referenz-Handbuch (>700 S) wird bis jetzt - soweit ich das sehe - von keiner anderen IDE erreicht.
Wir werden sehen, wie's weiter geht ...
So viel für heute.
Grüsse aus Ahrensfelde (bei Berlin)
Peter Salomon
www.ps-blnkd.de (https://www.ps-blnkd.de)
Hallo
@Peter Salomon 1. es scheint dass dein alte Technik mit unicode nicht klar kommt? Norbert kann es lesen.
2. Da steht "Click or drag files here to attach them."" - also bei mir steht das wenn ich einen Post schreibe.Das bedeutet du kannst da Zum Beispiel ZIP-Dateien an einen Post anfügen.
3. Ja, das Doku Problem. Ändert nichts an der sehr guten Qualität der Software. Angesichts dessen dass Charles noc hseine kranke Oma nebenher pflegt und das als Nebenbei Projekt macht ist das ganz toll was er da macht.
@Norbert Spoerl Ich hatte Jürgen schon vor längerer Zeit einen Vorschlag zur Performance-Optimierung gemacht. Allerdings ist es verständlich, dass man an seinem etablierten Programmierstil festhält, denn ein gewachsenes System nachträglich auf standardisierte Verfahren umzustellen, ist eine große Herausforderung.
Um die Grundlagen effizienter Syntaxanalyse (Parsing) zu verstehen, hilft oft ein Blick in die Originalliteratur, etwa von den C- oder Pascal-Autoren. Früher lag solchen Büchern oft ein großes Poster bei, das die gesamte Grammatik der Sprache visualisierte. Daran ließ sich exakt ablesen, welches Zeichen oder Keyword nach einer bestimmten Anweisung syntaktisch erlaubt ist.
Solche Grammatiken lassen sich mittels Assembler (ASM) extrem effizient parsen und erreichen dadurch eine enorme Geschwindigkeit. Dies ist eine klassische Programmiertechnik aus der Ära der 8-Bit-Systeme, wo Ressourcen knapp waren. Heutzutage wählt man oft den Umweg über zeitintensive String-Operationen, die für ein performantes Parsing jedoch unnötig sind. Im Grunde genügen eine zeichenweise Auswertung und die Suche nach dem nächsten Trennzeichen (Delimiter). Für komplexere Strukturen wie Formeln oder Schleifen kommen bewährte Konzepte wie Stacks zum Einsatz. Die ältesten und fundamentalsten Algorithmen sind hier oft die besten.
Sollte Jürgen jedoch tatsächlich ein neues, PowerBASIC-kompatibles System mit verbesserten Makros und neuen Datentypen schaffen – Bereiche, in denen er ohnehin stark ist, wie beim Debugging –, dann wäre die Performancefrage zunächst zweitrangig.
Früher oder später wird er jedoch an einen Punkt gelangen, an dem er auf diese bewährten, zeitlosen Techniken zurückgreifen muss. Man kann es anders implementieren, aber nicht, ohne erhebliche Geschwindigkeitseinbußen in Kauf zu nehmen. Das ist im Assembler vergleichbar: Eine Version könnte einen SELECT CASE-Block mit 500 Fällen nutzen, was ineffizient ist. Der performante Ansatz hingegen wertet Zeichen für Zeichen aus und hat nach jedem Schritt nur eine kleine, überschaubare Menge an gültigen Folgeoptionen.
Im C-Syntaxdiagram sieht es dann so aus ...
https://users.informatik.uni-halle.de/~brass/oop08/d4_synta.pdf (https://users.informatik.uni-halle.de/~brass/oop08/d4_synta.pdf)
Das lässt sich mit ASM-Macros oder Unterprogrammen nachbilden.
So gehts:
So ein Syntaxdiagram musst du machen dann wird daws genauso schnell.
Das hat seinen Ursprung in der Automatentheorie - das war damals als man die Dinger noch mit Lochkarten gefüttert hat. Da MUSSTE jedes Byte perfekt sitzen. Und das ist eben der Unterschied zu heute.
Alles Andere geht zwar benötigt aber "Memory Allocation" das ist da unnötiog und langsam-
Hi Theo,
>>>
Sollte Jürgen jedoch tatsächlich ein neues, PowerBASIC-kompatibles System mit verbesserten Makros und neuen Datentypen schaffen – Bereiche, in denen er ohnehin stark ist, wie beim Debugging –, dann wäre die Performancefrage zunächst zweitrangig.
<<<
Es geht erst einmal um die möglichst 1:1 Umsetzung des Sprachumfangs von PB. Verbesserte Datentypen, etc. könne nur in einem 2. Entwicklungsschritt erfolgen. Bzgl. Performancefrage gebe ich Dir Recht, wobei der compilierte Code sicherlich sehr schnell sein wird, da ja ein Assembler-Compiler verwendet wird. Bei meinem Gedanken mit der optionalen Abschaltung des Syntax-Checks dachte ich an Fälle wie z.B. Änderungen im eigenen Quellcode, die nur auf die Layout-Gestaltung abzielen. Wenn ich Objekte platziere und nach Zahlenänderungen der Pixelkoordinaten schnell das Ergebnis sehen will, muß ich nicht unbedingt einen Syntaxcheck durchlaufen.
Warum Compiler eine Syntaxprüfung brauchen
Liebe Norbert,
das Problem ist grundlegend: Ohne Syntaxprüfung würde der Compiler selbst instabil werden. Hier die Gründe:
1. Vermeidung von Systemabstürzen
Wenn du die Syntaxprüfung abschaltest, erzeugt der Compiler ungeprüften Code – ein "logisches Wirrwarr".
Beispiel: Fehlende Klammern oder falsche Befehlsstrukturen führen zu unvorhersehbarem Maschinencode.
Folge: Der Compiler verarbeitet inkonsistente Daten → Absturz des gesamten Systems (z. B. Segmentation Fault, Speicherlecks).
2. Undefinierte Zustände verhindern
Code ohne syntaktische Korrektheit bringt den Compiler in undefinierte Zustände.
Der Compiler weiß nicht, wie er den Code übersetzen soll → willkürliche Fehlverhalten (z. B. Endlosschleifen im Parser).
Ziel: Sicherstellen, dass der Compiler vorhersagbar und stabil läuft – nicht willkürlich.
3. Keine Alternative zur Korrektheit
Es gibt keinen "Workaround": Entweder Code ist syntaktisch korrekt → er funktioniert.
Oder er ist fehlerhaft → er muss abgelehnt werden.
Kompromisse (z. B. "fehlerhaft aber trotzdem kompilieren") gefährden die Integrität des Compilers.
4. Syntaxprüfung ≠ "Schikane" für Nutzer
Die Prüfung dient nicht primär, um Nutzer zu ärgern oder zu schützen.
Ihr Hauptzweck: Den Compiler vor sich selbst zu schützen.
Ein stabiler Compiler ist die Voraussetzung dafür, dass überhaupt zuverlässiger Code erzeugt werden kann.
Zusammenfassung in einem Satz
Syntaxprüfung ist der "Notaus-Schalter" des Compilers: Sie verhindert, dass fehlerhafter Code den Compiler selbst zum Absturz bringt – denn ein instabiler Compiler nutzt niemandem.
Beim SPR zum Beispiel ist die Syntaxprüfung nicht getrennt von der Speed-Code Generierung.
Im Idealfall ist es so, dass bei der Code-Generierung eben unerwartete Zeichen auftreten und dann wird eine FM generiert.
Es gibt eigentlich - im Idelafall - keine separate Syyntax-Prüfung, die man abschalten könnte um das schneller zu machen.
Hi Theo,
nur zur Info, ich programmiere seit 1985, im Laufe der Zeit mit unterschiedlichen Sprachen, und kenne auch alle Deine aufgeführten Punkte zum Syntaxcheck. Okay, das mit den Syntaxdiagrammen kannte ich so noch nicht. Im Falle von JKBasic wird erst die Syntax geprüft, das Compilieren erfolgt danach. Von daher kann man annehmen, dass der Check übersprungen werden könnte. Oder es geht aus irgendwelchen Gründen eben nicht.
Du hast doch von extrem großen Projekten und der Compilerzeit im Beitrag gesprochen.
>>>
𝑀𝑒𝑖𝑛 𝐶𝑜𝑑𝑒 𝑤𝑖𝑟𝑑 𝑚𝑖𝑡 𝑃𝑜𝑤𝑒𝑟𝐵𝑎𝑠𝑖𝑐 10 𝑣𝑜𝑛 𝑇𝑜𝑚 𝑖𝑛 ü𝑏𝑒𝑟 120 𝑆𝑒𝑘𝑢𝑛𝑑𝑒𝑛 𝑘𝑜𝑚𝑝𝑖𝑙𝑖𝑒𝑟𝑡 – 𝑑𝑎𝑠 𝑖𝑠𝑡 𝑠𝑐𝘩𝑜𝑛 𝑒𝑖𝑛𝑒 𝐿𝑒𝑖𝑠𝑡𝑢𝑛𝑔! 𝑀𝑎𝑙 𝑠𝑒𝘩𝑒𝑛, 𝑜𝑏 𝑎𝑛𝑑𝑒𝑟𝑒 𝑃𝑟𝑜𝑔𝑟𝑎𝑚𝑚𝑒 𝑑𝑎 𝑚𝑖𝑡𝘩𝑎𝑙𝑡𝑒𝑛 𝑘ö𝑛𝑛𝑒𝑛, 𝑑𝑒𝑛𝑛 𝑚𝑒𝑖𝑛 𝑃𝑟𝑜𝑗𝑒𝑘𝑡 𝑖𝑠𝑡 𝑤𝑖𝑟𝑘𝑙𝑖𝑐𝘩 𝑠𝑒𝘩𝑟 𝑘𝑜𝑚𝑝𝑙𝑒𝑥.
<<<
Da finde ich meine Überlegung nicht unlogisch. Und ich habe in meinem letzten Beitrag einen Fall genannt, wo ein Syntaxcheck nicht zwingend erforderlich ist. Eine solche Option setzt natürlich ein verantwortliches Handeln des Programmierers voraus.
Aber egal, wir müssen nicht länger darüber reden - ist eh nur theoretischer Natur.
Ansonsten freue ich mich jetzt schon auf die Reaktionen der PB-Gemeinde, wenn JKBasic allgemein zugänglich sein wird. Problematisch sehe ich die Deaktivierung des amerikanischen PB-Forums. Nur aus diesem Grund wird noch einmal eine nicht geringe Anzahl an PB-Usern eine Alternative suchen und PB den Rücken kehren. Ob sie dann nach Start JKBasic zurück kommen, ist fraglich. Das war auch die Intension für meinen 1. Beitrag in diesem Thread.
LG
Norbert
@Theo <#13>
Ja, so wird es sein, mein XP kann Unicode nicht lesen. Auf'm Handy gehts auch nicht, weil das Teil zu alt ist und es keine Updates dafür mehr gibt ... nur auf dem Linux-PC geht es, aber den nehme ich nur selten, weil der Startvorgang immer eine Ewigkeit dauert.
Bei mir gibt es nur ein "Insert Image", wo auch eine URL angegeben werden muß, wo das Bild liegt. Also kann ich auch gleich ein Link auf meine HP einfügen ...
Sei's drum - irgendwie weiß man sich immer zu helfen.
@Norbert <#16>
1985 bin ich zwar noch nicht beim Programmieren gewesen, aber schwerpunktmäßig in der HW-Entwicklung. Kannst Du alles nachlesen auf meiner HP -> www.ps-blnkd.de.
Meine Programmierversuche sind in -> http://www.ps-blnkd.de/AutoIt.htm ausführlich dokumentiert. Noch nicht enthalten ist der Weg zu PowerBASIC.
Daß diese - aus meiner Sicht - geniale IDE nun plötzlich nicht mehr seitens des Herstellers unterstützt wird, ist zwar sehr ärgerlich, ändert aber nichts an der Tatsache des Bestehens der SW.
Je länger ich mich damit beschäftige, umso mehr bin ich der Überzeugung: das isses!
Sicherlich gibt es, oder soll es demnächst, bald oder wann auch immer irgendwelche Alternativen dazu geben. Aber bei über 30 Jahren Entwicklung, dabei gesammelten Erfahrungen, die immer wieder in neuen Versionen Eingang fanden, so daß in der 10er Version nun über 1200 Befehle auf über 2000 Seiten Doku ausführlichst beschrieben (die Referenzdatei hat "nur" ~700 Seiten) zur Verfügung stehen. Dabei ist die Compiler-Größe mit 1,5 + 0,8MB extrem klein und läuft auf jedem Windows-PC - naja, vielleicht nicht mehr auf den ganz alten (Win3.1) und möglicherweise auf den "neuzeitlichen" 10er und 11ern vielleicht auch nicht, weil deren überzogene "Sicherheitsbarieren" das verhindern.
Das soll erstmal jemand nachmachen!
Zum Überblick über die Leistungsfähigkeit von PBWin10 hier mal ein Auszug aus der (in Arbeit befindlichen) deutschen Version der diesbezüglichen Referenzdatei -> http://www.ps-blnkd.de/PowerBasic_Compiler10__Referenz(Befehls-Uebersicht).pdf .
Die roten xxx-Seitenangaben sind die, die noch nicht bearbeitet sind.
Gedacht ist das für diejenigen, die vielleicht schon mal was von PowerBASIC gehört haben, aber "mainstream"-mäßig ablehnend dem gegenüberstehen.
@Theo
Du hattest mal was von PBWin11 geschrieben - hast Du diese wirklich letzte Version? - Welche Unterschiede/Ergänzungen gibt es dort?
Hattest Du damals noch Kontakt zu Kirschbaum-Software - was gehörte alles zu deren Lieferumfang?
So viel für heute ...
Grüsse aus Ahrensfelde
Peter Salomon
www.ps-blnkd.de
Leider wird der Link zu der PDF-Datei "Auszug aus der PBWin10-Referenz" nicht abgebildet - warum?
Meine anderen Links gehen doch auch!
Grüsse aus Ahrensfelde
Peter Salomon
www.ps-blnkd.de (https://www.ps-blnkd.de)
Hi Peter,
vorab, mit PROFAN habe ich vor vielen Jahren auch gearbeitet.
Noch einmal zur INFO. Der Befehls- und Funktionsumfang von PBWin 10 wird durch JKBasic fast zu 100 % umgesetzt werden, nur bei den DDT bezogenen Funktionen bin ich mir nicht sicher, bzw. wird wohl noch etwas dauern. D.h., Du kannst die Handbücher von PB für JKBasic weiter benutzen. Vermutlich wird es später Ergänzungen zum Sprachumfang von PB PBWin 10 geben. Damit wird PB in gewisser Wiese weiterleben und sich weiter entwickeln. Die letzten Versionen von PB erzeugen 32 bit Code. JKBasic kann wahlweise 32 oder 64 bit Code erzeugen. Das mit den 32 bit wird in einigen Jahren aussterben, so wie es zuvor den 16 bit Abwendungen erging. Mit einem XP-PC kommst Du allerdings nicht weit. JKBasic wird vermutlich nicht darauf laufen.
Gruß
Norbert
@Norbert <#19>
Es freut mich außerordentlich, daß sich noch ein "Sachverständiger" zu PowerBASIC hier zu Wort meldet.
Leider habe ich zu JKBasic noch nichts gefunden - wo sind die Download-Quellen und die Doku, damit ich mir selbst mal ein Bild machen kann? - 64Bit-Code wäre natürlich schon vorteilhaft - wenn's denn unbedingt z.B. aus Performance-Gründen sein muss ...
Bzgl. des Problems mit dem PDF-Link hier im Forum habe ich mir was einfallen lassen - auf -> http://www.ps-blnkd.de/AutoIt.htm (http://www.ps-blnkd.de/AutoIt.htm) gib's jetzt ein Update, d.h. eine Ergänzung zu PowerBASIC. Dort sind die Links problemlos aufrufbar!
Grüsse aus Ahrensfelde
Peter Salomon
www.ps-blnkd.de (https://www.ps-blnkd.de)
@Peter Salomon Powerbasic 11 gab es nur für die Beta-Tester, da war ich dabei.
Die wesentliche Änderung ist dass es mein Program kompilieren kann,
PB 10 stürzt dabei ab und findet die kompilierte Datei nicht.
Und es kompiliert etwas schneller.
Die spezifischen neuen Features wie die Auto-Dim Arrays sind gefährlich da sie zu Abstürzen am Programende führen - das war nie richtig fertigentwickelt.
Trotzdem nehme ich eben nur Version 11 .... allerdings geht da der Debugger nicht also Single-Step.
Geht bei meinem Program aber sowieso nicht da zu viele Assembler-Teile.
@Norbert Spoerl Das mit den Syntaxdiagrammen ist sehr wichtig, dadurch hat es eine enorme Kompilierschnelligkeit.
50.000 Zeilen/Minute auf einem 12 MHz CPU ist schon eine Wort. Ein gut gemachter Compiler - der genau so arbeitet, wäre im Nu fertig.
Ich denke dass es sich lohnt mehr nach (Free-)Pascal/Modula zu schauen, da wird immer mehr die Musik spielen, weil das moderne Zeugs ist alles nicht richtig zuverlässig.
Das ist es eben nur wenn man exakt arbeitet. Das hat man früher gelernt mit den 8 Bit COmputer.
Und da gibt es nur eine Möglichkeit. Bei Compilern sind das Syntaxdiagramme.
Das wird auch keine KI so schnell ändern.
Eine konkrete Tabelle mit Kompiliierungszeilen pro Minute belegt meine Aussage:
## Kompiliergeschwindigkeit historischer Pascal-Compiler (ca. 1990)
| Compiler | Geschwindigkeit (Lines/Min) | Hardware | Bemerkungen |
|----------|----------------------------------|----------|-------------|
| **JPI TopSpeed Pascal** | **30.000-50.000** | 80286 @ 12MHz | Rekordhalter, extrem schnell |
| **Turbo Pascal 5.5** | 15.000-25.000 | 80286 @ 12MHz | Sehr schnell, Ein-Pass-Compiler |
| **Borland Pascal 7.0** | 10.000-20.000 | 80386 @ 33MHz | Etwas langsamer durch mehr Features |
| **Microsoft Pascal** | 5.000-10.000 | 80286 @ 12MHz | Langsamer, aber stabil |
| **IBM Pascal/2** | 3.000-8.000 | 80286 @ 12MHz | Sehr gründlich, aber langsam |
## Moderne Compiler im Vergleich (geschätzt)
| Compiler | Geschwindigkeit (Lines/Min) | Hardware | Bemerkungen |
|----------|------------------------------|----------|-------------|
| **Free Pascal 3.2+** | 100.000-300.000+ | i7 @ 3.0GHz | Sehr schnell, mehrstufig |
| **Delphi (modern)** | 80.000-200.000+ | i7 @ 3.0GHz | Schnell, mit umfangreicher Code-Analyse |
## Wichtige Anmerkungen:
- **TopSpeed Pascal** war legendär für seine Geschwindigkeit - es gab Berichte von 40.000+ Zeilen/Minute auf einer 286-Maschine
- **Turbo Pascal** war berühmt für sein "Compile-Go" Prinzip - oft in unter 1 Sekunde für kleine Programme
- Die Zahlen sind **relativ** zu verstehen - moderne Hardware macht direkte Vergleiche unmöglich
- Komplexität des Codes beeinflusst die Geschwindigkeit erheblich
Der Geschwindigkeitsvorteil von TopSpeed war so signifikant, dass Entwickler, die große Projekte (50.000+ Zeilen) bearbeiteten, oft speziell auf TopSpeed wechselten, um Wartezeiten von mehreren Minuten (bei anderen Compilern) auf wenige Sekunden zu reduzieren.
Hi Peter,
Deine Seite mit den Links konnte ich bereits in dem Post 17 aufrufen.
JKBasic, wobei der Name noch nicht 100%ig feststeht (Arbeitstitel = JKB), ist in einer finalen Entwicklungsstufe und im Beta-Test-Stadium. Informationen dazu sind noch recht rar. Auf der Seite http://pump.richheimer.de/index.php gibt es Informationen dazu, allerdings nur lesbar für Beta-Tester. Das JK steht für Jürgen Kühlwein. JK hatte einige Posts zu dem Thema im alten (ehemals offiziellen) PB-Forum gesetzt. Hier der Link.
https://forum.powerbasic.com/forum/user-to-user-discussions/third-party-addons/838286-jk-ide-version-2-5-and-a-new-basic-compiler-for-32-and-64-bit-is-under-construction
Wenn Du geblockt wirst, hier ist eine Anleitung, wie man die Seite noch einsehen kann.
http://pump.richheimer.de/showthread.php?tid=71&pid=457#pid457
Und hier noch ein Post, den Du direkt sehen müsstest.
http://pump.richheimer.de/showthread.php?tid=70
Gruß
Norbert
Hallo
@Norbert Spoerl wenn du in das Richheimer Forum rein kannst frag den RIchheimer mal warum ich nicht reingelassen werde.
Hi Theo,
unter "How to register with PUMP / become a PUMP member" steht Folgendes:
>>>
You are welcome to join PUMP (PowerBasic Users Meeting Point) by registering. PUMP is reserved for active (=contributing) users already registered at PowerBASIC. You are required to use your real name, in the exact spelling you are registered with PowerBASIC.com. After you have submitted the registering form I will check the name with the PowerBASIC forum and activate your account, if the above requirements are met. Otherwise the application for membership will be deleted without notification.
Please note that there is no formal right for getting access to PUMP.
<<<
Der Grund ist also, weil Du zuvor aus dem PB-Forum rausgeflogen bist. Das PUMP-Forum war praktisch nur für den Notfall, wenn das PB-Forum temporär oder so wie jetzt endgültig nicht zur Verfügung steht. Albert und mehrere registrierte Nutzer sind dabei, als Fortsetzung des PB-Forums, ein neues PB-Forum einrichten, vermutlich unter dem Namen PBUsers.org. Wenn es soweit ist, kannst Du Dich bestimmt anmelden.
VG
Norbert
@Norbert Spoerl Eigentlich ist mir der Pump auuch egal aber ich habe gesehen dass der Stan Durham da aktiv ist, kannst du dem Mal eine Nachricht senden er soll sich hier anmelden oder mir eine Mail senden?
Das wäre nett, da ich nicht rein komme sehe ich dem seine Mailadresse nicht.
Ich will paar Sachen wegen seinen Datentypen mit Ihm diskutieren.
@Theo #021
Danke für Deine Infos zu PBWin11.
Demnach sind es nur Überarbeitungen hinsichtlich der Stabilität und kaum neue Funktionen.
#022
Danke auch für die vergleichenden Untersuchungen bzgl. verschiedener Pascal-Varianten. Gib's sowas auch für BASIC, oder PowerBASIC im Vergleich zu anderen BASIC-Varianten?
Ich wollte auch mal vergleichsweise untersuchen (ggf. lassen), wie verschiedene BASIC-Varianten und andere Programmiesprachen den Code wie effektiv in Maschinensprache umsetzen ...
@Norbert #023
Die Richheimer-HP kenne ich auch - d.h. eigentlich nicht wirklich, da man dort ohne Anmeldung nichts sehen kann. Auch der von Dir zu letzt gepostet Link geht ohne Anmeldung nicht.
Hat jemand zu meinen Übersetzungen Einwände?
Link in http://www.ps-blnkd.de/AutoIt.htm#PowerBASIC
Grüsse aus Ahrensfelde
Peter Salomon
www.ps-blnkd.de (https://www.ps-blnkd.de)
Hi Theo, habe vor 2 Tagen eine "private Nachricht" wegen Deinem Anliegen an Stan geschickt - bisher ohne Antwort.
Hi Peter,
hier ein Beitrag von JK vom Jan. 20205.
>>>
Hi all, as already announced here there will be a new compiler meant as a (currently limited) alternative and maybe future replacement for PowerBASIC.
My current situation still limits the time i can invest, so for a start i must limit the number of testers. I thought of asking the members of the former beta team first. I you are not a member of the beta team, but feel you must be among the first testers drop me a PM. There is no public download yet, don´t worry, everyone interested will get a chance for testing later. Please don´t ask all kinds of questions! I will tell more as things go on and time will come for all kinds of questions - but this time is not now.
Don´t expect too much, this is WIP and an alpha version. It is not a full blown compiler and linker all in one, it is a tool chain consisting of a code generator (my work), an assembler (minor changes by me) and a linker (e.g. link.exe by MS). The first step is generating assembler code from BASIC source code, this code gets assembled to one or more object files (.obj), which in a last step are linked to a final executable. This can be an .exe, a .dll or a .lib (static library) file conforming to Windows standards.
The assembler can assemble to 32 and 64 bit Windows and Linux executables. Currently i support only Windows executables.
MS´s link.exe + adjacent files are not redistributable, that is, i am not allowed to include it in my package. But on the other hand it is free and available by a free VC download. You can find the files you need (64 bit VC 22 version, Windows 10) in: C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.37.32822\bin\... ,copy cvtres.exe, link.exe, lib.exe and all ms*.dll to \Assembler\Link32 and you are ready to go.
At current stage you will need my IDE for testing. Maybe there will be a standalone version in the future, but for the time being my IDE is the easiest way of handling all the messy details for me, so this is a requirement.
I´m not very happy with the name "JK-Basic", i´m not very creative finding names, so if you think you know a better name (not conflicting with existing ones), please tell me.
My first goal is to make core features and statements solid and stable. Future extensions are possible, but for the moment i don´t need suggestions, what else should be included and why, except i forgot to implement "really important" statements. I want a solid basis of what i have and afterwards we can talk about extensions and further development.
<<<
Und hier ein Beitrag vom 07.09.2025.
>>>
Maybe you remember the discussion about the name of my PowerBASIC replacement project, as a working name i choose "JKB", which is not an already registered trademark, so i think it is safe (legally) to use it.
After my retirement i had to move. I will become 65 in November this year and are in good shape and health. My mother is 89 now and never has seen a hospital from inside, so inheriting their gens i can hope for some years to come. One of my plans for these years is going public with and maintaining my 32/64 bit language, which syntactically is almost to 100% compatible to PowerBASIC, but a complete re-write and in some respect an expansion of it.
I hoped to be ready for this in summer this year, but moving to another place happens not as fast as i planned and expected. It is a small, lovely town, nearby where i was born. An old, charming, beautiful house, nearly 100 years old - i love it.The downside with old houses is, nothing is straight, even, plain or has 90 degree angles, Arranging your furniture is a real challenge, if the floor (a wonderful wooden floor) rises about 2 cm (nearly an inch!) towards the wall in the living room. By now i manged to install my kitchen and finally my desk with my computer setup, so i´m in play again - but by far not as far as i hoped to be.
In the meantime i could fix some problems including a bug (memory corruption) that almost drove me crazy. After long discussions with one of my test mates, finally the right idea came to my mind how to trap it. I have some of my projects compiling and running including object and COM stuff. I´m near but not yet there ...
So all i can ask for is your patience, i´m determined (and all of my tests so far show, i can do it) to publish a real 32/64 bit alternative for PowerBASIC, which (alas) seems to be come to an end. BASIC was the first computer language i learned, later i learned assembler and C/C++. After al those years to be honest, i still prefer BASIC, because human readability was not one of the first goals, when C was developed - it should be machine readable (easy to parse with the computer capacities back then). Well written BASIC code is much more readable and maintainable and as PowerBASIC shows, can easily stand the comparison to other modern languages.
BASIC is said to be "old-school" and for "beginners", because of the "B" in front of it. Maybe we should interpret the leading "B" as "Best ..."
Please stay tuned, there is more to come (definitely)
<<<
Quote from: Norbert Spoerl on September 30, 2025, 07:38:54 PMHi Theo, habe vor 2 Tagen eine "private Nachricht" wegen Deinem Anliegen an Stan geschickt - bisher ohne Antwort.
Danke, Norbert.
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.
@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
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
@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 (https://www.ps-blnkd.de)
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.
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ß
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 (https://superhivemarket.com/products/blender-quickbuttons-buttonbar)
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...
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.
@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 (https://www.ps-blnkd.de)