Hallo Gemeinde.
Kann mir mal jemand kurz und prägnant aber fundiert und verständlich erklären worin der Unterschied zwischen den beiden Versionen liegt.
Ist VB eine nennenswerte Weiterentwicklung von QB oder nur eine verkaufsfördernde Marketingmasche?
Worin liegen die Unterschiede in Handhabung und Befehlssatz. Interpreter oder Compiler? Oder beides wahlweise?
Bis vor zwei Jahren hatte ich bei WINDOWS eine DOS-QBasic-Version dabei. Das WIN XP prof. hat keine mehr, obwohl der DOS-Bereich einwandfrei läuft. Und alles in C++ oder Assembler schreiben ist auch nicht immer sinnvoll. Und Quellcodes konvertieren von QB nach VB ist auch nicht tragisch, wenn es denn sein muss. Aber einfacher wäre es eine QB-Version zu installieren, wenn sie im Grunde genommen das gleiche kann wie VB!
Schon mal vielen Dank im Voraus.
Mit freundlichen Grüßen
Alexander Berresheim
Hallo,
Kann mir mal jemand kurz und prägnant aber fundiert und
verständlich erklären worin der Unterschied zwischen den
beiden Versionen liegt.
nein, das geht zu weit. Ich erzähle Dir lieber die Gemeinsamkeiten, das geht schneller. 
- Beide sind von Microsoft
- Beide nennen sich ‚Basic‘
- es gibt an vielen Stellen Ähnlichkeiten bei den Namen der Befehle.
Ist VB eine nennenswerte Weiterentwicklung von QB oder nur
eine verkaufsfördernde Marketingmasche?
VB ist eine Neuentwicklung, die mit QB nicht viel gemeinsam hat.
Worin liegen die Unterschiede in Handhabung und Befehlssatz.
Interpreter oder Compiler? Oder beides wahlweise?
Hmmm, Du hast den falschen Denkansatz. Was würdest Du antworten, wenn Dich Jemand fragt, welche Unterschiede gibt es zwischen MS-DOS und Windows-XP?
Bis vor zwei Jahren hatte ich bei WINDOWS eine
DOS-QBasic-Version dabei. Das WIN XP prof. hat keine mehr,
obwohl der DOS-Bereich einwandfrei läuft. Und alles in C++
oder Assembler schreiben ist auch nicht immer sinnvoll. Und
Quellcodes konvertieren von QB nach VB ist auch nicht
tragisch, wenn es denn sein muss.
Aber nicht möglich. Die Konzepte sind zu verschieden, als daß das möglich wäre.
Aber einfacher wäre es eine
QB-Version zu installieren, wenn sie im Grunde genommen das
gleiche kann wie VB!
Nein, QB kann auch nicht ansatzweise das Gleiche wie VB.
Was mit QB gemacht wurde, kann man mit VB auch machen, nur anders. Umgekehrt gilt das nicht, VB kann sehr viel mehr.
Der wesentliche Unterschied, In QB schreibst Du Deine Programme linear, als einen Code. VB ist Ereignisorientiert, Du brauchst einen völlig anderen Denkansatz. Wenn man das verstanden und verinnerlicht hat, geht mit VB alles sehr viel leichter als mit QB und man kommt sehr viel schneller zum fertigen Programm.
Gruß, Rainer
Hallo Rainer.
Hmmm, Du hast den falschen Denkansatz. Was würdest Du
antworten, wenn Dich Jemand fragt, welche Unterschiede gibt es
zwischen MS-DOS und Windows-XP?
Das läßt sich erklären, weil WINDOWS - zumindest bis XP - eine auf DOS aufgesetzte Bedieneroberfläche ist. Die Arbeit machte nach wie vor DOS.
Der wesentliche Unterschied, In QB schreibst Du Deine
Programme linear, als einen Code. VB ist Ereignisorientiert,
Du brauchst einen völlig anderen Denkansatz. Wenn man das
verstanden und verinnerlicht hat, geht mit VB alles sehr viel
leichter als mit QB und man kommt sehr viel schneller zum
fertigen Programm.
Jetzt weiß ich was Du meinst. Das nannte man früher ‚strukturiertes Programmieren‘ und war nach einer DIN-Empfehlung definiert. Ich habe seinerzeit viel Steuerprogramme für Prozessrechner an Sondermaschinen geschrieben. Die waren so aufgebaut. Dafür gab es dann spezielle Programmiersprachen, die eine Struktur in Programmmodulen ermoglichten. Sie hatten vor allem den Vorteil dass sie schneller liefen, da immer nur das Modul tätig war das gebraucht wurde. Und bestimmte Routinen waren durch spezielle Befehle einfacher zu programmieren. Ich schrieb damals allerdings fast ausschließlich in Z80-Assembler.
Aber ‚möglich‘ waren solche Strukturen auch in den alten Basic-Versionen. Es war nur viel aufwendiger und man brauchte eine eiserne Disziplin beim Strukturaufbau, sonst gab es die gefürchteten ‚Spaghetti-Programme‘.
Vielen Dank für Deine Aufklärung.
Mit freundlichen Grüßen
Alexander Berresheim
Hallo Alexander,
jetzt ist die Zeit reif zu fragen, welches VB Du meinst. Da hat es inzwischen schon wieder einen Sprung gegeben. VB2005 ist VB.net, dafür gibt es drei Zeilen weiter oben ein eigenes Brett. Ich kenne mich nur mit VB bis Version 6.0 aus und das ist inzwischen auch schon wieder veraltet.
Gruß, Rainer
PS. Wenn Du weißt, daß NT4,W2k,XP kein Dos haben, weißt Du doch, warum QB auf XP nicht mehr läuft. QB ist DOS-basiert.
Hallo Rainer
PS. Wenn Du weißt, daß NT4,W2k,XP kein Dos haben, weißt Du
doch, warum QB auf XP nicht mehr läuft. QB ist DOS-basiert.
Ich meinte dass die Verknüpfung von DOS und WIN ab XP prof. stark gelöst wurde und dass kein QBasic mehr mitgeliefert wird. Ein DOS-Bereich ist nach wie vor vorhanden, da arbeite ich viel mit.
Gruß Alexander Berresheim.
Hallo.
Ein DOS-Bereich ist nach wie vor vorhanden, da arbeite ich viel mit.
Das ist aber kein DOS mehr, sondern eine DOS- Emulation. Früher™ war Windows auf DOS aufgepfropft, man könnte auch -gemogelt sagen. Die jetzigen Windows-Versionen dagegen tun nur so, als könnten sie DOS.
Gruß Eillicht zu Vensre
Hallo Alexander,
Kann mir mal jemand kurz und prägnant aber fundiert und
verständlich erklären worin der Unterschied zwischen den
beiden Versionen liegt.
Ist VB eine nennenswerte Weiterentwicklung von QB oder nur
eine verkaufsfördernde Marketingmasche?
Es war einmal, so in den 60er Jahren des letzten Jahrtausends, als jemand eine Programmiersprache für Anfänger entwickelt hatte. Diese Sparche wurde B eginners A ll-pupose S ymbolic I nstruction C ode benannt.
Obwohl BASIC auf fast allen Grossrechnern mit Multiuser-Betriebssystemen vorhanden war, blieb es eine reine Programmiersprache für Applikationen.
Mit der Entwicklung der PCs wurde dann BASIC als Programmiersprache verwendet. Einerseits war der Interpreter relativ einfach zu implementieren und andererseits war auch die Sprache recht einfach zu lernen. Meist war auf diesen System BASIC auch gleich das „Betriebs-System“.
Da es sich nun um Single-Task/Single-User Systeme handelte wurde BASIC noch erweitert umd spezielle Hardware anzusteuern und direkt im Speicher rumzustochern (PEEK() und POKE()).
NAch einer Zeit des Wildwuchses, wurde ein grundlegender Befehls-Satz definiert, welcher in jedem BASIC vorhanden sein muss und als ANSI-Basic genormt.
Grundsätzlich war BASIC eine Interpreter-Sprache aber es wurden mit der Zeit dann zunehmend auch Compiler geschaffen.
Q-BASIC ist eine auf DOS angepasste weiterentwicklung von ANSI-BASIC.
Mit Windows ergaben sich dann Probleme für BASIC. Die Ausgabemöglichkeiten (PRINT) in BASIG sahen nur eine Console oder ein TTY vor, da waren keinerlei Befehle um Fenster und verschiedene Eingabeboxen anzusteuern vorhanden.
VB wurde nun für diese Bedürfnisse neu entwickelt. Dabei wurde einerseits ein Objekt-Orientiertes Modell hinzugefügt und auch die Möglichkeit um Ereignisse, also Meldungen von anderen Tasks, zu verarbeiten.
Im Gegensatz zum ANSI-BASIC ist bei VB der Programmablauf nicht mehr linear, sondern wird durch die Ereignisse gesteuert.
Allerdings enthält auch VB noch die Grundlegenden Befehle, welche im ANSI-BASIC festgelegt wurden.
Ein weiter Gedanke bei VB war, dass diese Sprache auch als Macro-Sprache für Windows-Applikationen verwendet werden kann. VBA entspricht der Definition von VB, ist wird aber, je nach Anwendung, durch entsprechende Objekte erweitert. Diese Objekte können aber auch direkt von VB verwendet werden um z.B. Word oder Excel anzusteuern.
Im Prinzip könnte man auch mit Q-BASIC noch Programme schreiben, welche Windows unterstützen. Allerdings müsste man sich dazu, durch Aufrufe der WIndows-API, in die Meldungs-Queue einhängen und dann die ganze Verwaltung selber Programmieren. Dieses Programm-Gerüst wäre dann schon einmal ein halbes Betriebssystem, welches man zu jedem eigentlichen Q-BASIC-Programm jedesmal mitschleppen müsste. Dabei würde man wohl schnell die Übersicht über das Egentliche Programm verlieren.
Wie du siehst gibt es im Kern noch Gemeinsamkeiten zwischen Q-BASIC und VB, aber die Beiden lösen gänzlich unterschiedliche Aufgaben.
Noch etwas zu deinem eigentlichen Problem:
Mit Windows wird der Scripting-Host mitgeliefert, welcher eigentlich für automatisierungsaufgaben vorgesehen ist und eigentlich schon eine eigene Programmiersprache ist.
MfG Peter(TOO)
Hallo Peter,
Da es sich nun um Single-Task/Single-User Systeme handelte
wurde BASIC noch erweitert umd spezielle Hardware anzusteuern
und direkt im Speicher rumzustochern (PEEK() und POKE()).
mal eine Frage, Basic war ein Interpreter, das heisst mit Peek und Poke konnte man zur Laufzeit quasi den Code ändern.
Ein VBA Code wird kompiliert und dann gestartet. Das kompilierte Programm steht ja wohl irgendwo im Arbeitsspeicher, kann man zur Laufzeit mit VBA-Befehlen dort den Maschinencode (assembler?) abändern? Also sowas wie poke oder peek für kompilierten Code?
Mal ein Beispiel
Ich habe
Sub tt()
Eingabe=Input(…)
If Eingabe=„kein A“
'jetzt quasi ein Poke in den kompilierten VBA-Code der in der nachfolgenden Codezeile anstatt „A“ was anderes anzeigen soll
MsgBox „A“
End sub
Ich hoffe ich konnte mich verständlich machen
Gruß
Reinhard
Das läßt sich erklären, weil WINDOWS - zumindest bis XP - eine
auf DOS aufgesetzte Bedieneroberfläche ist. Die Arbeit machte
nach wie vor DOS.
Das mag ich jetzt so nicht stehen lassen, auch wenn es in ein bisschen Off-Topic ausartet. Aber XP ist der Nachfolger von Windows 2000, welches ebenfalls auf den NT-Kern aufbaute. Dessen Vorgänger, Windows NT 4.0, baute ebenfalls auf den NT-Kern auf. Alles vollkommen unabhängig von DOS.
Die DOS-basierten Windows Versionen umfassen nur die Reihe 95/98/Me. Sogesehen hat Windows XP mit diesen Versionen eigentlich nichts zutun, und die Vorgänger von Windows XP ebenfalls nicht. Ich weiß, ist ein bisschen klugsch*ßerei jetzt, aber man sollte „WinDOS“ nicht mit Windows verwechseln 
Grüße
Lars
Gallo Reinhard,
mal eine Frage, Basic war ein Interpreter, das heisst mit Peek
und Poke konnte man zur Laufzeit quasi den Code ändern.
ja, auch das ging.
Ein VBA Code wird kompiliert und dann gestartet. Das
kompilierte Programm steht ja wohl irgendwo im
Arbeitsspeicher, kann man zur Laufzeit mit VBA-Befehlen dort
den Maschinencode (assembler?) abändern? Also sowas wie poke
oder peek für kompilierten Code?
Mal ein Beispiel
Ich habeSub tt()
Eingabe=Input(…)
If Eingabe=„kein A“
'jetzt quasi ein Poke in den kompilierten VBA-Code der in der
nachfolgenden Codezeile anstatt „A“ was anderes anzeigen soll
MsgBox „A“
End subIch hoffe ich konnte mich verständlich machen
Ja, natürlich konntest Du Dich verständlich machen.
Ob es Dir gelingen kann, die Speicheradresse des Programms zu finden, weiß ich nicht. Der Inhalt von Variablen ist leicht zu finden …
Ob Dich Windows in den Speicher des Programms schreiben läßt, weiß ich auch nicht, da rate ich mal … nein. Das Programm wird wohl abstürzen. Was ich mich aber frage: Wie willst Du die Speicherstelle finden? Der Maschinencode ist nicht so leicht lesbar, Das „A“ findest Du nicht, behaupte ich. Wenn das aber alles geht, darfst Du natürlich die Anzahl Bytes nicht verändern …
Jetzt frage ich mich nur noch, wozu? Vor 30 Jahren haben wir in Assembler so Schleifen programmiert. Mit VB so etwas zu programmieren ist wie mit einem Zyklotron Gold zu machen. … Wenn es geht.
Gruß, Rainer
Du hast Recht.Es war schon früher Schluss!(o.w.T.)
A.B.
Hallo Peter(TOO).
Recht herzlichen Dank für Deine ausführliche, historische Erklärung.
Ich melde mich mal bei Dir mit einer Mail, um noch eine paar Detailfragen für mein weiteres Vorgehen zu klären, auf die ich keine Antwort weiß. Eilt aber nicht!
Gruß Alexander.
Ich hoffe ich konnte mich verständlich machen
Gruß
Reinhard
Hallo Reinhard.
Ja.
Ob es geht? Im Prinzip nein, peek und poke war einmal. Hier handelt es sich dann zunächst um eine sogenannte Schutzverletzung, protected mode usw…
Es gibt aber einen Stapel für Befehle, bzw. Routinen, die aber nicht direkt zugänglich ist. Damit werden z.B. Funktionen instanziert. Eine Funktion kann sich damit quasi selbst aufrufen, so das plötzlich diese Routine 2 mal im Speicher steht.
Ein Programm, welches Programmcode in den Speicher schreibt und diesen auch noch verändern kann, ist zum Beispiel ein sogenannter debugger.
So ein debugger fordert ein Speichersegment an, welches entsprechende Oprationen(Zugriffsrechte) erlaubt.
Er muß unter anderem die Pipe der CPU berücksichtigen.
Etwas anderes ist bedingt erstellter Code, also abhängig von Parametern einmalig erstellter code. Das geht auch mit vb.
Natürlich könnte auch ein Programm ein neues Programm erstellen, speichern, und dieses starten.
MfG
Matthias
Hallo
Ich hoffe, Dir ist klar, das QB ein 16 Bit Programm ist, und vb(5) ein 32 Bitter.
Wenn Du das QB dopen willst, kannst Du zum Beispiel mittels Interrupts lange Dateinamen benutzen.
Da gibts auch coole Compiler(statt uncoole Interpreter), ich habe noch das Borland Power Basic.
Aber mal eben so 5 MByte für Textverarbeitung anfordern oder ein Eingabefeld mit drag and drop in ein Window ziehen, wird bei QB nicht klappen.
MfG
Hallo Matthias.
Zunächst mal vielen Dank für Deine Antwort.
Ich besitze z.Zt. überhaupt keine Basic-Version mehr, wohl aber einen ganzen Schwung von z.T. wertvollen Programmen aus dem tech./wissensch. Bereich im Quellcode, von denen ich einige weiternutzen möchte. Auch möchte ich Applikationen ohne jeden Hardware- und Ereigniskontakt mit einer Programmiersprache erstellen, die weitestgehend ‚basicähnliche‘ Befehle enthält. Und das Ganze soll natürlich unter WIN XP prof. laufen. Das Problem heißt also: Was tun?
Mit freundlichen Grüßen
Alexander Berrsheim
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo Alexander,
Ich besitze z.Zt. überhaupt keine Basic-Version mehr, wohl
aber einen ganzen Schwung von z.T. wertvollen Programmen aus
dem tech./wissensch. Bereich im Quellcode, von denen ich
einige weiternutzen möchte. Auch möchte ich Applikationen ohne
jeden Hardware- und Ereigniskontakt mit einer
Programmiersprache erstellen, die weitestgehend
‚basicähnliche‘ Befehle enthält. Und das Ganze soll natürlich
unter WIN XP prof. laufen. Das Problem heißt also: Was tun?
Dann sieh Dir mal VisualBasicScript an.
Du brauchst nicht mehr als einen Texteditor.
Unter der Bezeichnung script56.chm findest Du bei MS eine vollständige Anleitung.
Gruß, Rainer
Hallo Alexander,
Recht herzlichen Dank für Deine ausführliche, historische
Erklärung.
Ich melde mich mal bei Dir mit einer Mail, um noch eine paar
Detailfragen für mein weiteres Vorgehen zu klären, auf die ich
keine Antwort weiß. Eilt aber nicht!
Ja, mail mal.
In den letzten 30 Jahren, habe ich Projekte mit 15 bis 20 unterschiedlichen BASIC-Dialekten auf unterschiedlichen Betriebssystem ausgeführt. igentlich hatte ich vor 15, 20 Jahren BASIC zur Seite gelegt und mich Pascal, anderen Sprachen und vor allem C zugewant. Vor 10 Jahren habe ich dann VB verwendet, weil damit die Oberflächen für Win95 einfacher zu gestalten waren. Heute verwende ich haupsächlich einen Mix aus C, VB und C++, da VB nicht so gut auf Micro-Controllern kommt, aber die meisten Geräte auch eine Bedienung auf dem PC benötigen. C auf dem PC ergiebt sich meist dadurch, dass ich dann den Sourcecode für die Protokolle auf dem Controller und dem PC verwenden kann. Auf dem PC wird dann der C-Code mit C++ als COM-Object gekapselt.
Kann also etwas dauern, bis ich das wieder aus meinem Gedächnis hervorgekramt habe.
MfG Peter(TOO)
Win und DOS
Hallo Lars,
Das läßt sich erklären, weil WINDOWS - zumindest bis XP - eine
auf DOS aufgesetzte Bedieneroberfläche ist. Die Arbeit machte
nach wie vor DOS.Das mag ich jetzt so nicht stehen lassen, auch wenn es in ein
bisschen Off-Topic ausartet.
Geht mir auch so.
Aber XP ist der Nachfolger von
Windows 2000, welches ebenfalls auf den NT-Kern aufbaute.
Dessen Vorgänger, Windows NT 4.0, baute ebenfalls auf den
NT-Kern auf. Alles vollkommen unabhängig von DOS.
Genau.
Die DOS-basierten Windows Versionen umfassen nur die Reihe
95/98/Me. Sogesehen hat Windows XP mit diesen Versionen
eigentlich nichts zutun, und die Vorgänger von Windows XP
ebenfalls nicht. Ich weiß, ist ein bisschen klugsch*ßerei
jetzt, aber man sollte „WinDOS“ nicht mit Windows verwechseln
Bis Win 3.x war Windows eine Anwendung, bzw. ein besserer Ersatz für COMMAND.COM, welche unter DOS gestartet wurde. Wer’s noch kennt, GEM funktionierte auf die selbe Weise.
Mit Win95 wurde dann der DOS-teil in Win eigebaut und konnte dadurch auch vom erweiterten Speichermodell (Flat Modell mit 4GB Adressraum ohne Segmentierung), dem Multitasking und der 32-Bit CPU Gebrauch machen (Bis Win 3.x musste immer zwischen dem 8086-Mode und dem Protectet-Mode umgeschaltet werden, was beim 80286 nur über einen Hardware-Reset machbar war, also recht zeitaufwändig, seit dem 80386 hat die CPU dafür Befehle, bzw. spezielle Speicherbereiche).
Insofern ist das DOS-basierende Win erst seit Win95 ein Betriebssystem.
OS/2 und Win NT waren von Anfang an eigenenständige Betriebsysteme, mit einer DOS-Emulation und bei NT auch einer für OS/2.
MfG Peter(TOO)
Hallo Alexander,
Zunächst mal vielen Dank für Deine Antwort.
Ich besitze z.Zt. überhaupt keine Basic-Version mehr, wohl
aber einen ganzen Schwung von z.T. wertvollen Programmen aus
dem tech./wissensch. Bereich im Quellcode, von denen ich
einige weiternutzen möchte. Auch möchte ich Applikationen ohne
jeden Hardware- und Ereigniskontakt mit einer
Programmiersprache erstellen, die weitestgehend
‚basicähnliche‘ Befehle enthält. Und das Ganze soll natürlich
unter WIN XP prof. laufen. Das Problem heißt also: Was tun?
Der technische Teil, also die Rechnerei, sollte sich ohne allzugrossen Aufwand an VB anpassen lassen (vieles geht da schon mit Search&Replace) wenn diese Programme vernünftig strukturiert sind.
Soubroutinen in Funktinen umzustricken ist auch nicht so schwierig.
Der grösste Aufwand wird sich dann bei der Ein-/Ausgabe ergeben.
MfG Peter(TOO)
Ich habe jetzt einen Überblick!
Hallo Gemeinde.
Vielen Dank an alle die mir geantwortet haben. Ich glaube ich kann mir jetzt ein Bild machen wie ich weiter vorgehen soll.
Mit freundlichen Grüßen
Alexander Berresheim