Visual Basic steht vor dem Aus - MS bleibt hart

@.r@zor>FX: Kompliziert? Durch die riesige vorhandenen .NET Klassen wurde vieles einfach!!! Und schön sieht es auch nicht aus, da die .NET Windows Forms kaum besser aussehen als die Win98 Fenster etc., alles andere sind WindowForms von Drittanbietern!!!

@DerDon: Das Problem von VB.net gegenüber VB6 ist die Lernkurve. Bei VB6 fängt sie ganz unten an, und steigt dann immer stärker an. Bei VB.net fängt sie erheblich weiter oben an, bleibt dann aber relativ gleich. VB6 ist also ideal für Anfänger, während VB.net erst dann richtig geil ist, wenn man die Anfangshürde genommen hat.

@DerDon: Es bedarf jedoch nur geringer Aenderungen um Xp Syle zu aktivieren:
In die "Public Shared Sub Main()" folgenden code einfuegen:
application.EnableVisualStyles()
application.run(New nameDerMainForm)
und bei jedem control, welches die eigenschaft FlatStyle hat, diese auf System setzen!

@Rika: ja das stimmt. in .net ist die achso beliebte produktivität auch verloren gegangen. vb und d$ liegen hier fast gleich und das ist nicht gut für vb. vb6 ist ein ganzes stück leichter als .net!

@Rika: Naja, bis auf einige Mouse-Events konnte ich mein einziges Projekt bisher erfolgreich migrieren... aber gerade die waren geil. :)

@icetea: ich denke du unterschätzt vb .net. generell leiden vb-programmierer an einem minderwertigkeitskomplex. der name Basic hat keinen tollen ruf. vergleicht man allerdings vb1 mit der heutigen version vb .net muss man doch deutlich sagen, dass hier eine durchaus komplexe sprache vorliegt. vb ist nicht unbedingt die kinderleichte sprache für kleine kinder wie manche c-programmierer meinen. C$ und vb .net sind denke sehr ähnlich. vb .net deutlich schwerer als vb6. ein vb .net programmierer wird es zudem nicht schwer haben auf c$ umzusteigen. daher wurde hier vb um einiges aufgwertet. es ist auch umso schneller. daher würde ich nicht einfach so sagen "...oder man denkt über eine ordentliche sprache nach". Gleichzeitig bin ich aber auch der Meinung das die Sprache C mit C$ wiederrum etwas verloren hat 8einiges gewonnen, ok, aber auch viel verloren). Aber das ist wieder ein anderes Thema. Es geht letztendlich um Produktivität und nicht darum, dass nur der absolute Guru Coden kann. Dann könnten wir gleich bei assembler bleiben.

@icetea: VB.net unterscheidet sich von C$ in kaum mehr als der Syntax. VB.net ähnelt einer natürlichen Sprache, C$ ist eher ASCII-Art *duck*.

VB.NET ist eher ein schlechte Emulation von C.Sharp mit VB-Syntaxelementen. VB ähnelt indes auch keine verständlichen Programmlogik, mit VB.NET hat sich das nur in dem Sinne gebessert, als daß man es als andere Ausdrucksform von C.Sharp auffassen kann.

@rika: koenntest du mir erlaeutern, wo eine "schlechte emulation von C$" vorliegt???

VB.NET-Programme werden im Compiler in die gleichen Syntax-Elemente wie CSharp-Programme zerlegt, mit dem Unterschied daß CSharp eine direkte Darstellung dieser Elemente bietet. Du kannst sogar jedes VB.NET-Programme maschinell exakt in ein äquivalentes CSharp-Programm übersetzen: umgekehrt geht das allerdings nicht, da VB.NET nicht so mächtig wie CSharp ist.

das stimmt nicht so ganz. es stimmt zwar, das einige elemente in vb weniger abstrakt sind, und durch c$ elemente ersetzt werden, allerdings nicht in einer art "schlechten emulation". Klar ist, das viele Befehle vereinfacht wurden um die Produktivität zu steigern. Und VB ist in vielen Fällen unbestritten Produktiver als C$. Zudem ist C$ nicht viel mächtiger als vb. Man kann daher mit vb genau so gut viele Probleme lösen und hat auch kaum Geschwindigkeitsvorteil. Man müsste da wirklich mit einer Stoppuhr ran, um den Unterschied festzustellen.

@Rika: Was kann C$ was VB.net nicht kann?

soweit ich informiert bin sind das überiwegend kleinigkeiten. z.b. waren am Anfang Dinge wie unsigned int nicht möglich. Aber das ist mittlerweile auch in vb möglich. Möglich sind solche erweiterungen nicht zuletzt dank der IL. Da bei beiden hinterher eh fast der gleiche Code heraus kommt, kann man auch an der Sprache etwas 'rumschrauben'. Jedoch sollte es ja nicht übertrieben werden, weil man mit vb eben schneller sein und weniger Lernaufwand haben möchte. Bei C$ sind es halt so Sachen wie XML usw. wo man damit besser voran kommt. Jedoch sind das eben Sachen die Programmiertechnisch nicht so sehr von bedeutung sind.

@chromeboy32: Visual Studio umfasst 1 DVD. Da ist aber noch MSDN, C++, C$, J$ usw. dabei.

@svenyeng: Solange $Develop keinen integrierten Debugger mitbringt, ist es aber leider mehr oder weniger unbrauchbar.

@svenyeng: [ironie]fuer was $Develop? notepad.exe und vbc.exe tuns auch :-)[/ironie]

@googler: Ja, und manche schreiben auch direkt in IL-Code. Aber auf Sachen wie IntelliSense, automatische Codeformatierung, integrierten Debugger u. ä. möchte ich nicht verzichten.

@Tiku:sorry, hab ironie tags vergessen...
ich verwende das vs.net 2003, also keine sorge :-)

hmm. wäre gar keine schlechte idee :) dann fehlt nicht mehr viel bis asm und das ist und bleibt wohl die beste aller sprachen :) zumindest was geschindigkeit und größe angeht :)

@pilzeman: das ist kein nachteil. für vb brauchtest du auch runtimes und selbst für mfc-programme sind dll's notwendig! ab longhorn wird das .net framwork fest integriert sein.

Dachte da eher an Win 95/98 WinNT.
Da laufen VB6 Programme in der Regel ohne zusätzliche Installationen von irgendwas.
Einfach ein Tool in VB6 geschrieben, und läuft auf jedem Rechner ohne gedanken zu machen hat der Framework oder nicht.

@pilzeman: "Einfach ein Tool in VB6 geschrieben, und läuft auf jedem Rechner ohne gedanken zu machen hat der Framework oder nicht." Ähm, Du gehst dabei davon aus, dass die VB6-Runtimes vorhanden sind. Das ist aber ganz und gar keine gute Idee.

@XDestroy: "selbst für mfc-programme sind dll's notwendig" - Das ist falsch. Du kannst statisch linken, sind 2-3 Mausklicks einmalig pro Projekt und schon haste ne EXE, die keinerlei MFC DLLs (oder andere) mehr braucht. Dazu muss man auch sagen, dass es auch möglich ist, ganz auf MFC und Konsorten zu verzichten, dann wird gar nix gebraucht, diese Möglichkeit hat man unter VB6 und .NET nicht. ... Achja: Ein Vorteil der VB6-Routinen: a) Sie sind *deutlich* kleiner zum Downloaden (es gibt immer noch 56k-Modemuser :) ). b) Win95-kompatibel (in manchen (zugegeben und glücklicherweise: immer weniger werdenden) Bereichen immer noch von Bedeutung).

der Vorteil der größe ist wirklich etwas, das mit auch am herzen liegt. Man ist heute leider etwas verschwenderischer geworden. jedoch wird das später keinen unterschied mehr machen. vor ein paar jahren waren 128 mb noch "oh yes" und heute gibt sich manches nicht mit weniger zufrieden... :) daher denke ich ist das eine sache die verwachsen wird.

@XDestroy: Man muss dabei auch bedenken, was das .net-Framework alles mitbringt. Dagegen sind MFC und VB6 ziemlich spartanisch.

@TiKu: Ab Win95 und WinNT4 SP4 sind die VB-Runtimes vorhanden und mehr erwarte ich auch nicht.
Da kann das Framework nicht mithalten.

@pilzeman: Diese Vorgehensweise ist trotzdem keinesfalls zu empfehlen. Du weißt nicht, welche Version der Runtimes installiert ist. Dass auf einem Win95 und NT4 die VB6 Runtimes vorinstalliert sind, nehme ich Dir schonmal nicht ab, da VB6 später erschien. Dann kommt noch das SP-Level der Runtimes ins Spiel. Wenn das Programm über ein "Hallo Welt" hinausgeht, sollte man wenigstens die SP5-Runtimes nutzen.

@aliasname: War VSA (das ist was Du mit .NETA meinst) nicht für Office 2003 oder Office 12 geplant? Was is'n daraus geworden?

@aliasname: Es gibt schon ein Pendant zu VBA. VSTO http://www.microsoft.com/germany/msdn/vsto/default.mspx funktioniert ab Office 2003 und man kann damit .NET Code in Office Dokumenten speichern!!

*gelöscht*

@svenyeng: das stimmt.
und bis jetzt sind meines wissens nach kaum schwerwiegende sicherheitsluecken im framework 1.1 aufgetaucht!
ms kann es offenbar doch ganz gut

@svenyeng: ICh gerhöre zu denjenigen, die nichts vom Framework halten! Das kommt mir nicht auf die Platte!

@Eddies UDDR: Begründung?

@TiKu: Sein Problem, muss er halt auf Paint .Net usw. verzichten!

@Eddies UDDR: Als Windows ME Anwender solltest du sowieso über den ein oder anderen Upgrade nachdenken.

@svenyeng: Sorry, aber ich sehe nicht, dass man ohne nicht zu recht kommen sollte. Wir haben ein breites Softwarespektrum bei uns im Institut, das ich administriere, am Laufen, meistens die aktuelle Version der Software, aber .NET wird nur von einiger meiner Adminprogramme benötigt, sonst zur Zeit noch von nichts (es ist aber trotzdem drauf, wir sind also gewappnet). 95% der Programme, die auf den Systemen laufen, sind immer noch C/C++ als .EXE mit keinen, Standard- oder proprietären DLLs. (Versteh ich mich nicht falsch: Ich bin absoluter .NET-Fan und ich installier es überall drauf, nur die Aussage, man käme ohne nicht mehr zurecht, ist absolut nicht der Fall. Bei dir mag das stimmen, weil du entsprechende Softwareprodukte verwendest, aber die Masse wird es noch nicht unbedingt brauchen.

@swissboy: Und die wären?
@TiKu: das riesenpaket macht sich ganz schön im System breit und verlahmt!

@Eddies UDDR: Einen Geschwindigkeitsnachteil kann ich nicht wirklich erkennen. Stimmt, es integriert sich ins System, aber darin kann ich keinen Nachteil erkennen.

es verlahmt keineswegs. nicht dein system! was aber klar ist, dass alle IL programme ganz klar den nachteil haben das sie langsamer sind als programme die in reinem C/C++ beispielsweise geschrieben sind. Ein MFC ist und bleibt schneller als ein .net Programm und ein Programm das nur die WinAPI verwendet wird noch nen tick schneller sein usw. (und kleiner)! Jedoch beeinflusst das framework nicht das system selbst das man sagen kann es "verlahmt".

@XDestroy: Wobei der Geschwindigkeitsnachteil eigentlich nur beim 1. Start der Anwendung (durch JIT) so richtig zum Tragen kommt. Ansonsten ist er normalerweise nicht spürbar (jetzt mal von irgendwelchen richtig aufwendigen Berechnungen abgesehen, bei denen sich das dann summiert).

@XDestroy: MFC ist auch nicht so toll wie viele behaupten... unnötiger Codemüll...

@Eddies UDDR: Wo verlahmt es denn dein System, es lässt doch gar nix laufen, während du kein .NET-Programm laufen hast. Und die .dlls sind aufgeräumt im Unterordner, sodass der Zugriff auf SYSTEM32-DLLs nur minimal verzögert wird (bei ner VB-Runtime haste Minimum 5, normalerweise >15, das müllt viel mehr zu) und eine höhere Anzahl Dateien in einem Verzeichnis wie SYSTEM32 verlahmt ein WinME-System heftig, da FAT keine sortierten Verzeichnisse hat und ME kein NTFS unterstützt (und das eine Suche in einem unsortierten Verzeichnis wesentlich länger dauert, merkste schon daran, wenn du mal nach allen Leuten, die in einer bestimmten Strasse wohnen im Telefonbuch suchst, und das dann mit der Suche nach Nachname in demselben vergleichst).

@Lofote: Wird da nicht mehr RAM benötigt oder der Systemstart verlangsamt, wennn der Systemordner um 1/10 des bisherigen Platzes zunimmmt?
Selbst unter NT 5.0 würde ich kein NTFS nutzen, da NTFS 5.0 nicht mit NT 3.51 kompatibel ist.

@Eddies UDDR: Du solltest dein Wissen wirklich mal auf den aktuellen Stand bringen. NTFS ist um Längen besser als FAT und auf NT 3.51 braucht man nun wirklich keine Rücksicht mehr zu nehmen, das gehört nun wirklich in die Mottenkiste. NTFS ist dringend zu empfehlen. PS: Mit dem Upgrade meinte ich eigentlich das Betriebssystem, Windows ME ist schon etwas angestaubt. Der einzig vernünftige Grund dafür ist wenn man sehr schwache Hardware hat und sich keine neue (auch keine Gebrauchte) leisten kann.

@Eddies UDDR: Ich verstehe Deine Argumentation nicht ganz. Du nutzt Windows Me, hast also mit NTFS derzeit eh absolut nix am Hut, willst aber kein NTFS 5.0 nutzen, weil es nicht kompatibel zu NTFS 3.51 ist. Häh?? Das ist so nach dem Motto "Ich fahre weiterhin Trabbi statt Mercedes, weil die Stoßstange eines Golf nicht an einen Mercedes passt, allerdings habe ich gar keinen Golf"

@TiKu: Ich hatte geschrieben, wenn ich Windows NT 5.0 nutzen würde statt ME, würde ich kein NTFS nutzen, da es nicht mit NT 3.51 kompatibel ist.

@Eddies UDDR: ... und genau das ist totaler Unsinn, wie dir TiKu schon zu erklären versucht hatte .

@Eddies UDDR: a) Wenn du kein WIndows 2000 installierst, bekommste auch kein NTFS 5.0, also wo ist das Problem? Wenn du unbedingt auf ein veraltetes System setzen willst, für dass es null (lies: 0) Sicherheitsupdates mehr gibt. NT 3.51 war klasse - bis NT 4.0 rauskam - das beste Windows-OS, das es gab. Aber hey, das war vor langer Zeit :)... b) Nein, das System würde nur langsamer, wenn der Systemordner SELBST mehr Dateien hätte (vor allem bei FAT, da wie gesagt nicht indexiert), aber dieser hat genau 1 EIntrag (nämlich das Unterverzeichnis Microsoft.NET) mehr. VB6Runtimes wie gesagt ca. 15. Unterverzeichnisse zählen dabei nicht, bis auf den Eintrag des Unterverzeichnis selbst.

@Lofote: Eigentlich hast du ja Recht. Nur sieht leider Windows NT 4.0 wie Windows 95 statt wie Windows 3.1 aus.

@amorosicky: naja eigentlich würde ich dir, wenn du vor langer zeit schon erfahrung damit gemacht hast, es aber eingestaubt ist, vb net empfehlen. dadurch hängst du nicht zu sehr an vb6 - der umstieg fällt dir somit umso leichter.

@amorosicky: Visual Basic 6.0 Service Pack 6 ist die aktuellste VB6-Version. Alles danach (also ab 7.0) ist Visual Basic .NET und und unterscheidet sich sehr heftig vom VB6-Code. VB .NET ist deutlich schneller als VB6-Code und du kannst wesentlich mehr mit machen, aber die Syntax ist mehr an moderne Sprachen angepasst und viel weniger Spaghetti-Code als noch VB6. Empfehlen kann ich dir aber auf keinen Fall, nochmal unter VB6 zu programmieren, da es halt nicht mehr weiterentwickelt wird. Veraltet in dem Sinne ist es nicht, aber halt zukunftslos.

@Lofote: Es gibt kein VB 7.0! VB.net ist kein Nachfolger von VB6, sondern ein Ersatz. Microsoft hatte auf der Basta 99 ein VB7 vorgestellt, das schlummert seitdem halbfertig in den Redmonder Schubladen.

@TiKu: Nunja, das Unterverzeichnis im Visual Studio .NET 2002+2003 heisst "VB7", von daher ist das ganze "Visual Basic .NET 7.0 (oder 7.1)" so falsch nicht :)... Aber wird wohl von Microsoft nicht so verkauft, genausowenig wie es offiziell kein Office 11 usw. gibt.

@Meatwad: Um die Zeit sollten Kinder in Deinem Alter im Bett liegen.

@Bobbie25: "Aber für ein kleines "Progrämmchen" zzwischendurch ist VB schon ok." *lol* Erzähl das mal den vielen Firmen, die VB6 für richtig große Projekte nutzen/genutzt haben.