Re: VB classic petition

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Herfried K. Wagner [MVP] (hirf-spam-me-here_at_gmx.at)
Date: 03/13/05 

Date: Sun, 13 Mar 2005 14:04:00 +0100

Hallo Thorsten!

"Thorsten Dörfler" <t.doerfler_nospam@bdsw.de> schrieb:
>>> VB6 fusst in seinem Gesamtbild auf COM und ist damit
>>> stark abhängig von COM und der Zukunft von COM. Also, am Ende seines
>>> Entwicklungszweigs angelangt ist.
>>
>> VB gab's schon in prä-COM-Zeiten, d.h. VB ist nicht extra auf COM
>> zugeschnitten, sondern wurde an COM angepasst.
>
> Stimmt. Dieser Verdrahtung mit COM hat VB erst mit VB4-32 erfahren.
> Ironischerweise Code kompatibel zu VB3.

Eben. Bibliotheken und Technologien mögen sich im Laufe der Zeit ändern,
aber die eigentliche Sprache /kann/ kompatibel beibehalten/erweitert werden.
Es ist ja schon fast ironisch, dass Microsoft beim Entwurf von VB.NET
versucht hat, diese Kompatibilität zu brechen (vgl. 'Wend' -> 'End While',
'Property' etc.), wo es nur geht und wo ein Bruch nicht begründbar ist.

>> Selbstverständlich könnte
>> Microsoft, wenn es denn willens wäre, ein kompatibles VB7 entwickeln
>
> Gab es nicht das Gerücht, dass ein nahezu fertiges VB7 (VB.COM) in
> irgendwelchen Redmonder Schubladen gammelt?

Das gibt es...

>> Selbst wenn COM tot ist
>
> Tot <> Weiterentwickelt. Legacy Kompatibilitäts-Support wird es ja
> weiterhin geben. Mit der Option als potenziell "gefährlich" eingestuft
> zu werden.

Stimmt. Ganz tot ist COM tatsächlich nicht, genau das wollte ich ja mit den
Beispielen von Longhorn-Technologien für COM ausdrücken. Trotzdem wird .NET
als "das einzig Wahre"(TM) angesehen.

>> warum werden dann Longhorn-Technologien für COM
>> verfügbar gemacht? Es muss also doch Programmiersprachen geben, in denen
>> es
>> akzeptiert wird, dass sie nicht auf .NET basieren. Sonst bräuchte man
>> diese
>> für COM ansprechbaren Schnittstellen nicht :-/.
>
> Weil in Longhorn selber noch viel Legacy COM Krempel laufen wird. Oder
> meinst Du LH erhält einen von Grund auf neuen Explorer? Ein neues
> Modell für Shell-Erweiterungen, das das aktuelle obsolet macht? Ließe
> sich beim MediaPlayer, IE, OjE etc. pp. fortsetzen. MSFT wird diese
> Anwendungen in LH nicht neu schreiben, sondern erweitern und will
> natürlich LH Goodies ebenso nutzen.

Eben, das meinte ich. Das, was Microsoft selbst tut, wird VB6-Entwicklern
dadurch verwehrt, dass VB6 2008 überhaupt nicht mehr unterstützt wird (von
Sonderverträgen mit Microsoft abgesehen).

>> Weil es mir gerade ins Auge sticht:
>>
>> Visual FoxPro 8.0 -- Upgrading from Earlier Versions
>> <URL:http://msdn.microsoft.com/library/en-us/dv_foxhelp/html/igUpgrading_from_Earlier_Versions.asp>
>>
>> ---
>> Microsoft Visual FoxPro protects your investment in applications built
>> with
>> previous versions of FoxPro. In Visual FoxPro, you can run many
>> applications
>> that were written in earlier versions with little or no conversion. You
>> can
>> modify and enhance applications using the Visual FoxPro language, knowing
>> that most extensions to the language do not affect backward
>> compatibility.
>> ---
>>
>> Wenn man das nur über VB sagen könnte... :-(.
>
> Mich würden mal repräsentative Statistiken interessieren, wie die
> Verteilung VB.classig -> VFP -> VB.NET -> .NET allgemein aussschaut
> (nein, ich meine nicht die Zahlen, für die keiner eine Quelle nennen
> kann).

Was meinst du denn dann ;-)?

> Mich würde allerdings noch mehr interessieren, was MSFT geritten hat,
> ein solch inkompatibles VB.NET abzusegnen? Es wäre doch ein vielfaches
> Attraktiver gewesen, ich könnte meine VB.classic Sourcen in VB.NET
> öffnen, kompilieren und fertig ist meine erste .NET App. Kaum einer
> würde heute mehr nach VB6 oder einem VB.COM krähen.

Das Frage ich mich ebenfalls. Warum musste Code (absichtlich?) inkompatibel
gemacht werden? Jetzt ist es zu spät, ein VB6.NET wird es nie geben, da es
ja bereits VB.NET gibt und zwei VBs /für .NET/ zueinander in Konkurrenz
stehen würden.

>>> VB.NET fusst dagegen auf .NET und ist damit genauso abhängig von der
>>> zugrunde liegenden Technik, wie es VB6 war. Ergo: VB war nie eine
>>> eigenständige Entwicklungsumgebung (um es nicht speziell Sprache zu
>>> nennen), ist es aktuell nicht und wird es auch in Zukunft nicht sein.
>>
>> Demzufolge, und das prophezeie ich bereits seit Längerem, werden in
>> einigen
>> Jahren diejenigen, die jetzt (statt C/C++) nur auf C# setzen, ein
>> ähnliches
>> Schicksal erleiden
>
> Sicher. C# ohne Framework, ist wie C ohne C.

*Sekt kaltstell*

>>> C/C++ dagegen ist es herzlich egal, mit welcher Technologie man
>>> arbeitet. C/C++ macht jeden Technologiesprung mit. Den Rest richtet
>>> der Compiler.
>>
>> Das könnte wohl auch bei VB der Fall sein.
>
> Könnte es sicher. Ist aber nicht das Ziel des MSFT Marketing.

Microsoft sieht VB, im Gegensatz zu C++, viel zu sehr als "Produkt", das
nach belieben geändert werden kann. Dass mit VB, gleich wie mit C++, Kapital
in Form von damit erstellten Daten (Code) gebunden werden kann, scheint sich
der Kenntnis von Microsoft zu entziehen oder mehr oder weniger gleichgültig
zu sein.

> Letztlich alles eine Frage des Sprachkern, der Runtime und des
> Compilers. Einfacher ist es natürlich, wenn man den Sprachkern auf
> eine bestehende Komponenten-Technik aufsetzen kann. Ansonsten müsste
> VB diese ja nochmal selber implementieren (was es ja in Teilen macht).

ACK.

>>> Tja und FoxPro? Keine Ahnung, aber ist das nicht 'ne Datenbank? Im
>>> .NET Korsett würde diese doch wohl komplett an Bedeutung verlieren.
>>
>> Visual FoxPro ist vom Aufbau her ähnlich wie .NET. Es ist gewissermassen
>> eine "Parallelwelt". VFP ist mehr als eine einfache Datenbank, es ist ein
>> objektorientiertes DBMS, mit dem Anwendungen erstellt werden können.
>> Wenig
>> Bedarf nach .NET.
>
> Also, interessanter wäre eher das oo DBMS in .NET, das mit einer
> beliebigen Sprache gefahren werden kann. So könnte man VFP absägen.
> Aber entweder ist die Userbase stärker oder aber die Technologie
> interessanter für MSFT.

Ich nehme an, dass die Visual FoxPro-Benutzergemeinschaft wesentlich
grösseren Einfluss auf Microsoft hat, als dies bei der VB-Gemeinschaft der
Fall ist. Das, was heute Visual FoxPro heisst, stammt ursprünglich nicht von
Microsoft... 

-- 
 M S   Herfried K. Wagner
M V P  <URL:http://dotnet.mvps.org/>
 V B   <URL:http://classicvb.org/petition/>

Relevant Pages

  • Re: VB classic petition
    ... >> damit COM eine Technologie ist, deren Weiterentwicklung nicht mehr ... VB6 fusst in seinem Gesamtbild auf COM und ist damit ... Es würde unter .NET an Bedeutung verlieren. ... In Visual FoxPro, ...
    (microsoft.public.de.vb)
  • Re: ProzessorID
    ... die zwar von .NET Wrappern ... COM ist auslaufware, das ist klar und COM war ... Es gibt einige Programme, die bestehen fast nur aus COM ... Microsoft Live Space: http://kerem-g.spaces.live.com/ ...
    (microsoft.public.de.german.entwickler.dotnet.csharp)
  • Re: Windows Forms sind eine Sackgasse
    ... Was meine VB6 Anwemdung ... von VB6 auf .NET zu migrieren, dabei aber in den einzelnen Tests immer ... - wo liegen die größten Probleme bei der Migration ... Microsoft vom Server zum Client migriert. ...
    (microsoft.public.de.german.entwickler.dotnet.vb)
  • Re: Usando VOIP com varios provedores
    ... A ideia de usar um soft de Microsoft me da nojo. ... Sempre me da vontade de rir quando Bill Gates chega na cena, anos tarde e com uma solucao sempre inferior. ... Ele descobriu o VOIP so agora? ... que tem como objetivo simplificar contatos entre ...
    (soc.culture.brazil)
  • Re: ActiveX/COM mit .NET
    ... [COM Integration] ... The COM Interop works in both directions; the .NET Interop system acts as a gateway between .NET components and COM Components, it makes the COM component look like .NET component and a .NET component look like a COM component. ... In building a .NET component intended to be accessed from COM, we simply check the Register for COM Interop checkbox on the project setting dialogue box (setting the Register for COM interop option to True will create a type library and make the correct registry entries for you.). ...
    (microsoft.public.de.german.entwickler.dotnet.csharp)