Diskussion:QuickC

QuickC vs. TurboC

 Info: Übertrag von meiner eigenen Diskussionsseite. --Siegbert v2 (Diskussion) 16:31, 9. Jul. 2024 (CEST)

[…] Hier gibt es einen alten Artikel "QUICK C VERSUS TURBO C" aus dem Dr. Dobb's Journal aus dem Jahr 1989. https://jacobfilipp.com/DrDobbs/articles/DDJ/1989/8905/8905g/8905g.htm Das ist eventuell für die beiden Wikipedia Artikel nützlich. --93.229.166.99 18:18, 1. Jul. 2024 (CEST)

Und das hier, auch Dobb's Journal: https://jacobfilipp.com/DrDobbs/articles/DDJ/1989/8908/8908j/8908j.htm --93.229.166.99 18:20, 1. Jul. 2024 (CEST)

Danke Dir für die Info! Ich schau mir das mal an. Zeitlich bin ich gerade etwas eingebunden, aber das bekommen wir hin. --Siegbert v2 (Diskussion) 00:03, 4. Jul. 2024 (CEST)

Den Artikel hab ich jetzt bis zu einem gewissen Stand veröffentlicht (QuickC bzw. QuickC for Windows), damit wenigsten etwas da ist. Der Dobb's Artikel ist aber noch nicht eingeflossen. […] --Siegbert v2 (Diskussion) 16:27, 9. Jul. 2024 (CEST)

QuickC und Microsoft C enthalten Code um zu Prüfen, ob DR-DOS 3.40 läuft

Siehe hier, im Buch Undocumented DOS, Second Edition auf Seite 199 bis 204.

https://archive.org/details/undocdos2ed/page/198/mode/2up?view=theater

Das sollte im Artikel noch berücksichtigt werden. Hier wird es auch noch erwähnt: https://www.geoffchappell.com/notes/dos/interrupts/21h/30h/oemtable.htm?ta=9 --84.158.120.82 23:41, 19. Jul. 2024 (CEST)

…und?! In den Systemvoraussetzungen der Produkte wird DR-DOS weder direkt (also wörtlich „[…] oder DR-DOS“) noch indirekt (z. B. „[…] oder PC-kompatibles DOS“) genannt. Es ist lediglich die Rede von MS-DOS und PC-DOS. Siehe:

• Verpackung von QuickC 2.51
• Verpackung von QuickC for Windows 1.00

Es ist völlig legitim, wenn Microsoft feststellt, ob die Software unter einem unterstützen Betriebssystem läuft oder nicht. Nur dafür muss Microsoft bei Fehlern aktiv werden. Soll sich Microsoft einen Wolf suchen, wenn ein Fehler durch eine fremde Software verursacht wird?! Soll Microsoft für Produktionsausfälle haften, wenn sich ein Programmierer nicht an die Systemanforderungen hält?!

Die Software lässt sich ja trotzdem installieren und nutzen. Beim Setup und vor dem Start der IDE wird lediglich folgender Text angezeigt:

WARNING: This Microsoft product has been tested and certified for use only with the MS-DOS and PC-DOS operating systems. Your use of this product with another operating system may void valuable warranty protection provided by Microsoft on this product.

Den Text muss man mit einer beliebigen Taste quittieren und danach läuft das Programm problemlos. Bei QC verschwindet der Text sogar nach 3 Sekunden automatisch. Also nichts anderes als ein Splash Screen. Ich kann da nichts Verwerfliches erkennen. Der Hinweis ist ein sehr mildes Mittel, um den Kunden auf Gewährleistungsbedingungen hinzuweisen.

Wenn ich mir die Seite und das Buch von Herrn Chappel durchlese, hab ich gewisse Zweifel bezüglich der Objektivität in dieser Causa. Die vorgegebenen Systemanforderungen werden von ihm mit keinem Wort erwähnt. Microsoft ist einfach per se böse. Bis zu seinem DosBox-X Release 2023.05.01 erschien auch dort der Hinweistext für diese Produkte; es zielt nicht nur auf DR-DOS ab, sondern generell auf alle anderen Betriebssysteme als MS-DOS und PC-DOS.

Beim ursprünglichen Bezugsobjekt - der Beta von Windows 3.1 - kenne ich die Ausgangssituation nicht. Möglicherweise waren die Systemanforderungen nicht restriktiv genug formuliert oder sie fehlten komplett. Bei QuickC und MSC ist die Sachlage allerdings eindeutig (siehe die Verpackungen).

Wie sieht es denn mit moderner Software aus? In der Regel erscheint schon beim Setup eine Messagebox, wenn das OS veraltet ist oder nicht unterstützt wird (Stichwort: Wine / ReactOS für Win32-Software). Dann lässt sich die Software gar nicht erst installieren. Da war die alte Praxis von MS deutlich sanfter. --Siegbert v2 (Diskussion) 04:09, 21. Jul. 2024 (CEST)

Nein, das tut es nicht. In DR-DOS 3.41 und früher geben in der IDE compilierte Programme den Speicher nicht mehr frei. Je nachdem, wie groß das eigene Programm ist, muss man spätestens nach dem 3 Durchlauf den Rechner neu booten. --84.158.120.82 12:24, 21. Jul. 2024 (CEST)

…selbst wenn das das so ist, wäre das immernoch vollkommen ok. Die Systemvoraussetzungen schreiben MS-DOS oder PC-DOS vor. Das sieht der Kunde vor dem Kauf. Wenn sich der Kunde nicht daran hält, ist und bleibt es die alleinige Schuld des Kunden. --Siegbert v2 (Diskussion) 14:56, 21. Jul. 2024 (CEST)

Es ist durch die Gerichtsverhandlungen bewiesen, dass Microsoft vorsätzlich Code in ihre Produkte eingebaut hat, damit diese Produkte nicht oder nicht richtig auf fremden DOS Varianten funktionieren. Siehe dazu bspw. der AARD code bei Windows 3.1 Beta Version, der übrigens auch bei OS/2 Probleme macht. Die Kunden sind Opfer dieser Machenschaften, denn es gab MS-DOS damals nicht einmal als Retailversion zu kaufen. MS-DOS gab es viele Jahre nur zusammen mit einem Komplett PC und die Computerhändler, wie bspw. Vobis verkauften viele Jahre diese Komplett PCs mit DR-DOS an völlige Computerlaien, die noch nie zuvor einen Computer hatten. Was damals auch der Normalfall war. Von einer Schuld des Kunden kann man hier somit überhaupt nicht sprechen. Die meisten dürften nicht einmal gewusst haben, dass es da überhaupt einen Unterschied gibt, es galt, bezogen auf den PC, DOS ist DOS. --84.158.120.82 17:08, 21. Jul. 2024 (CEST)

"Keine Version unterstützt objektorientierte Programmierung."

Ich finde, diesen Satz kann man entfernen, denn man muss ihn im zeitlichen Kontext beachten und er muss/sollte raus, weil er falsch ist.

Erläuterung:

Frage: Was war damit ursprünglich gemeint?

Antwort: C mit Klassen. Es ging damals also eigentlich um die Frage, ob QuickC C++ unterstützt. Was es nicht tut, denn QuickC kann nur C. Aber am Anfang wurde C++ noch nicht C++ genannt bzw. herrschte da bei vielen noch Unklarheit, insbesondere in der Presse. In den Anfängen von C++ sprach man hinsichtlich von C++ nicht von einer eigenen Sprache, sondern von C mit Klassen, also C mit Sprachelementen für Klassen, was C++ ja wurde. Und man hatte es auch nicht besser gewusst. Das erklärt den Satz "Keine Version unterstützt objektorientierte Programmierung.". Meinen würde man heute damit eher "Keine Version unterstützt C++".

Frage: Aber warum muss er raus?

Antwort: Weil man natürlich auch in C objektorientiert programmieren kann, nur fehlen halt die Schlüsselwörter, so dass man von C dafür nicht unterstützt wird, aber es ist möglich. Dazu wurden ganze Bücher geschrieben. Beispiele in denen mit C objektorientiert programmiert wird:

• https://www.ionos.com/digitalguide/websites/web-development/oop-in-c/
• https://lwn.net/Articles/444910/
• https://en.wikipedia.org/wiki/GObject

Also, die Aussage ist falsch. Entweder passt man den Satz an die heutige Formulierung an und schreibt "Keine Version unterstützt C++." oder man entfernt ihn, weil man in C natürlich sehr wohl objektorientiert programmieren kann und somit auch in QuickC, was ja nichts anderes als eine IDE und ein Compiler für C ist. --84.158.120.82 16:22, 2. Aug. 2024 (CEST)

Nein, dem stimme ich nicht zu. Die dort beschriebenen Tricks sind kein Ersatz zum Paradigma OOP. Die im Ionos-Artikel beschriebenen Äquivalente sind keine. Es sind Alternativen aber keine gleichwertigen Sprachkonstrukte. Das ganze Thema Vererbung (engl. Inheritance) wird auch völlig ausgeblendet. Generell: im Extremfall kann man alle Sprachkonstrukte von Hochsprachen herunterbrechen auf den Befehlssatz eines Prozessors. Beispielsweise werden Schleifen immer heruntergebrochen auf (bedingte) Sprunganweisungen. Deshalb sind diese aber nicht überflüssig und ein GOTO ist kein äquivalenter Ersatz zur "Errungenschaft" Schleife. Eine losgelöste Funktion, die als erstes Argument einen Zeiger auf eine Struktur erwartet ist kein äquivalenter Ersatz für eine Methode (≠ Funktion).

Es geht um das Paradigma OOP; nicht um die Möglichkeit, Daten (irgendwie) strukturiert abzubilden. Die Aussage ist aber auch nicht trivial und überflüssig, da QC for Windows resp. das CASE-Tool QuickCase:W Steuerelemente so repräsentieren, als wären es Objekte (mit Eigenschaften, Ereignissen etc.), was aber nicht der Fall ist. Die Wortwahl und der Verzicht es als "C mit Klassen" zu betrachten, waren bei der Formulierung eine bewusste Entscheidung, an der ich festhalte. --Siegbert v2 (Diskussion) 15:02, 3. Aug. 2024 (CEST)

Aber was erwartest du von einer IDE bzw. genauer einem Compiler, der nur die Programmiersprache C umsetzt? Ich finde, das muss man im Hinblick auf die damalige Zeit ca. 1990 betrachten, als C++ eben noch nicht wirklich als eigene Sprache bekannt war bzw. die Autoren noch nicht wirklich wussten, ob sie nun weiter wie bisher, einfach C oder C mit Klassen oder C++ schreiben sollten. Microsoft lieferte erst mit Microsoft C/C++ 7.0 1992 ihren ersten C++ Compiler aus und lediglich Borland war mit Turbo C++ 1.0 im Mai 1990 etwas früher dran, was den damaligen Vergleich aus deinem Beleg, dass QuickC keine OOP unterstützten würde, erklären würde. Und die Tatsache, dass jeder damalige C++ Compiler auch direkt C Code compilieren konnte, macht diese Unterscheidung nicht einfacher. Ich finde man sollte schon erwähnen, dass man hier eigentlich C++ gemeint hat, dann könnte man den Satz mit dieser Erwähnung so lassen. --84.158.120.82 17:52, 3. Aug. 2024 (CEST)

Und noch eine Ergänzung. Genau genommen gehört der Satz in einen Abschnitt Namens Rezeption. --84.158.120.82 18:10, 3. Aug. 2024 (CEST)

QuickC für Windows und DOS TUI?

Im Artikel heißt es:

Es können aber auch DOS-Programme im Real Mode erzeugt werden.

Hier stellt sich die Frage, war die alte TUI für DOS aus den Vorgängerversionen noch zusätzlich dabei oder musste der Quellcode für ein DOS Programm innerhalb der Windows GUI geschrieben werden? Bezieht sich dieser Satz also nur darauf, dass der Compiler für DOS entsprechende EXE Dateien erzeugen konnte oder ob auch die Entwicklung noch weiterhin innerhalb der alten DOS TUI von den Vorgängerversionen stattfinden konnte, wenn man wollte? Falls letzteres zutrifft, dann sollte das unbedingt im Artikel erwähnt werden. --84.158.120.82 16:43, 2. Aug. 2024 (CEST)

Nein, die alte TUI für DOS ist leider nicht mehr dabei, aber der Compiler ist in der Lage, ausführbare Binärdateien für DOS (aus Windows heraus) zu erzeugen. Es gibt nur einen Editor mit Windows-GUI. Dort kann man im Einstellungs-Dialog die entsprechende Zielplattform über Radio-Buttons auswählen und für den Linker und den Compiler zusätzliche Kommandozeilenparameter in einem Textfeld angeben. Interessant ist hier das Tiny-Modell. Die GUI bietet in der Combobox für das Speichermodell keinen entsprechenden Eintrag an und die mitgelieferten Bibliotheken sind für dieses Modell nicht im Lieferumfang enthalten. Trotzdem wird das Kommandozeilen-Flag /TINY angeboten. Kopiert man die Tiny-Bibliotheken aus QC 2.5x, dann kann man auch mit QC for Windows COM-Dateien erzeugen. Den Sachverhalt habe ich aber beim Schreiben übersprungen, da der Workaround zu sehr ins Detail geht bzw. allein schon weil es ein Workaround ist. --Siegbert v2 (Diskussion) 20:00, 2. Aug. 2024 (CEST)

Ah danke für die Info. Einen Abschnitt weiter oben habe ich noch etwas zu OOP geschrieben. --84.158.120.82 23:33, 2. Aug. 2024 (CEST)

Versionen kann man im Inhaltsverzeichnis nicht anspringen

Wenn man === Überschriften nutzten würde, anstatt so einen komischen Anker, dann würden die Versionen im Inhaltsverzeichnis aufgeführt werden. --84.158.120.82 03:21, 7. Aug. 2024 (CEST)

Eben das möchte ich verhindern. Es muss nicht jeder unbedeutende Aufzählungspunkt im Inhaltsverzeichnis erscheinen, für z. T. nur eine einzige Anmerkung. Dieses würde sinnlos viel zu sehr aufgeblasen werden. Das ist nur eine nebensächliche Strukturierung des Fließtextes. Gleichwohl soll eine Möglichkeit bestehen gezielt zu einem Punkt zu springen (Permalink). Und letztendlich gäbe es Probleme mit der zusätzlichen Jahreszahl. Die hat in einer "echten" Überschrift nichts verloren und wäre automatisch Teil des impliziten Links, wenn man darauf verweisen würde; der Anker verhindert das. Würde man die Jahreszahl aus der Überschrift in den Text verschieben, wäre es wesentlich unübersichtlicher und jeder Block würde mit dem trivialen Satz "Die Version <xyz> erschien <abcd>." beginnen. Das ist unübersichtlicher und nervt einfach. Es reicht, wenn man diese Kurzinfo in Klammern hinter die Versionsangabe schreibt.

Im Zweifelsfall würde ich die Anker eher entfernen (bis auf QuickCaseW; das brauche ich demnächst), aber keine Überschriften für einen trivialen Satz. Den MS Image Editor und Dialog Editor kann man in WikiData als Objekt aufnehmen und dann gezielt zu deren Beschreibung springen; eigenständig sind sie nicht relevant und nicht separat (oder im Bundle mit anderen Programmiersprachen) zu erwerben. Mehr als jetzt muss man die Kurzbeschreibung dieser Tools aber auch nicht aufblähen, da wie gesagt eindeutig irrelevant. --Siegbert v2 (Diskussion) 05:32, 8. Aug. 2024 (CEST)

Also so wie es jetzt ist, ist es ineffizient und nicht funktional. Ich würde gerne direkt zur entsprechenden Version hinspringen können. Das Inhaltsverzeichnis wandert mit der nächsten Mediawikiversion sowieso auf die linke Seite der Seite, so wie es jetzt schon in der englischen Wikipedia der Fall ist. Außerdem wäre es gar nicht lang, wenn die Versionen darin einzeln aufgeführt werden, das passt alles auf einen Bildschirm und es kommen auch keine neuen Versionen hinzu. Den Anker kann ich nicht nutzen. Auch ärgerlich und ineffizient ist es beim Editieren. Unterkapitel haben ihren eigenen Edit Button, so dass man das gleich bearbeiten kann. So wie es jetzt ist, muss man sich durch den ganzen Geschichteabschnitt hangeln. --84.158.120.82 12:00, 8. Aug. 2024 (CEST)

PS: Oben habe ich vor ein paar Tagen noch etwas zum OOP Thema geschrieben, ich weiß nicht ob du es gelesen hast. --84.158.120.82 12:01, 8. Aug. 2024 (CEST)