Vulcan.NET

Moderator: Moderatoren

Antworten
manni1729
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 30
Registriert: Mi, 04. Jun 2008 14:18
Wohnort: Nordhessen

Vulcan.NET

Beitrag von manni1729 » Fr, 02. Okt 2009 12:11

Hallo,
hat schon jemand Erfahrungen mit ' Vulcan.NET ' gesammelt?
Wir haben haben eine große Clipper/Xbase (im Textmodus) laufende Anwendung (Videotheken Software). Jetzt sind wir am überlegen welche Richtung wir in Zukuft einschlagen.

Der 'DotNet Gedanke' ist schon reizvoll, Zugriff auf ein riesiges Framwork mit allen Möglichkeiten für die Zukunft, moderne Wege optisch ansprechende Programme zu erstellen, die Möglichkeit mit unterschiedlich Sprachen die selbe Codebasis zu benutzen,...

Da wir jetzt an der Stelle angekommen sind , wo wir uns Gedanken über eine GUI Lösung machen müssen, sind wir halt am überlegen welcher Weg langfristig der richtige ist.

Unsere Idee ist,
1. bestehender Code mit so wenig wie möglich Aufwand mit eXpress auf GUI umzustellen
2. neu Erstellung der Software auf DotNet Basis
Wobei ich Vulcan.NET einen sehr interresannten Weg finde. Nur findet man im Netzt sehr wenig Informationen dazu, deshalb meine Frage an Euch!


Gruß Manfred

Juergen
UDF-Programmierer
UDF-Programmierer
Beiträge: 92
Registriert: Di, 19. Dez 2006 19:37
Wohnort: Düsseldorf
Kontaktdaten:

Re: Vulcan.NET

Beitrag von Juergen » Fr, 02. Okt 2009 12:48

Hallo manni1729

wenn Du schon auf DotNet gehen möchtest, dann programmiere
gleich C# oder VB.NET.

Ich kenne Programmierer, die den Umweg über VO gegangen sind
und frustriert aufgegeben haben.

Ich persönlich empfehle Dir das mit eXpress umzusetzen.

Gruß

Jürgen

Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 7333
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Kontaktdaten:

Re: Vulcan.NET

Beitrag von Tom » Fr, 02. Okt 2009 13:00

Die sind bei Versionsnummer 1.0 und es ist ein Seitenprojekt von GrafxSoft, einer ziemlich kleinen Firma aus Kalifornien. Ich wage zu bezweifeln, dass damit bereits massenmarkttaugliche, datenkritische Endanwendungen machbar sind.
Herzlich,
Tom

hschmidt
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 162
Registriert: Mo, 09. Jan 2006 17:06
Wohnort: Paderborn
Kontaktdaten:

Re: Vulcan.NET

Beitrag von hschmidt » Fr, 02. Okt 2009 14:33

Hallo Manfred,

Vulcan.NET ist meines Wissens nach in erster Linie als Migrationsprodukt für Visual Objects (VO)- Programme nach .NET konzipiert. Wenn Ihr nicht bereits in VO programmiert, ist Vulcan.NET kaum zu empfehlen.
Wenn Ihr noch ganz am Anfang der Migration Eurer textbasierten Programme steht, solltet Ihr eine komplette Neuentwicklung mit einer modernen .NET-Sprache (C# mit WPF) in Erwägung ziehen.
Wir sind seinerzeit den Weg der Migration von Clipper mit Xbase++ und Express++ gegangen mit dem Hintergedanken, möglichst viel von der Clipper-Programmlogik übernehmen zu können und möglichst schnell 'releasefähige' Ergebnisse zu erziehlen. Das hat soweit auch funktioniert.
Im Nachhinein muß ich aber sagen, dass vom bestehenden Clipper-Code so gut wie nichts mehr übrig ist, fast alles musste grundlegend überarbeitet bzw. in weiten Teilen neu geschrieben werden.
Neue Programmmodule entwickeln wir jetzt nur noch in Visual Studio2008 mit C# und WPF und ich muß sagen - obwohl ich mich noch ganz am Anfang meiner Erfahrungen mit dieser Entwicklungsumgebung befinde - ist die Arbeit damit unvergleichlich besser als mit den xbase-Sprachen.

Ein weiteres wichtiges Kriterium für uns war, dass wir nicht mehr auf ein Nischenprodukt eines Miniherstellers (sowohl Grafx als auch Alaska sind sehr klein, Express ist eine OneManShow) setzen wollten, sondern uns lieber an den Mainstream halten wollten (das MS pleite geht, ist so schnell nicht zu erwarten :wink: ).

Schöne Grüsse

Hans

Alfred
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 476
Registriert: Do, 03. Mai 2007 12:37
Wohnort: München

Re: Vulcan.NET

Beitrag von Alfred » Fr, 02. Okt 2009 21:09

Hallo Manfred,

die .Net Geschichte hat einige entscheidende Hacken.

Ich kann dir nur empfehlen eine einfache Anwendung damit zu erstellen und du wirst erkennen,
dass man für professionelle Programmierung einen sehr hohen Aufwand betreiben muss und
Zusatzpakete richtig Geld kosten(z.B. ein anständiges Datagrid(z.B. DevExpress)).

Die Tatsache, dass man sich Daten vom Server holt und dann die Verbindung gekappt wird
und nach der Bearbeitung erst wieder in den Datenbestand eingespielt wird und man sich
selbst um die damit verbundenen Problem kümmern muss, hat mich dazu veranlasst dieses
Produkt und die vielen Stunden die ich da hinein gesteckt habe in die Tonne zu treten.

Schau dir mal einen aktuellen Rechner an, mit wieviel verschiedenen Frameworks die heute
bereits zugeplastert sind.

Gruß
Alfred

Juergen
UDF-Programmierer
UDF-Programmierer
Beiträge: 92
Registriert: Di, 19. Dez 2006 19:37
Wohnort: Düsseldorf
Kontaktdaten:

Re: Vulcan.NET

Beitrag von Juergen » Fr, 02. Okt 2009 22:51

Hallo,

OK, selbst wenn Alaska in 2 oder 3 Jahren nicht mehr existiert.
eXpress++ liegt zudem noch im Quellcode vor.

Ob in 2 oder 3 Jahren .NET noch unterstützt wird ?
Ich denke da nur an die Foxpro-User.

Da nützt der beste Main-Stream nichts.

Gruß
Jürgen

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11515
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Vulcan.NET

Beitrag von AUGE_OHR » Sa, 03. Okt 2009 3:23

Juergen hat geschrieben:OK, selbst wenn Alaska in 2 oder 3 Jahren nicht mehr existiert.
es gibt ja auch "andere" Compiler die "pure" Xbase++ Code "verstehen"...
Juergen hat geschrieben:eXpress++ liegt zudem noch im Quellcode vor.
hat jemand schon mal versucht den "Source" von Express++ durch einen "anderen" Compiler zu jagen ;)
Juergen hat geschrieben:Ob in 2 oder 3 Jahren .NET noch unterstützt wird ?
sicherlich haben wir dann was "neues", aber die Frage ist doch : "Was" erwartest du von .NET ???
Juergen hat geschrieben:Unsere Idee ist,
1. bestehender Code mit so wenig wie möglich Aufwand mit eXpress auf GUI umzustellen
2. neu Erstellung der Software auf DotNet Basis
Ich "denke" du hast noch keinen Plan wie "mächtig" Xbase++ ist.

mit Express++ hast du doch ein "Werkzeug" mit dem du die GUI "Masken" erstellen kannst, die "Logik" kannst du ja übernehmen.
Du wirst sehr schnell merken das das erstellen von GUI "Masken" den grössten Teil deiner Arbeit ausmachen wird.

Wenn du das nun alles zusammen hast, kannst du dir Gedanken über 3PP Tools machen um das ganze "schöner" zu machen.
Für Express++ gibt es das nun XCodejock womit du, per Framework, jedes Theme als Style benutzen kannst.

Die Codejock activeX sind nun IMHO in MFC / MPC geschrieben und damit 3D fähig wenn man ein DX9 fähiges OS() wie Win7 benutzt.

.Net ist im Prinzip auch "nur" eine 3PP Lib, aber du müsstest ja eine "Verbindung" schaffen : den "Wrapper".
genau sowas ist nun XCodejock für Express++ womit du mit "normalen" Express++ Befehlen die 3PP Tools (*.OCX) ansprechen kannst.

p.s. in der Wissensbasis gibt es die HX_Class welche, wie XCodejock, einen "Wrapper" für die Codejock activeX bereit stellt.
Diese Version ist "pure" Xbase++ und ab v1.9x zu verwenden.
gruss by OHR
Jimmy

Juergen
UDF-Programmierer
UDF-Programmierer
Beiträge: 92
Registriert: Di, 19. Dez 2006 19:37
Wohnort: Düsseldorf
Kontaktdaten:

Re: Vulcan.NET

Beitrag von Juergen » Sa, 03. Okt 2009 12:58

Hallo Jimmy,

du hast recht. Ich arbeite seit 2000 mit eXpress++ .

Unsere Idee ist,
1. bestehender Code mit so wenig wie möglich Aufwand mit eXpress auf GUI umzustellen
2. neu Erstellung der Software auf DotNet Basis

Das hat "manni1729" geschrieben.

Gruß

Jürgen

Benutzeravatar
Armin
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 374
Registriert: Mo, 26. Sep 2005 12:09
Wohnort: 75331 Engelsbrand
Kontaktdaten:

Re: Vulcan.NET

Beitrag von Armin » Mo, 05. Okt 2009 16:02

Hallo Manfred,

wieso dann nicht gleich HTML-Web? Mit Alaska WAA kannst Du den Verarbeitungscode von Clipper weiterhin benutzen. Die Ein/ Ausgabe geschieht im Browser, die Masken (Templates) können vorgestylt werden. Du brauchst noch ein bisschen Javascript (Ajax).
Dann kann man auf den Windows-Frame-Work-Ballast verzichten. Für´s Web gibt´s viele Dinge wie z.B. Kalender, Spaltensortierungen, Texteditoren usw. kostenfrei. Und der Client ist ab sofort betriebssystemunabhängig...

Außerdem habe ich schon viele große Firmen ziemlich schnell verschwinden sehen. Naja, mit Windows7 wird´s bei MS wahrscheinlich erst mal wieder boomen.

Grüße aus der Webecke, Armin

VulcanDC
Rookie
Rookie
Beiträge: 4
Registriert: Fr, 23. Jul 2010 13:25

Re: Vulcan.NET

Beitrag von VulcanDC » Fr, 23. Jul 2010 14:43

Hallo alle,
hier ein paar Richtigstellungen zu Vulcan.NET bzw .NET allgemein:
Vulcan.NET ist kein 'Seitenprodukt' sondern das Hauptprodukt von GrafX. GrafX ist eine Firma in Florida. Die Entwicklungsumgebung ist Visual Studio (wer kein eignes VS hat, kann eine reduzierte Version von GrafX bekommen, das entspricht dann etwa im Leistungsumfang den Express-Versionen von C# und Vb.NET, nur eben dass Vulcan.NET jetzt in VS integriert ist). Auf die Weise profitiert jeder Vulcan-User von Änderungen, die MS an Visual Studio vornimmt, ohne dass es GrafX Manpower kostet.

Zur Aussage 'marktfähige Anwendungen':
  • auf http://www.govulcan.net kann sind ein paar Anwendungen vorgestellt
  • VIDE ist eine sehr populäre Entwicklungsumgebung, die komplett in Vulcan.NET geschrieben ist (die kann man sich auch von govulcan.NET downloaden). Ich habe schon vor 4 Jahren mit Vulcan und VIDE gearbeitet. Das zeigt, dass man schon vor 4 jahren leistungsfähige Anwendungen in Vulcan schreiben konnte.
  • Ich selbst hab 3 1/2 Jahre für eine große US-Firma mit 12 Niederlassungen in Europa und ein paar 1000 Mitarbeitern Programme in Vulcan.NET geschrieben. Die Programme sind alle europaweit im Einsatz: Programme für Aussendienstler, Management-Informationssystem, IT-unterstützende Programme
Und noch ein Mißverständnis zu Ado.NET (hat also nur indirekt mit Vulcan.NET zu tun, weil man mit Vulcan.NET auch Ado.NET nutzen kann):
Es ist richtig, dass Ado.NET im 'disconnected' Modus arbeitet. Solange keine Daten zwischen Server (Datenhaltung kann in SQL DBMS, MDB oder auch DBFs sein) hin oder her bewegt werden, kann die Verbindung geschlossen werden. Diese 'schläft' dann aber in einem Connection-Pool und wird bei einem neuen Open() nur reaktiviert, d.h. die Verbindung steht schneller als beim ersten Mal (ist vor allem bei Web-Anwendungen wichtig). Die Client-Anwendung buffert die Daten (in einem DataSet) und weiss über alle Änderungszustände (RowStatus) Bescheid, so daß ein Update() an den Server weiss, welche Änderungen (incl. neue Sätze, gelöschte Sätze) weggeschrieben werden müssen. Das allermeiste geht automatisch, und doch kann man über alles auch im Code die Kontrolle behalten (wenn man sich die Arbeit machen will). Man kann auch Connection-Pooling ausschalten bzw. den Pool kontrollieren (ClearPool() und ClearAllPool())

Es gibt seit Jahren eine Vulcan-Konferenz in Deutschland.

Bin für Fragen zu Vulcan immer offen.

Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 7333
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Kontaktdaten:

Re: Vulcan.NET

Beitrag von Tom » Fr, 23. Jul 2010 15:02

Hallo, VulcanDC (DC steht vermutlich für Dieter Crispien).

Der Fairness halber solltest Du noch erwähnen, dass Du der deutsche Disti für Vulcan bist. :wink:
Zur Aussage 'marktfähige Anwendungen': auf http://www.govulcan.net kann sind ein paar Anwendungen vorgestellt
Da ist man doch glatt versucht, ein paar Screenshots aus der eigenen App als Gegenüberstellung anzubieten. :badgrin:
Herzlich,
Tom

Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 13142
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Kontaktdaten:

Re: Vulcan.NET

Beitrag von Jan » Fr, 23. Jul 2010 15:34

Ich kann es mir einfach nicht verkneifen, da ein paar Sachen zu zu sagen.

- Zugegeben, ich kenne ich mit .Net nicht wirklich aus. Aber nach dem Vortrag über .Net, den der hochdekorierte MVP auf dem letzten XXP-Treffen in den Niederlanden gehalten hat, werde ich nie und nimmer zu .Net wechseln. Egal ob mit C# oder Vulcan.Net oder sonst irgend eine .Net-Sprache. Die leichte Dekompilierbarkeit der .Net-Programme und der enorme Entwicklungsaufwand (gegenüber Xbase++) sind für mich absolute KO-Kriterien. Abgesehen davon: Was nützt es mir, das .Net 46.000 Klassen bietet wenn ich erstmal einen Pfadfinder brauche um die zu finden, die ich wirklich brauche?

- Wenn ich mir die News auf Dieters Seite ansehe, dann sind wir mit Xbase++ ja noch richtig gut dran. Die letzte VO-Version wurde 2006 angekündigt, die letzte Ankündigung auf www.vulcandotnet.de steht auf 2007. Leute, regt Euch nicht mehr auf, das Arctica 2 Jahre dauert :lol:

- Tom sprach die Screenshots an. Also ehrlich, es ist toll, das man mit Vulcan.Net so (optisch)= schöne Programme schreiben kann. Das ist zumindest schon mal ein Pluspunkt, das geht mit so mancher anderen xBase-Sprachen nicht. Und das so große Applikationen damit geschrieben wurden, ist natürlich beeindruckend. Aber mit Xbase++ wurden ebenfalls immense Programmpakete geschrieben. Ich erinnere nur an Deutsche Post und Yellow Cabs. Und auch einige optisch sehr ansprechende Oberflächen.

Es ist gut zu erfahren, was auf der anderen Seite des Zaunes geschieht. Und über mögliche Alternativen zu erfahren. Die es für Xbase++-Entwickler natürlich gibt. Siehe Harbour, WinDev, Fivewin, Flagship, dBASE (ja, das gibt es immer noch), Visual Foxpro (OK, die nicht mehr so wirklich), oder eben auch VO oder Vulcan.Net. Aber man muß deswegen ja nicht immer gleich zu jemandem anderen wechseln, nur weil der gerade moderne Schlagwörter in den Raum wirft.

Wer mich gut genug kennt weiß, wie ich das meine.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.

VulcanDC
Rookie
Rookie
Beiträge: 4
Registriert: Fr, 23. Jul 2010 13:25

Re: Vulcan.NET

Beitrag von VulcanDC » Fr, 23. Jul 2010 19:25

Hallo Tom,
Der Fairness halber solltest Du noch erwähnen, dass Du der deutsche Disti für Vulcan bist.
Kein Problem damit. Dann füg ich auch gleich der Fairness halber zu, dass ich der Veranstalter der jährlichen Vulcan.NET Konferenz bin. Und dass ich in Sachen Vulcan.NET europaweit Firmen unterstütze (könnte durchaus auch bei einer Portierung von Xbase++ Anwendungen nach Vulcan sein, obwohl ich zugeben muss, dass ich nie in Xbase++ entwickelt habe)

Screenshots sind nur die halbe Sache. Was da hinter steckt ist meistens viel wichtiger und wird auch in erster Linie vom Kunden bezahlt.

Grüße
DC

VulcanDC
Rookie
Rookie
Beiträge: 4
Registriert: Fr, 23. Jul 2010 13:25

Re: Vulcan.NET

Beitrag von VulcanDC » Fr, 23. Jul 2010 19:58

Hallo Jan,
Die leichte Dekompilierbarkeit der .Net-Programme ....
Lies doch mal nach was es unter dem Stichwort Obfuscator unter Google gibt. Nimm mal einen der freien Obfuscator (z.B. Dotfuscator Community Edition). Kannst du auf C#, Vulcan.NET oder jede andere .NET-Sprache anwenden (Wenn du kein C# Express hast, kann ich gerne den Code vorher und nachher hier posten). Und dann schau dir das Ergebnis mit Reflector (kostenloser Decompiler). Und dann erzähl mir, was du mit dem Code anfangen kannst. Übrigens, gab es auch für Clipper Decompiler (Valkyrie u.a.). Die haben aber keinen Clipperer abgeschreckt.
... und der enorme Entwicklungsaufwand (gegenüber Xbase++) sind für mich absolute KO-Kriterien.
was findest du denn so enorm aufwendig? VS zu lernen? Ist natürlich am Anfang sehr viel, weil sehr mächtig. Genau deshalb gibt es für Vulcan.NET die VIDE. Für kleinere Projekte auf jeden Fall ideal und alles sehr intuitiv erlernbar, was bei MS ja oft nicht der Fall ist. Von dem VS Designer hab ich jedenfalls noch nie jemanden gehört, der sagt 'aufwendig' (eher schon im Gegenteil). Und viel mehr brauchst du am Anfang auch nicht, zumindest bei kleineren Projekten. Der Sourcecode Editor ist voll mit Intellisense. Jeder will da nie mehr zurück zu einem Editor ohne Intellisense (BTW, die VIDE hat ebenfalls jede Menge Intellisense). Also erzähl mal, was da so aufwendig ist.
Abgesehen davon: Was nützt es mir, das .Net 46.000 Klassen bietet wenn ich erstmal einen Pfadfinder brauche um die zu finden, die ich wirklich brauche?
Ein gutes Buch über .NET und ein gutes Forum. Von beidem gibt es Hunderte.


Die Seiten zu Visual Objects und Vulcan.NET sind deshalb zurückgeblieben, weil ich so stark in Vulcan.Net engagiert war. Das letzte Update zu Visual Objects stammt vom Herbst 2009 (VO 2.8 Service Pack 3). Das letzte Update zu Vulcan.NET stammt vom 14.07.10 (Version 2.0)


Wenn dir ein paar Begriffe aus der .NET-Welt, die ich hier verwende, nix sagen, kannst du gerne fragen. Es geht ja vielleicht anderen auch so.

Grüße
DC

Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 13142
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Kontaktdaten:

Re: Vulcan.NET

Beitrag von Jan » Fr, 23. Jul 2010 20:41

Hallo DC,

Obfuscatoren sind ja soweit eine ganz nette Sache. Aber die verschleiern (soweit ich weiß) nur die Variablen und internen Methoden, nicht aber bei öffentlichen. Wie gesagt, ich kenne mich mit .Net nicht sehr gut aus. Aber ich habe mir sagen lassen, daß man .Net-Programme auch von MS-seitigen Vorgaben gegen das einfache dekompilieren schützen kann, nur sind die dann nicht mehr übergreifend zu verwenden. Also für jede 32- und 64-Bit Version von jeder Windows-Version ein eigenes .Net-Programm. Was dann wieder auch nicht der Sinn der Sache ist. Und das Obfuscatoren da rein von der Code-Logik nicht wirklich etwas gegen dekompilieren tun können.

Abgesehen davon bedeutet dekompilieren von .Net-Programmen, daß man hinterher klaren C#-Code hat. Bei Clipper war das schon wesentlich komplizierter. Klar ist es so, das man alles dekompilieren kann, wenn man will und entsprechenden Aufwand dahintersteckt. Fragt sich nur, wie einfach das ist und wie leicht der Code hinterher verständlich ist. Und das ist bei .Net eben extrem übersichtlich. Ich habe Codevergleiche gesehen, es war erschreckend wie sehr sich Originalcode und dekompilierter Code nach dem Reflector-Durchlauf ähnelten.

Zum Entwicklungsaufwand: Ich meine damit nicht das Umlernen oder die Lernkurve. Während des Vortrages hatten wir auch ein wenig begleitende Diskussion. Und ein anderer Xbase++-Entwickler wußte zu berichten, das ein Wettbewerber für ein ähnliches Programm mit ähnlichem Funktionsumfang wie seines 15 .Net-Entwickler benötigt, er selber aber mit 3 Xbase++-Entwicklern auskommt. Dieses 1:5-Verhältnis für den Entwicklungsaufwand zwischen Xbase++- und .Net-Programmen wurde mir später auch von anderen Entwicklern bestätigt.

Wie gesagt, das war ein Vortrag eines langjährigen, hochdekorierten MVP. Er mußte leider beide Punket eingestehen - die leichte Dekompilierbarkeit der .Net-Programme und der relativ hohe Entwicklungsaufwand (vergleichen mit Xbase++). Ich muß in diesen Fragen ihm vertrauen, mir fehlen dafür schlichtweg die persönlichen Erfahrungen. Aber wenn so ein MVP das sagt, dann glaube ich ihm das mal. Und wenn er sagt, das die einfache Dekompilierbarkeit von .Net-Programmen genau der Grund ist, warum MS sein eigenes Office noch nicht komplett auf .Net umgeschrieben hat, und den Core auch nie umschreiben wird, dann ist das für mich halt ein enorm gewichtiges Argument.

Ich möchte damit nicht .Net komplett schlecht reden. Es gibt sicher massiv gute Anwendungsbereiche, wo man das für verwenden kann. Und Millionen von Entwicklern können sich nicht soooo sehr irren, auch wenn viele das eher aus Hype-Gründen nutzen und nicht, weil es für ihre Fälle die beste Sprache ist. Aber für einen gestanden Xbase++-Entwickler anscheinend eher weniger.

Jan


Nachtrag: Gerade habe ich zum Thema Sinn von Obfuscatoren noch diesen Artikel gefunden: http://msdn.microsoft.com/de-de/library/bb979521.aspx Und wenn der schon im MSN steht, dann darf das ja wohl nicht so ganz falsch sein, was darin steht.
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.

Benutzeravatar
azzo
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 268
Registriert: So, 28. Mär 2010 19:21

Re: Vulcan.NET

Beitrag von azzo » Sa, 24. Jul 2010 0:02

Ich habe vor einigen Jahren meine gesamten Produkte von Clipper/FW auf VB.NET umgeschrieben(VS2003/2005/2008) .
Auch die Internet Sachen habe ich auf ASP.NET umgestellt.

Bin nun aber froh, dass ich wieder zurück in der dBase Gemeinde bin (HARBOUR/FWH) und im Internet bei ASP ohne Net.

Ich bin überzeugt, dass es für eine kleine Entwicklerfirma nicht möglich ist mit VB.NET langfristig erfolgreich zu entwickeln.
Es gibt für jedes und alles 100 Möglichkeiten und leider nimmt man auch jede Menge 3rd Party mit auf. Die Kosten die Alfred angesprochen hat sind noch das wenigste.
Schwerwiegender ist der Lernaufwand. Praktisch hat jede Komponente einen Assistenten mit im Lieferumfang mit Features, wie man sie vielleicht von WINWORD kennt. Wenn man damit nicht gut umgehen kann nützen auch die besten visuellen Designer wenig. Bei Feinheiten muss man trotzdem Eingriffe im Code vornehmen.

Auch bei der Internetsuche erschlägt einen die hohe Trefferanzahl. Man bekommt praktisch für jede Frage etliche 100 Treffer, die man dann vorsichtshalber durchschaut und so viel Zeit verliert. Ich glaube diese mächtigen Sprachen eignen sich sehr gut für größere Teams wenige aber für Selbständige.

Der Entschluss, dass ich mit VB.Net aufhören muss kam bei mir, als ich wieder einmal eine Ankündigung von einem der vielen Komponentenhersteller gelesen habe, dass im neuen Update 80 neue Features sind. Hierbei handelte es sich aber nur um ein DataGrid, das ich eingebunden habe.
Sehr viel ist auch Marketing. Als ich mit VB anfing war DAO dann ADO dann ADODB und immer war es das beste Datenzugriffskonzept. Immer von Grund auf alles neu.

Seit 1995 habe ich die Windowsversion (CLIPPER/FW) meines Programms und große Teile des Codes sind seit damals unverändert auch im Quellcode der aktuellen Version im Einsatz.

Meine VB6 Sachen oder VB.NET 2003 Sachen, die ich für den PocketPC gemacht habe, sind praktisch wertlos und müssen komplett neu entwickelt werden.
(Investitionsschutz!)

Gruß
Otto

VulcanDC
Rookie
Rookie
Beiträge: 4
Registriert: Fr, 23. Jul 2010 13:25

Re: Vulcan.NET

Beitrag von VulcanDC » Mo, 02. Aug 2010 2:42

Hallo Jan,
zu den Obfuscators kursieren ja viele Gerüchte. Und umso tiefer der Schock sitzt, umso ausgewachsener die Gerüchte. Leider gibt auch unter MVP leider manche, die lieber irgendetwas erzählen, bevor sie sagen "Da kenne ich mich auch nicht so gut aus".
Deine Sorgen bzgl. Quelltextschutz sind natürlich nachvollziehbar und berechtigt, d.h. man muss sich schon ein Bewußtsein erarbeiten, wo man icht einfach naiv un-obfuskiert seine Programme verbreitet. Ein Artikel, den ich besonders gut finde steht hier: http://www.yoda.arachsys.com/csharp/obfuscation.html. Er plädiert dafür, dass man nicht hypersensibel reagiert und auch keineswegs sorglos.
Obfuscators können nicht erst heutzutage mehr als du beschreibtst. Lies mal nach, was Xenocode .Net Obfuscator 2010 alles kann: http://www.xenocode.com/obfuscator/: unter anderem kann dieser Obfuscator .Net-Anwendungen in native Binaries umwandeln, die sogar ohne das .NET Framework laufen (was eigentlich nur noch auf Windows-Versionen Sinn macht, die älter als Vista sind).
Und dann noch eins zur Leistungsfähigkeit von Obfuscators: Schau dir mal den folgenden Code an. Du musst schon verdammt viel Zeit und kriminelle Energie haben, um das zu entschlüsselm (auch mit Reflektor!):

Code: Alles auswählen

using O111; using O111.l1000; using System; using System.Collections; using
System.l1001; using System.l1010; using System.Text; public class l1011 {
public string l1100; public int l1101; public l1011(string l1011) { l1100 =
O1110(l1011); } public int O1111 { get { if (l1101 == 0) return 1; if (l1101
== 1 && l1100 == "v\u006F\u0069\u0064") return 012; return 3; } } public bool
O10000 { get { return l1101 == 0 && l1100 == "\u0076oid"; } } public string
O10001(int O10010, bool O10011, bool l10100) { if (l1101 == 0) return l1100;
if (O10010 == 0) return l1100+l10101(l10100 ? '\u0050' : '\u002A'); if (l1101
> 1 || O10011 || O10010 == 1) return "\u0049n\u0074\u0050\u0074\u0072"; if (
l1100 == "\u0076o\u0069d") switch (O10010) { case 2 : return "b\u0079\u0074\
u0065[\u005D"; case 3 : return "sbyte\u005B]"; case 4 : return "\u0073\u0068\
u006Fr\u0074[]"; case 5 : return "\u0075\u0073h\u006Fr\u0074\u005B]"; case
6 : return "\u0069\u006E\u0074[\u005D"; case 7 : return "\u0075int[]"; case
8 : return "\u0066\u006C\u006Fa\u0074[]"; case 011 : return "d\u006Fu\u0062\
Der obfuskierte Code stammt von http://www.semdesigns.com/products/obfu ... ample.html, dort kannst du auch den Originalquelltext sehen. Aber nur so nebenbei: Hast du mal wie ich in einem Projekt gearbeitet, wo du die ganzen 30 MB Quelltext hast, keine Dokumentation, alle 100 Zeilen mal ein halbzeiliger Kommentar in einer Sprache, die du nicht kennst, und alle Variablennamen in derselben Sprache. Da nützt dir auch kein Decompiler, ausser du bist einverstanden für einen Lohn von weit unter 1Euro zu arbeiten.
Entwicklungsaufwand 5* so hoch: Mach dir doch nichts vor, bei 15 Entwicklern steigt der Projektverwaltungsaufwand exponentiell gegenüber 3 Entwicklern. Ich bezweifle, dass alle 15 Vollzeit-Angestellte waren, wahrscheinlich ein Drittel Studenten, die gelegentlich mal mitgearbeitet haben. Ist die Feature-Liste wirklich identlich? Meistens ist die bei .NET-Anwendungen um Einiges aufwendiger, ich meine was die Leistungen betrifft, nicht was den Aufwand betrifft, einen gleichen Leistungsumfang zu realisieren. .NET-Anfänger müssen in der Tat einiges lernen, denn die Klasen sind wirklich umfangreich. Aber der Aufwand zahlt sich bald aus, auch wenn man gleichzeitig neu den Umgang mit VS lernen will (was man übrigens bei Vulcan vertagen kann, weil es VIDE gibt).

Was MS-Office angeht, gehe ich davon aus, dass es wahrscheinlich in C++/CLI, die .Net-kompatible Variante von C++ nachprogrammiert wird, die aber erlaubt, gleich native Binaries zu entwickeln. So wie es auch bei C# schon ist und bei VS 2010 sein wird. Übrigens, der Projektleiter von VS2010 hat geschrieben, dass es mindestens 4 Jahre dauern wird, bis es VS voll in managed code (64-Bit) geben wird - weil es einfach Tonnen von Quelltext sind.

Grüße
DC

PS: zu dem anderen Beitrag evtl. morgen

Antworten