Re: [VB?] & Java ...

Hallo Olaf! Sorry für die Verspätung, aber hier gäbe es viel zu antworten und ich hatte die letzten Tage andere Prioritäten ;-)

Ok, nun inline meine Kommentare. Ich werde mich aber kurz halten.

Schmidt schrieb:
"Ulrich Korndoerfer" <ulrich_wants_nospam@xxxxxxxxxxxx> schrieb im
Newsbeitrag news:uIfzSV0UJHA.964@xxxxxxxxxxxxxxxxxxxxxxx

Das wäre doch was für Olaf: da gibts also bereits eine IDE, die
offensichtlich VB Classic Code parsen kann, Intellisense hat, einen
Editor, einen Formgenerator etc pp.. Jabaco erzeugt dann zwar
Java-Bytecode, aber Olaf könnte ja alles außerhalb der Codeerzeugung
nutzen. Der Autor Manuel Siekmann bzw. dessen Firma www.makasy.com
sitzt übrigens gleich bei mir um die Ecke, in Erlangen / Oberfranken /
Bayern
/ Deutschland.

Dass die IDE (und wahrsch./vielleicht auch der Java-ByteCode-
Compiler) in VB implementiert sind, ist natürlich äusserst interessant.


Ich seh auf die Schnelle nichts außer Jabaco.exe, was den Bytecode erzeugen könnte. Jabaco.jar scheint die "Runtime" zu enthalten.

Genau den Weg wollte ich die nächsten Jahre ja ebenfalls gehen
(erstmal eine in VB6 implementierte IDE-Umgebung schaffen,
die danach dann relativ einfach in den "selfhosting Status"
überführbar sein sollte, gesetzt den Fall, der neue VB->C-
Compiler verhält sich bei VB6-Source-Input nahezu kompatibel.

Vielleicht mal zum besseren Verständnis all des "Schmidtschen
Geschwafels" in meinen letzten Postings - meine "persönliche
RoadMap" bzgl. Migration VB6-SourceCode zu "fully
unmanaged C/C++" (die dann in den weiteren Schritten auch
irgendwo gerne auf die Unterstützung der Community zählen
würde).

Da wäre zunächst die dhRichClient.dll, die demnächst in
neuer Version 3.0 erscheinen wird - Binary wie immer
Public Domain ... Sourcen (noch) geschlossen - alle
Klassen regfree benutzbar usw.


Da fällt mir ein: wäre es nicht langsam Zeit, die Dll in www.thecommon.net zu integrieren? Und DirectCOM.dll könnte mal eine eingebaute Versionsnummer vertragen ;-)

Diese neue Version enthält dann (inzwischen wirklich einfach)
benutzbaren Threading-Support für VB (da werkeln Pipes
unter der Haube, so dass ein einmal aufgespannter Thread
auch von anderen Prozessen! aus benutzbar ist, z.B. in
Singleton-Szenarios - also in etwa gleiches Prinzip wie die
Async-Workers oder auch Singletons in .NETs WCF ...
und socketbasierte + hostübergreifende Kommunikation geht
ja eh schon immer über den RPC-AppServer der da auch
schon drinsteckt...).

Ein paar andere neue Klassen (VB-kompatible Collection -
nested serialisierbar, neuer CommandObjekt-Typ für die
Leserichtung im SQLite-Wrapper, neue und überarbeitete
GDI-WrapperKlassen, usw.) sind dann auch noch enthalten -

Können die GDI-Wrapper Klassen auch Bilder im PNG Format laden (womöglich von Platte und/oder Memory)? GDI kennt doch nur die Bildformate, die auch die VB-PictureBox kennt, und da fehlen halt inzwischen wichtige Formate.

und am wichtigsten für die Migration sind wahrsch. die neuen
Widget-Support-Klassen (hab nach mehreren Anläufen
wie Du ja weisst, nun endlich *den* Weg gefunden, der
am besten mit der aktuellen VB6-Usercontrol-Philosophie
vereinbar ist - und dennoch völlig klassenbasiert (und natürlich
windowless) daherkommt.


Prima! Bin schon gespannt. Hast Du auch den Widgets die Möglichkeit mitgegeben, dem User Ownerdraw zu erlauben und die Daten virtuell zu halten?

Diese Infrastruktur-Dll (dhRichClient) also vielleicht zunächst
mal als VBRuntime-Erweiterung betrachten, die "einfach da ist"
und gegen die dann quasi "managed" (ohne explizite API-Aufrufe
im eigenen Applikations-Code) gearbeitet werden kann.
Diese Klassenbibliothek stellt (aus meiner Sicht) also das
regfree benutzbare "MiniFramework" dar, gegen dass dann
(größtenteils calling-kompatibel) auch *nach* erfolgter VB6-
Sourcemigration weiter gearbeitet werden kann.

Ich verstehe ja den Framework-Ansatz. Aber ich bin immer noch nicht so recht davon überzeugt, daß ein solches Framework in *einer* Dll implementiert werden sollte. ME wäre es besser, das Framework auf mehrere Dlls aufzuteilen (nach Funktionszugehörigkeit).

Diese Abstraktion des klassischen WinAPI hinter (derzeit
noch) VB6-Klassen ist für den Cross-Platform-Support dann
in jedem Falle nötig, da z.B. auf Linux-Seite unter der Haube
eben an Stelle des WinAPI jeweils die entsprechenden
native OS-APIs zum Einsatz kommen werden.

Vielleicht noch ein paar Worte zu den neuen VB-"Widgets"...
Direkt im neuen dhRichClient werden zwei weitere wichtige Klassen
enthalten sein, ein richtiger "WindowManager" cWidgetRoot,
der in der Lage ist, einen Mouse+Keyboard-Input-Stream
zu verarbeiten - und in der Gegenrichtung dann auch das
Rendering der Widget-Hierarchie übernimmt (inklusive vollem
AlphaPercent-Support und/oder völlig transparenten
Backgrounds für derzeit jede enthaltene Widget-Implementierung).
Und dann eine cWidgetBase-Klasse, die von jedem neuen
Widget (direkt oder indirekt) WithEvents benutzt werden muss -
also so eine Art "visuelle Vererbung" ist damit in eigenen Widget-
Implementierungen relativ elegant möglich (ohne viel Code
schreiben zu müssen, und ohne die Benutzung von VBs
Implements-Keyword).


Klingt gut.

Der WindowManager ist noch relativ schlank - und kommt
derzeit in Kombination mit einem VB-Usercontrol zum Tragen,
das dann quasi den RenderHost für eine WidgetHierarchie stellt.
Hier wird derzeit per WithEvents-Subclassing ganz einfach
der Input-Stream (Key- und MouseEvents) abgegriffen
und in der Gegenrichtung bestimmt die aktuelle UserControl-
Ausdehnung (Width und Height) die Größe des Memory-
basierten Render-DCs, in den vom WindowManger aus
"gezeichnet" wird (inklusive finalem Blit in die aktuelle VB-
UserControl-Position/Ausdehnung).
Das funktioniert derzeit schon wunderbar schnell u. flickerfrei
auch gegen windowless VB-Usercontrols als "Host".
Und da das Ganze von vornherein auf einem von Windows
unabhängigen "windowless WindowManager" aufsetzt,
werden später noch sehr interessante Dinge relativ leicht
umsetzbar sein - wie z.B. zoomed RenderOutput einer kompletten
WidgetHierarchie (ebenso möglich auch für Einzel-Widgets)
oder TerminalServer-ähnliche Szenarien, bei denen dann
der "finale Blit" nicht gegen ein (derzeit noch) VB-Usercontrol
läuft, sondern als beispielsweise JPG-Stream (oder VNC-
kompatibler Stream oder RDP-kompatibler Stream) über
Sockets geleitet - und von einem sehr schlanken Client
dann letztlich auf den Screen gebracht wird.

Soviel erstmal zur prinzipiellen Arbeitsweise der neuen
Widgets (die zumindest von der Renderseite her schon
komplett unicode-fähig arbeiten über die xxxxW-APIs).

Die eigentlichen Widget-Implementierungen sitzen
derzeit innerhalb einer dhWidgets.dll (die also abhängt
von dhRichClient.dll) und bei der ich keine Probleme
hätte (entsprechendes Interesse der Community
vorausgesetzt), die sofort "aufzumachen" unter einer
BSD-Style-Lizenz.

Das wäre sicher wünschenswert. Als Entwicklungsmodell würde ich das "Linus"- Modell vorschlagen ;-)

Aktuell enthalten und funktionierend sind z.B. schon
TextBox (war ziemlich knifflig <g>), sämtliche Button-

Ja, die Textbox hats in sich :-) Hat die auch die Möglichkeit, Daten virtuell zu halten? Evtl. sogar in der Form, daß die einzelnen Zeilen in einem Array liegen? Du hast also die Funktionalität, die sonst in den Windowsfensterklassen liegt, nachgebaut? Ist natürlich eine Menge Arbeit, lohnt sich aber. Sicher schwierig, hier einen guten Kompromiß zu finden: es muß ja nicht alles zu 100% kompatibel sein, das wäre auch gar nicht sinnvoll, da auch MS nur mit Wasser kocht und manches stark verbesserungswürdig ist.

Typen (CommandButton, CheckBox, CheckButton,
OptionBox und OptionButton), ein virtuelles ListView-
Widget, dass in Verbindung mit dem neuen cCollection-
Container dann "seitwärts-Datenbindung" unterstützt
(sowohl sorted als auch unsorted) und MultiColumn-
sowie Edit-Support schon eingebaut hat - darauf basierend
dann auch schon ein voll funktionsfähiges DataGrid für
SQLite (inkl. der Column-Sorts und ebenfalls editierbar),
direkt "databindable" an SQLite-Recordsets und ein
universell einsetzbares Frame-Widget.

Und ich werd mal sehen, dass ich in die erste Demo
ebenfalls noch den schonmal in "Rohform" geposteten
VB-Editor als echtes Widget noch mit integriere -
da hättest Du dann (jetzt mal angenommen ich mach
die WidgetSourcen im Januar dann "auf"), Deinen
erweiterbaren SourceCode-Editor - und ich hätte schonmal
meinen ersten "Widget-Maintainer" gefunden und eine
Sorge weniger... ;-)


Bevor ich mich schlagen lasse ;-)

Also vielleicht nochmal als Kurzzusammenfassung:

Derzeit noch Public-Domain-Binaries für Infrastruktur:
dhRichClient.dll (klassenbasiertes MiniFramework)
sqlite35_engine.dll (die eigentliche DB-Engine ... -
in Verbindung mit dhRichClient-RPC ist echter und
sehr gut skalierender DB-ServerModus möglich)

Demnächst als BinaryDemo und wahrscheinlich bald
unter BSD-Style OpenSource-Lizenz:
dhWidgets.dll (oder von mir aus dann auch vbWidgets.dll)

Weiß jetzt nicht, ob da Namensrechte verletzt werden, aber prinzipiell fände ich vbWidgets besser.

Ein neues windowless GUI-Framework das auf einem sehr weit
tragenden Ansatz beruht - und künftig in der Lage sein sollte,
alle möglichen GUI-Szenarien abzubilden, von MDI-oder
Docking-Windows-Szenarien über "normale" Controls
bis hin zum selbst implementierbaren TerminalServer-
Szenario - alles unter VB-Classic-Sourcecode-Regie.
Abhängigkeiten derzeit nur zum "klassichen" GDI32,
keine GDI+ und keine CommonControls-Dependencies -
Themeing-Engine sehr einfach integrierbar - aktuelles Basis-
Theme ist ein farblich eher zurückhaltender Stil, der so
ein wenig nach XP-Silver aussieht - wenn man die
entsprechenden Routinen unter Windows auf uxtheme.dll
umlenken würde, bekäme man recht einfach den nativen
Look generiert/präsentiert.


Mit uxtheme bekommst Du doch dann doch eine common controls Abhängigkeit?

Dann der neue Compiler (Start so ab Mitte nächsten Jahres):
Von vornherein als offenes Projekt angelegt - zunächst
erstmal mit dem sehr einfach "installierbaren" (XCopy
einer ca. 500kByte-Ordnerstruktur reicht) TinyCC-
Compiler als Backend - hier gehen die Aktivitäten in der
tcc-Mailing-Liste in den letzten Wochen wieder nach oben -
(nach dem Wechsel der Code-Verwaltung auf GIT) - vor
ein paar Tagen hat jemand auch die 64bit-x86-Richtung
begonnen abzudecken (war bisher der Hauptgrund,
warum ich noch unentschlossen war bzgl. Compiler-Wahl
und auch auf llvm.org bzw. dem daruf basierenden clang-
Kompiler warten wollte - aber ich denke jetzt, für den ersten
Schritt ist TinyCC ideal - klein, ohne Probleme installierbar,
superschnelle Compile-Zeiten usw. und 32Bit-Code-
generierung unter Windows derzeit auch ohne Probleme.


Welcher Compiler anfangs verwendet wird, ist sicher nicht so entscheidend. Er sollte halt Standard-C-Code übersetzen können. Sollte dann später wegen zB. besser optimiertem Compileroutput ein Compilerwechsel nötig sein, ließe sich das ja einfach durchführen. Evtl. kann man es sogar dem User überlassen, welchen Compiler er verwenden will. Dazu müßte halt ein Buildtool mit integriert werden.

Und wie die hier erwähnten VB-Projekte ja bereits zeigen -
ohne IDE braucht man gar nicht erst anzutreten mit
Alternativen zu VB6. Und man muss IMO auf der Windows-
Plattform anfangen die Entwickler abzuholen (das meine
ich vor allem im Hinblich auf das schon sehr gut und
stabil funktionierende Gambas, das es aber derzeit leider
nur für "unixoide OS" gibt und das ein klein wenig an
zu geringem "community-support" leidet - und auf der
anderen Seite im Hinblick auf FreeBasic.org, das seine
schnell gewachsene Popularität vor allem seinem von
vornherein offenen Ansatz verdankt, aber zu einem
großen Teil eben auch der Tatsache, dass es auch
auf der Windows-Plattform läuft).


Die IDE ist schon wichtig. Und mit Windows anzufangen, ist auch ok. Bei Deinem Ansatz sollte es ja nicht so schwer sein, später andere OSe mit ins Boot zu holen.

Also eine zunächst auf "echtem VB6" basierende neue IDE
muss her, die am Anfang vielleicht erstmal ohne (Widget-)
Form-Designer auskommt - aber irgendwo dann
auch schon Intellisense supporten sollte, und VB-
Klassen und *.bas-Module handhaben und übersetzen
kann.

VB Code muß sie schon übersetzen können. Der Formdesigner ist vielleicht anfangs nicht so wichtig. Als ich mit Java anfing, war ich sehr angenehm überrascht zu sehen, daß sich das GUI komplett und relativ einfach in Code definieren läßt. DotNET geht ja den gleichen Weg.

Wichtig wäre ein vernünftiges und tragfähiges Layoutmodell, realisiert in Layoutklassen (inkl. Splitter etc). Außerdem müssen die Widgets die wahrscheinlich mit unterstützen (zumindest sollten sie eine Property haben, der man eine Layoutklasse zuweisen kann).

Da könnte ich mir vorstellen, mit einzuspringen.

Hierür will ich definitiv auf den neuen Widget-Klassen
aufsetzen, damit irgendwann in 2010 (wenn sowohl
die Klassen aus dhRichClient.dll als auch die in
vbWidgets.dll übersetzbar werden), auch der
Selfhosting-Status der IDE leichter machbar wird.

Und um jetzt nach der etwas länglichen "Eröffnung"
wieder die Kurve zu kriegen zu Jabaco - und der dort
offenbar in VB6 vorliegenden IDE - hier ließe sich
mit Sicherheit vieles an Coding-Aufwand sparen,
wenn Manuel Siekmann zu einer Art "Code-Merge"
ebenfalls bereit wäre (um zum Einen einheitlich auf dem

Ja, daran dachte ich auch.

neuen VB6-Widget-basierten GUI-Ansatz aufzusetzen -
zu dem ich entspr. Vorarbeiten liefern werde - und der
wie gesagt in einem von der aktuellen VB6-Runtime
unabhängigen SelfHosting-State enden wird) und
ich wäre natürlich interessiert am aktuellen Lexer/Parser
(so der denn in VB6 geschrieben ist und nicht irgendwo
auf Groovy-Code o.ä. basiert), um dann an Stelle von
JavaByte-Code halt alternativ "einfach" C-Code zu
emittieren.


Geschrieben ist der Parser sehr wahrscheinlich schon in VB. Welcher Ansatz verwendet wird, weiß ich nicht. Das Kompilieren geht jedenfalls nicht so rasend schnell. Von meinen eigenen Parserexperimenten weiß ich, daß hier handoptimierter Code durch nichts zu schlagen ist. Ansätze, die generischen Code verwenden und zB auf Tabellen (Goldparser) zurückgreifen oder (wie yacc und Konsorten) aus der BN-Beschreibung der Syntax Code generieren, der den zu compilierenden Sourcecode danach durchflöht, ob eine der Regeln erfüllt ist, sind immer langsamer.

Bzgl. der unterschiedlichen Welten (ich will in jedem Falle
eine unmanaged arbeitende, ohne die großen Frameworks
daherkommende neue RAD-Umgebung für den Desktop
hinbekommen, sehr leicht portierbar auf unterschiedlichste
Plattformen Dank des generierten C-ZwischenCodes) - das
gehe ich also in der nächsten Zeit (die nächsten Jahre) in jedem
Falle an, weil ich das nunmal "so brauche" künftig.

Aber jetzt mal angenommen wir würden "zeitig mergen",
dann sähe ich die zusätzliche Möglichkeit, mit dem selben
Kompiler sowohl C- als auch JavaByte-Code emittieren zu

Sollte wahrscheinlich möglich sein.

können (aus derselben IDE heraus) als ein sehr sehr interessantes
Feature - und wenn die IDE (bzw. Manuel mit seinem Java-
Background) sich dann (zunächst) erstmal darauf konzentrieren
würde, verstärkt die Serverseite bzgl. der Java-Emittierung
abzudecken (z.B. ein integrierter "Form-Designer" für
Java-Server-Faces als Pendant zu ASP.NET + WebControls)
dann gäbe es in der Startphase dieses Projekts kaum "Interessens-
Konflikte" und keine allzu großen "Merge-Abhängigkeiten".

Das Ganze dann auch für die "Desktop-Seite" mit der Fähigkeit
auszustatten (alternativ zu dem von mir favorisierten unmanaged
arbeitenden, schlanken "Widget-Ansatz bzw. Designer") dann
auch noch wahlweise Swing-basierte Java-GUIs bzw. die
Java-Runtime voraussetzenden Desktop-Apps erzeugen
zu können (ich glaube, Manuels derzeitiger Ansatz,
bzw. Form-Designer arbeitet ja bereits so) wäre dann kein
allzu großes Problem IMO.
Toll wäre natürlich, wenn sich für dieselbe existierende
GUI-Designer-Definition (also das, was sich derzeit beim
"richtigen" VB6 in den *.frm-Files befindet) per einfachem
Schalter alle drei GUI- bzw. Applikations-Varianten erzeugen
ließen:
unmanaged C-based + vbWidgets-GUI (Desktop-Targets)
managed java + Swing-GUI (Desktop-Targets)
managed java + JSF-based-GUI (WebServer hosted).


Jabaco hat hier sein eigenes Format. Es hält die Daten in XML-Files. Es gibt ein ausführliches Projektfile. Für die Forms und Module wird der Code ebenfalls in XML-Dateien gehalten. Der Code ist in einer CDATA-Sektion, GUI-Bestandteile sind im gleichen File und deren State ebenfalls.

Aber für Deine Zwecke: zumindest anfangs müßten doch auch die "alten" VB-Formate unterstützt werden (oder zumindest sollten alte Projekte gelesen und konvertiert werden können).

Vielleicht liest Manuel ja hier mit und schreibt mal,
was er von alldem hält - und wie gesagt - viel wird
auch davon abhängen, wie bereit man zur vollständigen
Öffnung seiner "Mannjahre an Code" ist, die bei Manuel
wahrscheinlich primär in der VB-komp.-IDE stecken (seine
bereits veröffentlichte Runtime auf sourceforge ist ja eher
"noch übersichtlich" und das Öffnen tat an der Stelle
wahrscheinlich nicht ganz so "weh").
Mir geht's da im Prinzip genauso - das Öffnen der Widgets
wird nicht so weh tun, da hier nur ein paar Mann-Monate
drin stecken - aber bei dhRichClient.dll tu ich mich auch
ziemlich schwer, da ist über die letzten Jahre sehr viel mehr
Coding-Aufwand reingeflossen.

Hätte da aber mit Sicherheit kein allzu großes "Öffnungs-
Problem", wenn denn ein darauf basierendes Kompiler-
Projekt richtig Fahrt aufnehmen würde - und so wird's
Manuel hinsichtlich seiner Investitionen in seine neue
VB-Classic-IDE wahrscheinlich auch gehen.

So nach dem Motto:
Erstmal schauen, wie (und ob) die Gemeinde anspringt,
falls nicht, dann hat man halt nicht den "Fehler" gemacht
und seine Sourcen zu zeitig geöffnet - und man bietet halt
für einen überschaubare(re)n Kreis an Usern weiterhin
Support für die Public-Domain-Binaries und eventuell
kommt auch hier und da ein am Source interessierter
Kunde der auch bereit ist, dafür (bzw. für "erweiterten
Support") zu zahlen. So läuft das zumindest derzeit bei mir
(in meiner "Denke" und auch in der Praxis) hinsichtlich der
dhRichClient.dll.

Ist natürlich in gewisser Weise (hinsichtlich "hoffentlich
anspringenden Community-Supports") ein Henne-Ei-Problem,
aber das ist sicherlich auch Manuel klar.
Ich kann mich jedoch hinsichtlich des Öffnens der RichClient-
Sourcen schonmal soweit festlegen, dass ich die in jedem
Falle aufmachen werde, sobald der neue unmanaged Compiler
in der Lage ist (nach hoffentlich gering ausfallenden Änderungen
an den enhaltenen, derzeit VB6-basierten Wrapper-Klassen),
selbige vollständig zu übersetzen - sprich - der schon erwähnte
"SelfHosting-State" für diese neue, erweiterte VB-Laufzeit-
umgebung erreicht ist.

Olaf



--
Ulrich Korndoerfer

VB tips, helpers, solutions -> http://www.proSource.de/Downloads/
.