Visual Basic (ohne .NET): Warum ist die Sprache gut/schlecht?

Hallo zusammen,

ich habe schon sehr oft Diskussionen über C++ und VB miterlebt. Die einen Sagen warum soll ich mich mit Pointern etc. quälen, wenn ich es mit VB viel einfacher haben kann und VB mir ja auch OpCode erzeugt. Die anderen sagen VB ist nich systemnah (nur mit bestimmten Mitteln) und langsam. Ich habe nicht die Absicht hier Visual Basicprogrammierer irgendwie runterzuputzen, denn auch diese Sprache hat irgendwo ihre Darseinsberechtigung. Es interessieren mich lediglich viele Dinge an dieser Sprache und ihrer Eigenarten.

Was ich so an Nachteilen gefunden habe:

• Benutzt für jedes Programm COM-Objekte.
• Viel Overhead, kein echter Maschinencode (Warum? Weil abhängig von Libary/Interpreter?)
• Kein OOP. (Objekt-orientierte Programmierung) - keine Verebung - keine Polymorphie - und keine Exceptions etc.
• Keine systemnahe Programmierung (nur durch API Importierung). Beschränkt auf Funktionen des Interpreters.
• Kein strukturierter Code. (meiner Meinung nach eher Geschmackssache als Nachteil)
• Braucht Runtime-Packages. Keine eigenständige Anwendung.
• Schreibfehler werden direkt als neue Variable(Variant) angesehn.
• VB-Code ist langsam.
• Keine Typsicherheit.
• Treiberprogrammierung kaum möglich (wer schreibt sowas auch...)

Was für die Sprache spricht ist natürlich der leichte Einstieg mit dem man sehr schnell seine Erfolge sieht oder schnell mal eben einen Prototypen zusammenbauen kann. Außerdem wird im Office Umfeld ja ebenso VB eingesetzt.

Was mich interessieren würde wie das mit dem Zugriff auf Speicher, andere Anwendungen usw. in VB gehandhabt wird. In C++ hab ich ja quasi die volle Kontrolle und wenn ich weiss was ich tue, kann ich alles mögliche damit machen. Ich kann an Adressen springen, dinge verändern etc.

Hat man diese Möglichkeiten in VB auch? Wie ist es z.B. Wenn ich feststellen will ob an einer bestimmten Adresse etwas geändert hat oder einen Wert hineinschreiben will? Wie sieht es aus mit grafischen Schnittstellen wie z.B. OpenGL? Hat man auf sowas vollen Zugriff um irgendwas zu machen?

Visual Basic ist ja von einer Libary abhängig. D.h. für jede Funktion von VB muss es irgendwie eine Interpretation der Methoden in dieser Libary geben (korrigiert mich, wenn ich da falsch liege). Wenn ich jetzt z.B. eine Methode aufrufe (Screenshot machen beispielsweise) müsste es doch theoretisch einfach möglich sein den Aufruf einer solchen Methode mit einem anderen Programm zu erkennen (vielleicht sogar mittels WMI?) oder nicht? Das andere Programm könnte dabei in beliebiger Sprache geschrieben sein, die systemnah interagiert wie z.B. C++. Wie würde sowas funktionieren und könnte man sowas in VB z.B. mitbekommen?

Und wie seht ihr das ganze mit VB?

Grüße Marco

Ich find, VB war mal super. Die ham glaub, das Designer - Konzept erfunden, oder täuschich mich?

Aber heutzutage sehe ich keinen Sinn darin, über eine nicht OOP-Sprache nachzudenken, wenn man eine mit OOP haben kann.

Hallo,

ich hab meinen Programmiereinstieg mit VB6 gehabt. Warum vergleichst du bzw. warum wird immer wieder VB mit C++ gemessen? Die beiden Sprachen decken doch unterschiedliche interessens Gebiete ab. Man vergleicht ja auch nicht Äpfel und Birnen auf ihre Schönheit...

Meiner Meinung war VB eine gute Einsteigersprache, heutzutage macht es aber wenig sinn erste Erfahrungen in VB zu sammeln wenn es VB.net oder ohnehin C# gibt. Fortgeschrittene wissen nach einer Zeit ohnehin in welcher Sprache sie welche Aspekte nutzen können und worauf sie sich spezialisieren sollen.

Ein paar kleine relativierungen:

Kein strukturierter Code. (meiner Meinung nach eher Geschmackssache als Nachteil)

Verstehe nicht wie du das meinst? Es gibt auch in VB sogennate Module bzw. Klassen.

Braucht Runtime-Packages. Keine eigenständige Anwendung.

Auch C++ braucht eine Runtime Library

VB-Code ist langsam.

Diese Aussage halte ihc für sehr allgemein gehalten.

In C++ hab ich ja quasi die volle Kontrolle und wenn ich weiss was ich tue, kann ich alles mögliche damit machen.

So einfach gehts nun auch nicht auf Speicher fremder Anwendungen zu schrieben

Bei deiner Frage kann ich dir gezielt nicht weiter helfen, glaube aber nicht dass das trivial ist. Machbar ist vieles, wenn es aber geht wäre es ein ziemliches Sicherheitsleck.

mfg Markus

Hallo 1nf1n1ty,

also ich bin in der nicht so glücklichen Lage noch VB6 zu programmieren (mehr Support und gesetzliche Umsetzungen), daher kann ich mir auch ein gewisses Urteil darüber erlauben:

• Kein OOP. (Objekt-orientierte Programmierung) - keine Verebung - keine Polymorphie - und keine Exceptions etc.

Naja, ich würde sagen, dass es nicht die volle OO Unterstützt, es ist aber weit Objektorientierter als man annehmen würde. Ich war erstaunt, welche Möglichkeiten es mit VB6 in Richtung OO gibt. Es gibt Klassen, Module und Formulare, das reicht um Business-Logik von GUI zu trennen und auch Modular zu programmieren.

Exceptions mag es vielleicht nicht mit einer Klassenumsetzung geben, es gibt Errors und eine Fehlerbehandlung lässt sich durch Sprungmarken sehr leicht realisieren. Ich finde das zwar eine Umgewöhnung, aber grundsätzlich ist damit auch alles erschlagen, was es zu Fehlerbehandlung gibt.

• Kein strukturierter Code. (meiner Meinung nach eher Geschmackssache als Nachteil)

Das ist nun überhaupt nicht wahr. Das kommt wie bei fast jeder Programmiersprache darauf an, wie man den Quellcode schreibt und in welche Codeteile man das verpackt. Die Syntax mag vielleicht für C++/C# Programmierer umständlich erscheinen, aber man gewöhnt sich schnell daran.

• VB-Code ist langsam.

Das würde ich vehement widersprechen. Es kommt ganz darauf an, was man damit programmiert. Selbstverständlich wäre z.B. in der digitalen Bildverarbeitung und bei Bitoperationen C wahrscheinlich schneller, aber in Windows-Fenster Anwendungen ist es keineswegs langsamer oder schneller (dafür aber wesentlich komfortabler als mit C++!)

• Keine Typsicherheit.

Das bietet meines Erachtens C++ auch nicht, wenn ich schon irgendwelche Void-Pointer sehe, da wird mir fast schlecht. Was oft mit "Typunsicherheit" verwechselt wird ist das "komfortable, automatische" Casten auf entsprechende Objekte, das VB6 typunsicher erscheinen lässt. Falls aber ein Cast nicht funktioniert gibt es genau wie in C++ einen Laufzeitfehler.

• Benutzt für jedes Programm COM-Objekte.

Da bin ich mir gerade nicht so sicher. Meiner Meinung nach kann man auch ohne COM auskommen, aber man verzichtet dann eben auf den ganzen Designerkomfort und die Basis was VB in der Fensterprogrammierung ausmacht.

Grundsätzlich würde ich folgende Aussage treffen VB6 ist sehr Fensterorientiert und bietet mit DAO auch eine akzeptable Methode um schnell und komfortabel mit Datenbanken zu kommunizieren. Bei C++ muss vieles zu Fuß gemacht werden und bietet mehr "Kontrolle" was mit dem eigenen Arbeitsspeicher passiert und agiert so gesehen etwas hardwarenäher. Aber das ist gleichzeitig auch der Fluch von C++: Speicher muss manuell freigegeben werden. VB6 hat für COM Objekte oder Fensterereignisse z.B. ein eigenes Speichermanagement.

Aber alles in Allem frage ich mich, warum man sich überhaupt noch mit VB6 oder C++ herumschlagen möchte. Dot-NET ist hier klar zu präferieren. Es gibt für mich eigentlich nur noch wenige Anwendungsfälle, bei denen man auf C (dann aber Plain-C) zurückgreifen muss. Managed C++ sei jetzt mal ausgenommen, das stempel ich mit Dot-Net ab.

Also warum interessiert Dich das denn überhaupt noch?

Grüße
Norman-Timo

Hallo zusammen,

wie ich es mir schon fast gedacht habe ist dieses Thema sehr gewagt. Wie jedoch auch vorher erwähnt möchte ich hier niemandem auf den Schlips treten oder so. Hintergrund dieser Diskusion ist folgender:
Ich möchte z.B. gerne ein Programm überwachen welches gestartet wird im Hinblick darauf ob Fremdapplikationen zu Laufzeit des zu überwachenden Programms irgendetwas ändern, was nicht gestattet ist. Ein sehr gutes Beispiel hierfür wären z.B. Onlinecheats für den Multiplayer. Da wird ja teilweise etwas am Spiel verändert um Sicherheitsmechanismen auszuhebeln und weiter etwas an der Grafikdarstellung verändert um irgendwelche Vorteile gegenüber anderen Spielern zu haben. Nun gibt es ja auch eine Reihe von Tools gegen solche Cheatcoder, allerdings sind diese teilweise eben mit VB geschrieben (Habe auch schon welche mit .NET 2.0 gesehen). Ich frage mich da natürlich schon ob diese wirklich geeignete Sprachen sind um solche Dinge festzustellen, da sich die Coder solcher Programme ja teilweise richtig fiese Tricks ausdenken um ein solches System zu überlisten. VB und .NET scheint mir irgendwie nicht Systemnah genug um sowas zu bewerkstelligen. Es könnte jedoch auch sein, dass ich mich Irre, belehrt mich dann bitte eines besseren.

Was ich suche sind eben Argumente dafür bzw. dagegen.

Grüße Marco

also ein wächterprogramm.

das problem ist, das man immer nur eines machen kann:
reagieren.

ein cheater denkt sich einen weg aus etwas zu machen und du musst diesen weg per reverse engeneering analysieren und dann an einer oder mehreren stellen dieses weges ein tor, falle oder alarm einbauen. hierbei gibt es bereits allgemein bekannte wege, die du von anfang an abdecken solltest (frag mich nciht welche...).

ansonsten bleibt dir nur das stetige updaten deiner bemühungen, wobei du den "bösen buben" immer mindestens einen schritt hinterher hinken wirst.

edit: ich würde das mit ansi-c oder gar assembler machen.

Hallo JAck30lena,

also ein wächterprogramm.
edit: ich würde das mit ansi-c oder gar assembler machen.

Kannst du das Begründen? Ich mein C ist halt schon sehr systemnah aber ASM kann ich nich richtig verstehen, weil die Sprache ist ja sehr weit unten angesiedelt. Warum wäre es vorteilhafter soweit runter zugehen? Wären da Vorteile gegenüber C?

Hallo JAck30lena,

Nochma zum Thema Reverse Engineering: Welche Möglichkeiten habe ich da? Wie weit kann ich da zurückgehen? Jedes Programm erzeugt ja in irgendeiner Weise Maschinencode, der in ASM rückübersetzt werden kann. Gibt es aber auch eine Möglichkeit den Code in die Ursprungssprache zu übersetzen? Bei .NET fällt mir z.B. der .NET Reflector ein, den man dafür benutzen kann die Codes einzusehen, sofern diese nicht durch Mechanismen gesperrt werden.

Gibt es Vergleichbares/Ähnliches für andere Sprachen?

€: Sollte kein Doppelpost werden, hab mich nur in zitieren/editieren geirrt :x

wenn man etwas mit assembler nicht schafft, dann kann man es nicht schaffen.
es geht dabei auch um das verhindern der cheatwege. dabei machst du im prinzip nichts anderes als es ein cheat auch machen würde, nur das du die lücke nicht öffnest, sondern versiegelst. richtig gute private cheats sind auch meistens in c oder c++ geschrieben. die hardcorehacks sind in assembler, da man da alle möglichen wege benutzen kann. hab mal einen cheat für GunGame in assembler gesehen... feines teil... oder für diablo2 (das hat übrigens einen recht guten wächter) gibts auch einen noch nciht entdeckten private cheat, der mir bekannt ist und der ist in c geschrieben.

gegen die private cheats kommst du mit keinem anti-cheatprogramm an, da dir der weg nicht bekannt ist... (außer ein public cheat nutzt den selben weg)

Gibt es aber auch eine Möglichkeit den Code in die Ursprungssprache zu übersetzen?

nein.

Bei .NET fällt mir z.B. der .NET Reflector ein

.net ist genauso wie java eine ausnahme, da diese keinen direkten nativen code erzeugen. daher lässt sich die.exe z.b. wieder fast originalgetreu wieder in lesbaren code widerherstellen (jajaja... es gibt da auhc sicherheitsmechanismen, hier aber irrelevant).

deswegen solltest du dich auch mit assembler auseinandersetzen, dann wird dir das reverse engeneering leichter fallen...

Je systemnaher eine "Programmiersprache" (oder wie du schreibst, weiter unten) lässt sich besser (nicht aber aber einfacher) auf Hardware zugreifen. Treiber (der Zugriff auf die Hardware) wird nur in C oder Assembler geschrieben weil es dort eben möglich ist, auf den Stack, CPU-Register oder IRQs zuzugreifen. Hochsprachen wie VB(.NET), C# usw. greifen nur auf HAL (Hardware Abstraction Layer). Dafür gibts fertige P/Invoke oder COM-Funktionen

auf den Stack, CPU-Register oder IRQs zuzugreifen eben die sind beim cheaten von interesse... genauso wie ramadressen oder noch besser cache bereiche (den cheat interessiert ja auch nur was gerade vom programm benötigt wird)

Ok, dann wäre da wohl Assembler die Sprache der Wahl. Hat jemand mal damit gearbeitet und kennt sehr einsteigerfreundliche Tutorials für x86? Ich war bisher nur in C aktiv, Assembler würde mich aber dennoch mal interessieren.

Assembler for Dummies
(Titel bitte nicht erst nehmen)

Hallo

Habe da auch noch einen Link:
Assembler Tutorial

Private Cheats können genau so erkannt werden wie Public Cheats den Sie unterscheiden sich im Prinzip nicht. Das Problem ist das die meiste AntiCheat Software nach einen sehr simplen Prinzip funktioniert. Sie speichern z.b die crc von bekannten Cheats und vergleichen diese dan mit deinen Cheat. Bei Private Cheats sind diese duch den kleinen Benutzerkreis umbekannt.

Wenn du eine etwas umfangreichere Anti Cheat Software schreiben möchtest kanst du das auch ohne weiters in C# oder VB machen. Ein gutes tool ist z.b Aequitas. Das Problem ist jedoch bei sicherer Software das du in die Privatsphere des benutzers eindringst.

Private Cheats können genau so erkannt werden wie Public Cheats den Sie unterscheiden sich im Prinzip nicht.

da muss ich dir widersprechen.

1. ist die herangehensweise meist eine andere
2. ist die herangehensweise meist die bessere oder durchdachtere

Sie speichern z.b die crc von bekannten Cheats und vergleichen diese dan mit deinen Cheat.

ja und das schimpft sich dann anticheat... das ist das negativbeispiel dieses nischenmarktes.

das VAC von valve z.b. ist so schlecht, das von schutz überhaupt nicht die rede sein kann. es durchsucht z.b. das filesystem an definierten orten nach dateien bestimmten namens und schreit dann ggf. "cheat"... so reicht es z.b. eine neue datei mit einem gewissen namen und einer gewissen endung zu erstellen, um von valve rausgeschmissen zu werden. oder in bestimmten dateien reicht ein stichwort als asci zeichenfolge um als cheater erkannt zu werden.

sowas ist müll und das kannst du natürlich auch mit c# erreichen. für allgemeinen "schutz" kann man das machen. wenn du aber eine spezielle software schützen wilst, dann mach sowas wie es der wächter von diablo2 macht. jeglicher zugriff auf diablo2 dll´s wird sofort erkannt....

Ein gutes tool ist z.b Aequitas

*HUST*

Entschuldige bitte, aber ich finde Aequitas keinesweg so gut wie du. Es kann Configs checken. Es gibt allerdings auch die Möglichkeit verbotene Befehle mit Hilfe von PAKs zu verstecken. Diese Technik ist lange bekannt, Aequitas setzt diese nicht um, bzw. prüft diese nicht.

Aequitas macht soweit ich das sehe eine Prozessliste und führt entsprechend wie erwähnt CRC bzw. MD5 Checks durch, um nach bekannten Cheats zu suchen. Das ist wie bereits erwähnt eine unbefriedigende Art derartige Programme zu erkennen. Cheatcoder wie Organner gehen bei sowas direkt auf Treiberebene und laden ihre Cheats direkt ins System.

Aequitas macht Screenshots, verwendet dabei aber bestimmte Libarys. Anscheinend ist es den Cheats jedoch möglich zu erkennen, wenn eine dieser Screenshotfunktionen aufgerufen wird. In dem Falle wird der Cheat für kurze Zeit deaktiviert -> Screenshots sehen sauber aus. Das funktioniert teilweise selbst bei den Publiccheats, demnach ist diese Funktion in dieser Implementierung unbrauchbar.

Theoretisch kann außerdem jeder Cheat Aequitassicher sein, der

• Aequitas nicht in irgendeiner weise blockt (sowas wird erkannt).
• dessen CRCs/MD5s nicht bekannt sind.

D.h. wer will kann einen billigen VAC 2 Aimbot nehmen (Sourcecodes gibts ja genug), etwas daran verändern, compilieren und hat einen "sicheren" Cheat, der unter Aequitas funktioniert. Natürlich lässt sich ein Aimbot durch das genaue betrachten der Demos erkennen.

Also alles in allem find ichs irgendwie ziemlich schlecht.