Programmierung unter Linux und Windows

Ich bastele ab und an kleine Programme mit VB.net, welche Dateien lesen und schreiben (xml, Text), die darin enthaltenen Daten bearbeiten. Oder Dateien kopieren und filtern. Selten DB-Zugriff und wenn nur lesend. Dazu gibt es einfache masken mit DAteiauswahldialogen und meistens ein paar Textfeldern und Buttons.Also kein großer Tiefgang, bin ja auch kein Programmierer.
Da ich sowas aus Spaß auch mal zu hause machen bzw. weiterbearbeiten will und nicht immer das Notebook mitschleppen möchte suche ich jetzt eine Möglichkeit, Linux und Windows zu verbinden.
Gibt es hier etwas abseits von Java und Mono?
Im Moment favorisiere ich Netbeans/Java, da ich dort die Masken einfach erstellen kann. Mono wäre sicherlich einfacher zu lernen weil ich aus der VB-Ecke komme.

Für einfachere sachen ist Mono sehr gut zu gebrauchen.
Ein Nettes Tool für VB-Freaks, die auch gerne ein bisschen herumspielen ist Gambas.
Das ist quasi eine art Nachbau von Visual Basic, allerdings mächtiger.
Für die GUI - elemente kommen da Qt und GTK zum einsatz und sind damit eigentlich Plattformunabhängig, sofern man die jeweiligen Libs auf dem System installiert.
Allerdings habe ich selbiges noch nicht unter windows benutzt und kann daher nichts darüber sagen...
Ansosnten hast du die üblichen Verdächtigen ja schon aufgezählt... der Vorteil von Java und Mono ist halt dass es verschiedene Entwicklungsumgebungen und tausende von Libraries für Schnick und Schnack gibt... Wenn deine Progrämmchen wirklich so einfach gestrickt sind, ist die chance überigens garnicht so klein, dass du sie quasi 1:1 unter linux mit Mono laufen lassen kannst.

Für die Aufgabe kommen die meisten Skriptsprachen in Betracht. Ich persönlich würde Python bevorzugen. Mit PyQt gibt es eine Qt-Anbindung, und mit dem Designer von Qt lassen sich die Oberflächen auch per Click&Drop zusammenbauen. Knackpunkt ist, dass man sich trotzdem mit dem Signal-Slot-Konzept von Qt auseinandersetzen muss.

Ich werde es mal mit Mono probieren.
An Python hatte ich auch schon gedacht, aber ich programmiere ja eigentlich nicht, insoweit soll die Lernkurve niedrig sein. Wenn ich mal wieder mehr Zeit habe, warum nicht.
Danke für euer Feedback

wintermute_3dc schrieb:

Ich werde es mal mit Mono probieren.
An Python hatte ich auch schon gedacht, aber ich programmiere ja eigentlich nicht, insoweit soll die Lernkurve niedrig sein. Wenn ich mal wieder mehr Zeit habe, warum nicht.
Danke für euer Feedback

Zum Vergrößern anklicken....

Ja genau..aus diesem Grund kann ich dir Mono nur empfehlen!

wintermute_3dc schrieb:

Ich werde es mal mit Mono probieren.
An Python hatte ich auch schon gedacht, aber ich programmiere ja eigentlich nicht, insoweit soll die Lernkurve niedrig sein. Wenn ich mal wieder mehr Zeit habe, warum nicht.
Danke für euer Feedback

Zum Vergrößern anklicken....

Nun ja, bei Python ist sie niedrig. Die größte Herausforderung könnte wirklich Qt dabei sein. Ansonst ist Python sehr einfach gestrickt und bringt die notwendigen libs auch meist schon mit der Standardbibiliothek mit. Mit Eric gibts auch eine schöne IDE (selber in Python geschrieben).

Naja, am flachsten ist die Lernkurve immer bei Dingen die man bereits kennt.
Wenn er mit VB.Net vertraut ist...
Allerdings ist Mono auf Linux noch ziemlich C#-Lastig, auch was die IDE Monodevelop betrifft.
Es existiert zwar AFAIK ein VB.Net Compiler und die Runtime ist prinzipiell kompatibel zu der von MS, dennoch ist der Komfort von Visual Studio bei VB.Net noch nicht wirklich auf der Linuxseite verhanden.
C#ianer habens da einfacher.

Ja genau..aus diesem Grund kann ich dir Mono nur empfehlen!

Zum Vergrößern anklicken....

Das kann ich dir auch nur empfehlen!!

1.) Es ist eine Illusion zu glauben, dass man sein für Windows geschriebenes Programm einfach so mit Mono auf einem Linux System laufen lassen kann. Hier musst du dich auf den kleinsten gemeinsamen Nenner beschränken und dann hast du nicht mehr viel. Eine Menge der VB.NET Funktion sind explizit für Windows ausgelegt.

2.) Wenn du vollen Zugriff auf den Linux Rechner hast, dann würde ich einfach eine zweite Partition mit Windows anlegen und gleich in VB.NET weitermachen. Wenn du auf dem Rechner nur User ohne Adminrechte bist, dann fällt wahrscheinlich das meiste sowieso schon flach, wenn du die Entwicklungsumgebung nicht installieren kannst.

andr_gin schrieb:

Eine Menge der VB.NET Funktion sind explizit für Windows ausgelegt.

Zum Vergrößern anklicken....

Beispiele?
Bei Windows Forms gebe ich dir Recht, aber das ist nichts VB.NET-spezifisches und Windows Forms wurden eh von WPF abgelöst. Ich weiß nicht wie gut Mono derzeit WPF unterstützt, aber während Windows Forms klar auf Windows ausgelegt ist und eigentlich nicht vernünftig für andere Plattformen implementiert werden kann, ist WPF tatsächlich plattformunabhängig.

Also Windows Forms wird unter Mono unterstützt. Unter Ubuntu z.B. muss man dazu nur entsprechende pakete nachinstallieren. WPF wird nicht unterstützt.

Ich habe mir letzens den Spaß erlaubt eine für .NET in C# geschriebene Anwendung (nicht mit Mono kompiliert!) unter Ubuntu zu testen. Hat soweit ganz ordentlich funktioniert. Kleinere Anpassungen waren aber doch nötig, wegen Platform-spezifischen Dingen, wie case-sensitive Dateinamen unter Linux.
Was mich dann noch genervt hat, war dann das etwas zerknautschte Layout. Ich vermute da einen Bug, wenn man Controls in andere Controls eindockt, per Dock.Fill.

Und was auch noch ein Problem war, aber nicht an Mono liegt sondern eher an meiner Anwendung: Die Schrift war anders und zu groß. An das habe ich beim entwickeln einfach nicht gedacht, weshalb dann die Buttons, Labels etc zu klein waren. Wenn ich die Schrift unter Windows auch größer stelle, habe ich das gleiche Problem.

Wenn man also ein paar Dinge beim Entwickeln im Hinterkopf behält, kann man bestimmt wunderbar Programme schreiben, die auf allen Platformen gleich funktionieren, und auch ansehlich aussehen. 8)

TiKu schrieb:

Beispiele?
Bei Windows Forms gebe ich dir Recht, aber das ist nichts VB.NET-spezifisches und Windows Forms wurden eh von WPF abgelöst.

Zum Vergrößern anklicken....

Nur weil Microsoft ordentlich die Marketing Trommel rührt, wird sich WPF noch lange nicht durchsetzen. Windows Forms hat alles das, was ein normaler Entwickler braucht. Ich sehe in WPF nicht wirklich einen Vorteil, außer dass Unmengen an bestehendem Code unbrauchbar sind.

Ich weiß nicht wie gut Mono derzeit WPF unterstützt, aber während Windows Forms klar auf Windows ausgelegt ist und eigentlich nicht vernünftig für andere Plattformen implementiert werden kann, ist WPF tatsächlich plattformunabhängig.

Zum Vergrößern anklicken....

Ich habe da gar nicht an so komplexe Dinge gedacht. Es scheitert ja schon daran, dass alle Windows Systemverzeichnisse nicht vorhanden bzw. komplett wo anders sind. Eine Registry gibt es auch nicht. Von Dingen wie ODBC Verbindungen oder ActiveX Steuerelementen will ich einmal gar nicht reden. Ich kann alles, was mit Pfaden umgeht doppelt implementieren, da hier der / das Trennzeichen ist usw. Das Rechtesystem funktioniert auch ganz anders. Bei Windows ist das ganz einfach geregelt: Alles, was andere User beeinflusst, darf ich nur lesen, in meinem Benutzer darf ich auch schreiben. Bei Linux ist der kleinste gemeinsame Nenner nur das alte rwx System, mit dem man nicht sonderlich weit kommt.

andr_gin schrieb:

Nur weil Microsoft ordentlich die Marketing Trommel rührt, wird sich WPF noch lange nicht durchsetzen. Windows Forms hat alles das, was ein normaler Entwickler braucht. Ich sehe in WPF nicht wirklich einen Vorteil, außer dass Unmengen an bestehendem Code unbrauchbar sind.

Zum Vergrößern anklicken....

Nutze WPF mal, dann spürst du die Vorteile. Windows Forms ist extrem starr und kann vor allem im Design kaum angepasst werden.
Irgendwo habe ich unlängst auch eine Statistik gesehen (nein, nicht von Microsoft), lt. der Windows Forms kaum noch eine Rolle spielt und WPF längst dominiert. Das hat mich zugegeben auch überrascht.

andr_gin schrieb:

Ich habe da gar nicht an so komplexe Dinge gedacht. Es scheitert ja schon daran, dass alle Windows Systemverzeichnisse nicht vorhanden bzw. komplett wo anders sind.

Zum Vergrößern anklicken....

Damit hat man nur dann ein Problem, wenn man schlechte Codequalität abliefert, d.h. die Verzeichnisse hardcoded im Code hinterlegt.

andr_gin schrieb:

Eine Registry gibt es auch nicht.

Zum Vergrößern anklicken....

Und die ist wofür nötig? Einstellungen kann man auch in Dateien abspeichern und das wird sogar empfohlen.

andr_gin schrieb:

Von Dingen wie ODBC Verbindungen oder ActiveX Steuerelementen will ich einmal gar nicht reden.

Zum Vergrößern anklicken....

Ich dachte wir reden über .NET und nicht über .NET/ActiveX-Hybriden. Wozu braucht man heute noch ActiveX in .NET-Anwendungen?

andr_gin schrieb:

Ich kann alles, was mit Pfaden umgeht doppelt implementieren, da hier der / das Trennzeichen ist usw.

Zum Vergrößern anklicken....

Hier wird erneut schlechte Codequalität zum Bumerang. Es gibt Path.PathSeparator. Außerdem kann man sich Pfade komplett über die Klassen zusammenbauen. Wann ist es denn mal nötig, den Separator direkt selbst anzugeben?

andr_gin schrieb:

Bei Windows ist das ganz einfach geregelt: Alles, was andere User beeinflusst, darf ich nur lesen, in meinem Benutzer darf ich auch schreiben. Bei Linux ist der kleinste gemeinsame Nenner nur das alte rwx System, mit dem man nicht sonderlich weit kommt.

Zum Vergrößern anklicken....

Weiter als mit dem System, was du hier für Windows beschrieben hast. (Ich weiß, dass Windows sich nicht darauf beschränkt). Davon abgesehen, so lange du nicht für sehr alte Distributionen programmierst, hast du auch unter Linux ACLs zur Verfügung. Die sollte auch Mono passend kapseln.

Hi,

ich bin mal ganz dreißt und werfe C++ in Verbindung mit QT in den Raum. Durch das QT Framework ist die Programmierung mit C++ auch garnicht so kompliziert, wie sonst. Man bekommt halt eine ganze Menge an Bibliotheken und Klassen mitgeliefert für die man sich sonst mühsam einzelne Biblitheken raussuchen muss.
Als Entwicklungsumgebung würde sich der QT Creator anbieten, den es für Windows, Linux und Mac gibt. Alternativ kann man auch mit einem Meta-Build-Tool wie CMAKE arbeiten um sich die Projektdateien/Makefiles für den jeweiligen Compiler automatisch zu generieren.
Das Problem mit / oder \ in Dateinamen ist übrigens keines. Man kann auch unter Windows / verwenden. Wenn man also seinen ganzen Code auf / auslegt geht es auf allen Systemen. Außerdem bietet QT z.B. auch Klassen um Pfade abstrakt darzustellen, so dass man den Pfad dann abhängig vom System erstellen kann.

Grüße

Marcel

MP05 schrieb:

Hi,

ich bin mal ganz dreißt und werfe C++ in Verbindung mit QT in den Raum. Durch das QT Framework ist die Programmierung mit C++ auch garnicht so kompliziert, wie sonst. Man bekommt halt eine ganze Menge an Bibliotheken und Klassen mitgeliefert für die man sich sonst mühsam einzelne Biblitheken raussuchen muss.
Als Entwicklungsumgebung würde sich der QT Creator anbieten, den es für Windows, Linux und Mac gibt. Alternativ kann man auch mit einem Meta-Build-Tool wie CMAKE arbeiten um sich die Projektdateien/Makefiles für den jeweiligen Compiler automatisch zu generieren.
Das Problem mit / oder \ in Dateinamen ist übrigens keines. Man kann auch unter Windows / verwenden. Wenn man also seinen ganzen Code auf / auslegt geht es auf allen Systemen. Außerdem bietet QT z.B. auch Klassen um Pfade abstrakt darzustellen, so dass man den Pfad dann abhängig vom System erstellen kann.

Zum Vergrößern anklicken....

Von VB.Net auf C++? Das willst du nicht ernsthaft empfehlen, oder? Die wesentlich sinnvollere Alternative, Python in Verbindung mit PyQt4 habe ich schon genannt.

Hi,

irgendwann muss man ja mal eine richtige Programmiersprache lernen . Ne Spass, aber ich weiß nicht was alle gegen C++ haben, so schwer ist das wirklich nicht. Besonders wenn man QT verwendet.
Und ob er jetzt Python lernt oder C++ macht auch nicht den Unterschied. Der Einstieg in jede neue Sprache ist erstmal schwer.
Wenn ich ihn hätte ärgern wollen, hätte ich gesagt er soll sich Squeak runterladen und Smalltalk lernen. Das wäre ein krassser Umstieg^^

Grüße

Marcel

Slashes in Pfaden benutzt man eigntlich nur bei URLs, und da haben weder windows noch linux ein Problem.
Dinge wie Zeilentrenner (Environment.NewLine) sind gekapselt und für Dateipfade nimmt man Path.Combine oder Path.PathSeparator. - Alles andere ist grob fahrlässig, wozu den Kram von Hand zusammenstückeln, zeichen escapen und krimskrams wenn man so hilfreiche funktionen hat.
Übrigens gibt Mono sich mühe windows.Forms nachzubilde so gut es geht. Vor Mono 2.0 war das quasi kaum zu gebrauchen. Schnell ist es sowieso nicht, das liegt aber daran dass Mono Windows.Forms nachbildet indem sie das Ganze UI selbst mit den Funktionen aus System.Drawing usw. zeichnen. Nur so handeln sie sich keine GDI Abhängigkeiten ein die sie unter linux (und mac!) beissen. Eigentlich ist Monos Winforms Implementation aber auch nur dafür gedacht Programme mit möglichst wenig Portierungsaufwand bzw. direkt ans laufen zu kriegen. Wenn man unter Linux entwickeln will empfehlen die Monoianer GTK#, alleine schon der Performance wegen.

Was recht hübsche gehen soll mittlerweile ist das Hosting von ASP.Net-Anweungen auf Apaches mit Mono-Plugin. In ASP.Net (und Webentwicklung allgemein) kommt vergleichsweise selten Code zum Einsatz der in die Registry schreibt oder ActiveX-Aufrufe macht. Daher portiert sich das am einfachsten.
Unter .Net ist es übrigens nicht mehr Mode alles in die Registry zu schreiben, sondern es kommen an allen möglichen stellen XML-Basierte Configfiles zum Einsatz. Sogar VisualStudio intern arbeitet so. Eine Solution ist nichts anderes als ein XML-File das man genausogut im Editor öffnen kann.
Web.Config, machine.config usw. alles .Net spezifische, vom System selbst verwendete Configdateien.
Um die Optionen auszulesen und zu setzen gibts wieder Hilfsklassen usw.
Für reines .Net braucht man keine Registry.

Edit:
Meine Erfahrungen mit Qt sind ein paar jahre her. Damals ging es darum eine Plattformunabhängige GUI für ein Programm zu schreiben das in der Projektgruppe entwickelt wurde.
Wenn man C++ kennt ist Qt ein sehr angenehmes Toolkit. Aber einem VB-Programmierer C++, mit all seinen Tücken bei referenzierung/dereferenzierung, pointerarithmetik, delete() - aufrufen usw. anzutun ist nun wirklich etwas fies.
VB konvertiert sogar ohne zu murren implizit von String in Integer in If-Anweisungen und dergleichen Spielchen, Da ist C++ schon ne ganz andere Hausnummer.
Wenn man unbedingt Purist sein will, kann ich Borland Turbo C empfehlen. Läuft auf DOS, die IDE ist im Stile von NortonCommander gehalten (Ncurses würden die Linuxer sagen) und ein unsigned Integer kann nur bis 65535 zählen.
Strings sind nichts anderes als \0 - terminierte Char-Arrays.
Arrays müssen mit Konstanten deklariert werden, ausser man benutzt malloc() und Konsorten... - Dagegen ist jedes halbwegs brauchbare C++-Framework ein Kindergeburtstag.

Ge0rgy schrieb:

Wenn man C++ kennt ist Qt ein sehr angenehmes Toolkit. Aber einem VB-Programmierer C++, mit all seinen Tücken bei referenzierung/dereferenzierung, pointerarithmetik, delete() - aufrufen usw. anzutun ist nun wirklich etwas fies.
VB konvertiert sogar ohne zu murren implizit von String in Integer in If-Anweisungen und dergleichen Spielchen, Da ist C++ schon ne ganz andere Hausnummer.

Zum Vergrößern anklicken....

Deshalb der Hinweis auf Python. Man verbindet das Angenehme der Skriptsprache mit den Vorteilen von Qt.

PuckPoltergeist schrieb:

Deshalb der Hinweis auf Python. Man verbindet das Angenehme der Skriptsprache mit den Vorteilen von Qt.

Zum Vergrößern anklicken....

Meinetwegen auch das.
Ich kenne Python nicht wirklich, habe mich mal rudimentär mit Ruby beschäftigt aber die Schlangenfraktion kenn ich kaum. Nur die IDE "Boa Constructor" hab ich mir vor einiger Zeit mal angeschaut weil ich das Wortspiel so geil fand

Meine empfehlung in Sachen Mono rührt daher dass der Threadstarter Background in .Net zu haben scheint. Daher hielt ich die Hemmschwelle für geringer wenn er sich in bekanntem Framework bewegt, ggf. Dlls übernehmen kann usw.
Wer Qt und Mono/.Net mag kann sich das Qyoto-Projekt angucken, Mono- bzw. .Net-Bindings für .Net.
Nur mal so als Ergänzung. Das ist alles OT und Schleichwerbung...
Wollte nur klarstellen dass ich die Empfehlung nicht geleistet habe um den Threadersteller zu ärgern - so einfach Python auch sein mag und so angenehm Qt, es ist in diesem Fall beides eine neue Welt die betreten werden muss.
Mono bewegt sich zumindest größtenteils auf bekannten Pfaden für .Netianer.
Allerdings könnte der VB-Zweig wirklich etwas mehr Pflege brauchen. Man merkt da ein wenig dass dem Monoprojekt die Manpower fehlt und die Meisten Entwickler aus der C/C++ - Ecke kommen und daher C# ganz klar bevorzugt wird gegenüber VB.Net.
Ich habe beruflich mit beidem zu tun. Ein größeres Portal ist in ASP.Net/C# geschrieben, und ein anderes wurde kürzlich von asp auf ASP.Net/VB.net portiert.
Manchmal hat VB syntaktisch durchaus seine Vorzüge.

Der Threadstarter liest hier immer noch fleißig mit und freut sich über die interessanten Beiträge.
Allerdings ist er aus Zeitmangel und weils fertig werden musste immer noch ausschließlich mit VB und MS-Visual-Studio unterwegs.
Und nein, C++ werde ich mir NIE antuen, bin keine Programmierer und werde nie einer sein.

Ich würde dir an dem Punkt noch Lazarus empfhelen wollen. Ist einfach zu handhaben und basiert auf FreePascal. Ist an Delphi angelehnt und kann für Linux, Windows und MacOS compilieren (GTK, GTK2, QT, Carbon, WinCE, Win32/64). Kann mit so ziemlich jedem OS genutzt werden (sogar Gameboy Advanced seh ich grad ).

http://upload.wikimedia.org/wikipedia/commons/b/b5/Lazarus_0.9.7.png