Visual Basic Win App auf OS X portieren?

[DasSCHWITZENDEÖltier]

Ein Freund von mir bietet eine mit Visual Basic programmierte Windows App an.

Ich frage nur aus Interesse und ohne einen Hauch von Programmierung zu verstehen. ließe sich diese auf OS X portieren?
Danke schon mal....


http://www.allinone-office.com/

 

[iPoe]

hallo,
auch ich bin kein programmierer, aber ich denke der unterbau und das rundherum um OSX und BSD sind so verschieden zu windows dass es keine chance geben wird das zu portieren.
wenn es so einfach ginge hätten wir ja viele tolle applikationen unter OSX laufen <-- das war ironisch gemeint!

iPoe

 

[DasSCHWITZENDEÖltier]

hallo,
auch ich bin kein programmierer, aber ich denke ....
iPoe

Hehe, danke, aber deshalb wollte ich ja was vom Fachmann hören....

 

[pi26]

Hallo,

die Portierung von VisualBasic-Applikationen (vor .NET) stellt mit RealBasic meist kein Problem dar.

Details siehe hier

mfg pi26

 

[Sir Q]

Ich habe selbst mit RealBasic Programme von VisualBasic portiert - bei "herkömmlichen" Anwendungen ist das auch absolut problemlos möglich. In einigen speziellen Fällen muß schon einiges an Aufwand betrieben werden - wenn z.B. mittels API-Aufrufen native DLLs angesprochen wurden - und es kann recht fitzlig werden, wenn nicht dokumentiert wurde was das Programm damit eigentlich bezweckt.

Auch die Ausführbaren Dateien, die RealBasic rausgibt funktionieren prinzipiell auf allen Zielplattformen - da war ich selbst überrascht - auch wenn ich festgestellt habe, das mann den Anwendungen unter Windows ansieht, das sie vom Mac stammen - die ProgressBar sah einfach Mac-Like aus

~

Persönlich entwickle ich Tools seither in Java - druch die standardisierter VM laufen die Apps so überall gleich. Zwar wird Java nachgesagt "langsam" zu sein - aber hey, das sagt man auch von MS-Word und wieviele verwenden es dennoch?! Ernst bei Seite - sauber gecodet läuft java zuweilen schneller als VB ...

 

[DasSCHWITZENDEÖltier]

Gut, das hilft mir schon mal weiter..danke!

 

[pi26]

In einigen speziellen Fällen muß schon einiges an Aufwand betrieben werden - wenn z.B. mittels API-Aufrufen native DLLs angesprochen wurden - und es kann recht fitzlig werden, wenn nicht dokumentiert wurde was das Programm damit eigentlich bezweckt.

Auch die Ausführbaren Dateien, die RealBasic rausgibt funktionieren prinzipiell auf allen Zielplattformen - da war ich selbst überrascht - auch wenn ich festgestellt habe, das mann den Anwendungen unter Windows ansieht, das sie vom Mac stammen - die ProgressBar sah einfach Mac-Like aus

~

Persönlich entwickle ich Tools seither in Java - druch die standardisierter VM laufen die Apps so überall gleich. Zwar wird Java nachgesagt "langsam" zu sein - aber hey, das sagt man auch von MS-Word und wieviele verwenden es dennoch?! Ernst bei Seite - sauber gecodet läuft java zuweilen schneller als VB ...

Gut, wenn DLLs im Spiel sind kann man meist auch nicht mehr von einem reinen VB-Programm sprechen. Gibt dann aber immerhin die Möglichkeit DDLs für die Win-Portierung beizubehalten und für Mac ein entsprechendes Framework einzubinden. Und wer etwas portieren will hat den Quelltext - und blickt hoffentlich auch durch, was die DDLs bewerkstelligen. Mit dem etwas frechen Werbeslogan "Cross-Platform that really works" spricht Realsoftware wohl besonders auf das eben auch nicht immer so paradiesisische "Java" an.
Übrigens geht Realbasic seit Jahren in vielen Belangen ein beeindruckendes Innovationstempo - die Programm können nun z.B. von "Windows-Realbasic", vom "Apple-Realbasic" oder seit neuestem vom "Linux-Realbasic" stammen, denn die (übrigens mit Realbasic höchstselbst programmierte) IDE ist für alle Plattformen verfügbar! Die Progress-Bars sind auch längst plattformspezifisch angepasst.

mfg pi26

 

[Sir Q]

RealBasic hat definitv enorme innovationen hervorgebracht - die Möglichkeit den Code gliech für Macintosh, Linux und Windows in einem Durchgang zu compilieren - und dann auch tatsächlich lauffähige Programme zu haben - ist schon toll, aber nicht zu letzt ist RealBasic aber auch zu diesen Innovationen gezwungen.

Das .NET Framework von Microsoft erfreut sich wachsender beliebtheit und ist dabei nicht einmal von einem herkömmlichen Wald-und-Wiesen-Windows auf ein Windows CE kompatibel. Es besteht aber zu befürchten, das nicht nur "alte" OS-X Programme mit Rosetta auf dem Intel-Mac laufen werden, sondern auch Windows-Programme im .NET-Framework (z.B. durch mono vorangetrieben) ...

Und Java mit seiner standardisierten VM läuft auf allen implementierten Plattformen (und das sind enorm viele) gleich gut. Java, als kostenlose Sprache ist zwar von einem Hersteller "abhängig" - aber das ist bei fast allen Sprachen schon immer so gewesen - aber dennoch hat sie eine unglaublich große comuinity die sich über verschiedene Plattformen hinweg erstreckt ... Das (Obwohl die Insel Java wirklich paradisisch ist) bei Java nicht alles paradisisch ist, ist kein Problem vom Java - dieses Problem hat jede Sprache. Dennoch sind sehr viele Dinge wirklich Plattformunabhängig machbar - Drag&Drop, Drucken, Internet - alles kein Problem.

Es gab es lange Zeit nur wenige alternativen für Leute, die auf resp. für Mac-OS entwickeln wollten. Mit OS-X war Java auf dem Mac plötzlich kein Problem und damit drängten immer mehr Entwicker auf diese kleine Plattform. Durch den BSD-Unterbau ist die entwicklung für Mac einfacher - viele BSD und GNU-Linux-Programme sind portiert - viele programme (und ich finde es sind in der Zeit gesehen mehr als vor X) sind neut hinzu gekommen. Mit dem unabwendbaren Zusammenschluss von Apple und Intel steht zu befürchten, das es kein Bedarf mehr an einer "nur Mac"-Programmiersprache geben wird. Der Ausweg - das System von RealBasic zu verbessern, um wenigstens die alten Kunden nicht zu verlieren ist daher ganz natürlich. Metrowerks (CodeWarrior) war es - wenn ich mich recht erinnere - die gesagt haben, das sie keine Intel-Mac-Version anbieten werden. Daher ist es auch verständlich, das sie Linux als Ausweichsystem anbieten. Damit wird sich RealBasic sicherlich das Überleben gesichert haben - es wird aber (wie ich vermute) ebenso ein Schattendasein fristen wie Delphi - die Zeit den Markt zu revolutionieren hat RealBasic verpasst (das ist jetzt vieleicht etwas arg zynisch, aber wenn RealBasic vor 6 Jahren hätte Linux, Mac und Windows in der heutigen Qualität beliefern können - who ) ...

~

DLLs ansprechen war bei VB ja kein Problem und in vielen online-Tutorials findet mann immer wieder Artikel die beschreiben, wie mann mit einem DLL-Aufruf umständliche Dinge ganz einfach "direkt" machen kann - z.B. den Druckerschacht wechseln, sind 2 zeilen, wenn mann direkt an die DLL geht, über die standard-Druckfunktion sind es locker 20. Ich habe (um diese Aussage etwas einzuschränken) zuletzt mit VB 8 gearbeitetet - neuere Entwicklungen können eventuell das Gegenteil zeigen.

Gerade die quick&dirty-Programmierer, die Clicki-Bunti-Gui-Bastler und die ambitionierten Hoby-Programmierer schätzen die visuellen Editoren von VB und RB - aber äufwändigere Programme gehen immer weiter davon weg. Mit Factorys und Facades bauen sich die GUIs selbst und passen sich dem ausgabeformat an. Da ist wieder abstraktes Denken verlangt und da trennen sich dann die ambitionierten Hoby-Programmierer von den Entwicklern.

Das ist dann auch das Problem - in VB entsteht viel Code einfach so - hier ein Button und ZACK - 5 Zeilen code. Hier ein Wert im Inspektor geändert, da was geklickt, hier ein objekt abgelegt und der Code wächst und Wächst und das Programm tut auch. Dann wird mal was aus einem Tutorial kopiert - funktioniert. Und dann soll das Programm auch auf'm Mac laufen. Ich kenne VB-Programmierer die garnicht programmieren können - jedenfalls nicht im herkömlichen Sinn von "ein Programm schreiben". Wenn diese Leute dann etwas portieren müssen - und schon nicht wissen was der Code im "original" macht - und plötzlich tut was nicht so wie es soll so das anpassungen notwendig ist, dann schauen sie wie Ochs in's Uhrwerk ...

~

Apropos - auch Eclipse als Multiplattform-IDE ist meines Wissens nach zum größten Teil in Eclipse selbst geschrieben worden. Microsoft gibt an, größtenteils VisualStudio für die Entwicklung ihres Betriebssystems und der Microsoft-Programme zu verwenden (Kernel-Komponenten und andere systemnahe Programme werden zuweilen noch in ansi-c mit asembler-funktions-aufrufen geschrieben) und der GCC wird mit dem GCC compiliert ...

~

Autsch - das ist aber viel Text geworden - na - ich werde da jetzt nicht löschen, seht es mir nach, es ist 2 Uhr und ich langweile mich - die beleuchtete Tastatur vom PowerBook tippt sich nur so runter und ich hatte zu viel Koffein heute und kann nicht einschlafen - aber das ist ein anderes problem

 

[pi26]

Eigentlich geht es in dem Thread ja um die Portierung einer VB-Applikation und nicht um ein Glaubenskrieg Realbasic gegen Java.
IMHO wurde damals mit JAVA wieder einmal eine mässige Idee als die vermeintliche Superlativlösung mit immensem Aufwand in den Markt gedrückt (Überschwemmung der Buchläden mit Java-Literatur etc.). Man hat die Interpreter-Sprachen mit dem Konzept der Virtual-Machine aus dem Feld geschlagen, weil man zunächst auch die in Hardware realisierte VM in Aussicht gestellt hat und Compiler-Sprachen wiederum natürlich über Javas die Multiplattformfähigkeiten in Zweifel gestellt. Heute ist Java letzlich von der Effizienz her eher in der Gruppe der Interpretersprachen zu positionieren, weil hier ein Prozessor emuliert wird.
Wiedereinmal der Siegeszug einer FataMorgana im IT-Laienmarkt - und hierein werfe ich auch 95% der "Entwickler". Keine Programmiersprache kann was für schlechte Programmierung und dennoch ist sie allgegenwärtig - unter Java ebenso wie unter Realbasic, etc..
Was mir persönlich aber am meisten auf den Geist geht, sind die Hinweise auf pseudokostenlosen Programmiersprachen, wo man entweder mühsam die kostenlose und dann oft wirr aufbereitete Doku fressen muss oder halt die Literatur holen muss. Bei Realbasic erhält man halt einfach ein Gesamtpaket samt brauchbarer und eigentlich vollständiger Doku. Spielt aber in unserem Bildungswesen ja keine Rolle - das muss primär nichts kosten bzw. althergebrachte Industriezweige mit Umsätzen füttern.

mfg pi26

 

[Sir Q]

Hi pi26,

ich habe garkeine Lust "Glaubenskriege" zu führen. Ich habe lange Pascal programmiert, dann sogar das Pascal for Windows bis Windows95 - dann habe ich auch Delphi programmiert - mit Schülerlizenz ebenso VB. Im Studium wurde dann Objektorientierung am Beispiel von C++ unterrichtet - also hab ich C++ programmiert und fand die Sprache toll - wenngleich nicht ganz konsequent. Dann hab ich im Rahmen eines Projektes für n-tv auf dem Mac entwickelt und mit RealBasic programmiert - privat habe ich später durch Zufall mit Java angefangen. Das ich sowohl ein Visual-Studio habe kaufen müssen, als auch ein Deplhi - selbst ein Borland-J-Builder habe ich mir mal gekauft, zeigt, das eigentlich nicht die Sprache geld kostet, sonder die IDE. Eine gute Java-IDE kann halt auch richtig Kohle kosten.

Aber egal für welche Sprache nun auch immer - Handbücher und Referenzen sind immer Teuer

~

Ich wollte mit meinem Senf zum Thema RealBasic auch eher darauf hinweisen, das die Möglichkeiten Mac, Linux, Windows zu beliefern erstens nicht ganz unproblematisch ist, und zweitens nicht selbstlos entwickelt, sonder eine logische Konsequenz aufgrund der Marktumstände ist / war.

Das es möglich ist, einfache Microsof VisualBasic Projekte mit RealBasic auf dem Mac zum laufen zu bringen, ist meines erachtens das gewünschte Fazit.

Die Frage, ob RealBasic die „richtige“ Wahl für eine Programmiersprache ist - wollte ich auch garnicht diskutieren, denn meiner Meinung nach ist eine Programmiersprache dann „die Richtige“, wenn man das gewünschte Ergebnis damit erziehlen kann.

~

Plattformunabhängigkeit ist auch nur marginal an der Programmiersprache festzumachen. C-Code kann mit genügender Sorgfalt im Porgramm-Design auch für einfache portierbarkeit ausgelegt werden (Siehe z.B. Firefox: Mac, Linux, Windows). Java kann mit entsprechender Planung auch die eigenen Schwächen umgehen auch wenn es keine Eigenschaft der Sprache ist, so kann die IDE RealBasic ausführbare Programme für verschiedene Platformen ausgeben ...

 

[DasSCHWITZENDEÖltier]

Für mich als Laien (waren) sind eure Ausführungen in jedem Falle interessant...danke nochmals.

 

[pi26]

Ich wollte mit meinem Senf zum Thema RealBasic auch eher darauf hinweisen, das die Möglichkeiten Mac, Linux, Windows zu beliefern erstens nicht ganz unproblematisch ist, und zweitens nicht selbstlos entwickelt, sonder eine logische Konsequenz aufgrund der Marktumstände ist / war.

Hallo Sir Q,

neben den natürlichen wirtschaftlichen Faktoren es ist auch immer eine Frage des Könnens und der Einstellung. Denn gute Entwicklungsabteilungen sind eben nicht beliebig skalierbar sondern sind von einigen genialen zusammenpassenden Leuten angetrieben. Bei Realsoftware wurde nämlich seit Jahren von Version zu Version auffällig nicht nur die Pflicht erfüllt.

Ich stelle mich hier ja auch nicht direkt gegen Java - ich halte es persönlich halt für nichts Besonderes. Z.B. Nextstep und das heutige OSX, Delphi, Realbasic, Postscript, Applescript hingegen halte ich für besondere Leistungen, welche imho im oben beschriebenen optimaleren Klima entstanden sind.

Letztlich sehe ich für Realbasic kaum Grenzen, wenn man strukturiert arbeitet und zusätzlich in der Lage ist, bei geschwindigkeitskritischen Code als Frameworks/Lib/DDL anzubinden.

mfg pi26

 

[Sir Q]

Wieder halb eins - meine Frau liegt schlafend neben mir und das powerbook steht in der ablage am kopfende unseres bettes - aber diesmal fasse ich mich kürzer

~

Insofern, lieber pi26, stimme ich mit deiner meinung überein - möchte sogar noch weiter veralgemeinern: ein Entwickler der seine Sprache genau kennt und deren Grenzen - der Weiß wie er Schwachstellen der Sprache vermeidet und der strukturiert eine Entwicklung angeht, für den ist in seiner Sprache eigentlich auch jedes Problem lösbar.

~

Ein gut aufeinander abgestimmtes Team ist unbezahlbar

 

[DasSCHWITZENDEÖltier]

Ich hab nochmal eine Ergänzungsfrage: die Win-App. wird wohl von einer Access-Datenbank gefüttert....lässt sich diese dann auch problemlos portieren?

 

[tjp]

Ich hab nochmal eine Ergänzungsfrage: die Win-App. wird wohl von einer Access-Datenbank gefüttert....lässt sich diese dann auch problemlos portieren?

Nein, Access ist nicht portabel. Vorher müßte man auch die Windows Version auf ein SQL DBMS umstellen. Access selbst kann man auch als RAD-Tool für eine beliebiges SQL DBMS verwenden, was auch eindeutig vorzuziehen ist. So gut Access als RAD-Tool ist so, schlecht ist es als DBMS.

 

[DasSCHWITZENDEÖltier]

Autsch...das hört sich nach einer Menge Arbeit an ..

 

[Sir Q]

MS-Acces gibt es für MacOS nicht.

Es gibt aber 3 mögliche Wege (vermutlich gibt es mehr - ich selbst habe nur diese 3 selbst ausprobiert resp. damit arbeiten müssen).

1. VALENTINA
Valentina ist ein Datenbank-Management-Syste (Kurz DBM oder noch allgemeiner: Eine Datenbank) die ihre Anfänge bei Director und RealBasic hat. Es ist recht einfach ganze Access-Datenbanken in Valentina zu importieren. Valentina gibt es (im Tausch gegen kleiner bedruckte Papierscheine) für verschiedene Plattformen und ist gerade in RealBasic ganz besonders einfach einzubauen.

2. ACCESS => ODBC => MySQL
Die MySQL AB bietet einen ODBC-Conntector an, mit dem es recht einfach ist, die Daten von Access in MySQL zu schieben. Da es MySQL kostenlos für verschiedene Systeme gibt, kann mann dann mit dem RealBasic-Programm recht einfach drauf zugreifen. Diese Lösung würde ich präferieren. (Der Umstieg von RealBasic/MySQL zu einer neuen Applikaton Java/MySQL ist dann garkein problem - sorry pi26, das mußte einfach sein

3. ACCESS => ODBC Windows => Netzwerk => ODBC Mac => RealBasicAplication
Der Admin kann auch unter Windows eine ODBC-Freigabe anlegen, über die dann unter MacOS wiederum mit dem ODBC-Administrator eine verbindung zur Verfügung gestellt werden kann - auf die die lokale Anwendung dann zugreifen kann. Diesen Weg mussten wir in einer Firma mal gehen - weil die Chefetage nicht wollte, das lokale kopien von der Unternehmensdatenbank auf den einzelnen entwicklungsrechnern rumliegen. eingerichtet hatte das Netzwerk-ODBC-Zeug ein kollege - damit wollte ich nichts zutun haben - es hat auch nur mäßig funktioniert (hin und wieder war die connection weg, es war sterbens langsam) - aber: es hat funktioniert ...

 

[DasSCHWITZENDEÖltier]

@ Sir Q: Danke..wie gewohnt sehr ausführlich

 

[tjp]

2. ACCESS => ODBC => MySQL
Die MySQL AB bietet einen ODBC-Conntector an, mit dem es recht einfach ist, die Daten von Access in MySQL zu schieben. Da es MySQL kostenlos für verschiedene Systeme gibt, kann mann dann mit dem RealBasic-Programm recht einfach drauf zugreifen. Diese Lösung würde ich präferieren. (Der Umstieg von RealBasic/MySQL zu einer neuen Applikaton Java/MySQL ist dann garkein problem - sorry pi26, das mußte einfach sein

Ich würde es eine Reihe von Gründen MySQL gegen PostgreSQL tauschen.
1) Lizenz; die PostgreSQL ist wirklich frei, bei der MySQL-Lizenz muß man genau lesen was man darf und was nicht, unter Umständen braucht man eine kommerzielle MySQL-Lizenz.
2) Fähigkeiten des DBMS; PostgreSQL ist bedeutend leistungsfähiger bei ähnlicher Performanz wie MySQL. Bei komplizierten Abfragen hat PostgreSQL die Nase nach meiner Erfahrung vorne.
3) ODBC Treiber gibt es auch für PostgreSQL

 

[Sir Q]

Hi tjp,

ich habe von persönlich durchgeführten Methoden gesprochen. Und ich habe nur zweimal mit Postgres arbeiten müssen. Einmal wurde das Projekt aufgrund unzureichender Dokumentation seitens Postgres nachträglich auf MySQL umgestellt, beim den anderen Projekt wurde nie bis zuende entwickelt, weil dem immer auf alles kostenlos bedachten kunden das geld ausging - traurig aber wahr ...

~

Postgres hat einige wirklich rafinierte gimicks und ist meiner meinung nach mit MySQL von der Leistung gleichauf. AutoScout24 wird mit MySQL betrieben (Jedenfalls war das vor der Übernahme duch die Telekom so - und ich gehe davon aus, das die Technik weiter die gleiche ist, das Geld nur in andere Tasche fließt) - DaimlerChrysler setzt beim SAP-R3 zu R4-Migrationsprozess in Teilbereichen auf MySQL (um von den Oracle-Lizensgebühren runter zu kommen, und dennoch eine Firma haftbar machen zu können, wenn was kaputt geht). Postgres kann einzelne Tabellen über mehrere Partitionen verteilen - das ist cool - bei MySQL kann maximal jede Tabelle auf einer eigenen Partition liegen. Postgres hat vor MySQL transaktionen unterstützt - da waren sie ihrer Zeit voraus. Postres hat vor MySQL Subselects unterstützt - auch da waren Sie anderen Produkten voraus. Es gibt schon evig StoredProcedures in Postgres und viele fitzlige Kleinigkeiten die rafiniert sind und die man von Berkley nicht anders erwartet.

Aber dennoch glaube ich, das MySQL und Postgres in dem Bereich von dem wir hier reden als technisch ebenbürtig betrachtet werden können - mit dem Vorteil, das MySQL aufgrund der durch den kostenpflichtig geführten Support enorm sauberen dokumentation die bessere wahl ist. Bei Postgres gibt es Probleme (z.B. Volltextsuchen) für den es schlicht keine Dokumentation gibt.

~

Um ein Bogen auf VisualBasic zurück zu schlagen: Wer eine VB-Anwendung mit RB portiert, der wird eine Dokumentation sehr zu schätzen wissen, so daß ich - allen „richtig frei“-Gedanken zu Trotz, guten Gewissens MySQL empfehlen muß ...