DLL systemunabhängig?

[Angel4585]

Hallo,

ich soll für eine Software einen Funktionskern schreiben der Systemunabhängig gehalten werden soll.

Ist eine DLL Systemunabhängig? Oder wie sollte ich sonst einen unabhängigen Kern schreiben?

Danke schonmal für eure Antworten

:angel:

[gsh]

Was meinst du damit genau?
Von der Hardware her?
oder vom Betreibssytem?
oder von was soll die DLL unabhängig sein?

[Luckie]

Eine DLL ist auch nichts anderes als eine Datei im PE32-Dateiformat und somit zumindest Windows spezifisch.

[Angel4585]

Und wie kann ich dann einen systemunabhängigen Funktionskern schaffen? :shock:

[Luckie]

Wenn du Betriebssystem unabhängig meinst und das auf Windows und Linux beziehst, gar nicht.

[Elvis]

Zitat:

Zitat von Angel4585

Und wie kann ich dann einen systemunabhängigen Funktionskern schaffen? :shock:

Ich glaube, dass sich dein hier Chef in Manager speak geübt hat und du einfach nur nicken und nix anderes tun müsstest als was du jetzt schon machst.
Falls dem nicht so ist sollte er dir erklären was er mit System meint. Meint er damit dass man die Funktionalität auch in anderen Softwaresystem verwenden können sollte, dass sie unabhängig von einem vielleicht zerfriemelten System ist, oder soll sie plattform-unabhängig sein.
Erstes und zweites lässt sich noch mit Delphi erledigen, für letzteres gäbe es FreePascal.

[Angel4585]

echt jetzt? Es gibt nicht die Möglichkeit zB alles in C++ zu machen und dann auf Windows und Linux auf die selben Dinge zuzugreifen? Also es können schon unterschiedliche Dateien sein, aber der Quellcode sollte nur einmalig vorkommen.

Das einzige was es dann gäbe wäre wohl das komplette in Java zu programmieren oder?

@Elvis alle drei Punkte am besten :D

[Luckie]

Zitat:

Zitat von Angel4585

aber der Quellcode sollte nur einmalig vorkommen.

So lange du keine betriebssystemspezifischen Funktionen benutzt geht das natürlich. Einmal unter Linux und einmal unter Windows kompilieren.

[Elvis]

Zitat:

Zitat von Angel4585

Das einzige was es dann gäbe wäre wohl das komplette in Java zu programmieren oder?

Äpfel <-> Birnen.
Du redest von einer DDL, also einer Bibliothek, die Funktionen enthält. Und diese Implementierungen würdest du gerne von Woanders benutzen können?
Solange der benutzende keine Java-App ist, dürfte sich eine Java-Bibliothek als KRAMPF erweisen um die Funktionen auszuführen.

Zitat:

@Elvis alle drei Punkte am besten :D

Eine native DLL mit einem XPlattform-Compiler erzeugen, der zu dem jetzigen Code sehr kompatibel ist, wäre mit FPC möglich.
FPC generiert größere Binaries als Delphi, aber der Compiler ist viel strenger und die Binaries selbst laufen oftmals auch noch schneller :).
Die GUI kannst du ja in Delphi lassen, auf der Windows seite. Für andere Plattformen kannst du dann eine andere GUI bauen, zum Beispiel mit Lazarus.

[Phoenix]

Zitat:

Zitat von Angel4585

Das einzige was es dann gäbe wäre wohl das komplette in Java zu programmieren oder?

Ieh. Java. *bwarks*

.NET ist da ne gute Alternative.

[Elvis]

Zitat:

Zitat von Phoenix

.NET ist da ne gute Alternative.

Wenn es eine komplette XPlattform-App werden soll, dann wäre Java sogar eine exzellente Wahl.
Aber wie es aussieht soll das ganze nativ bleiben (da bereits eine native GUI existiert, oder? ) und da fliegen sowohl Java als auch Mono raus.

[Angel4585]

ne es existiert noch keine GUI, wenn Java geeignet wäre würde man Java nehmen, aber es wird als "zu lahm" angesehen.. ich mag Java eigentlich :D

[Elvis]

Zitat:

Zitat von Angel4585

ne es existiert noch keine GUI, wenn Java geeignet wäre würde man Java nehmen, aber es wird als "zu lahm" angesehen.. ich mag Java eigentlich :D

Selbst Swing ist mit Java6 schneller als SWF oder WPF, Javas SWT hingegen war schon von Anfang an schneller als jedes .Net GUI Framework. Also was immer von der MS-Fanboy-Ecke zum Thema .net GUIs wären schneller kommt, kannst du getrost vergessen.
Mache dir selbst ein Bild von Lazarus und Java um herauszufinden was dir besser gefällt.

Aber wie gesagt, eine Java Bibliothek in einer nativen Anwendung zu benutzen wird so abartig dass
es zu einem Kündigungsgrund deinerseits werden kann.
Überlege dir also genau wie das gemeint war, frage besser ob da überhaupt etwas gemeint war (@Manager, oben).
Soll es as Bibliothek zur Verfügung stehen, sollte es eine native DLL sein. Die GUI kannst du aber immer noch in Java schreiben. (Von Java eine native Lib zu benutzen ist einfacher als andersrum, etwa um den Faktor 10^100)

[Angel4585]

ne es sollte ein Funktionskern für unsere neue Software sein, es ist noch nicht klar in welcher Sprache das programmiert werden soll, aber es ist klar das es auch auf Linux laufen soll.
Die Frage ist jetzt: Alles in Java, wobei dann ein Thema wie ein Dienst etwas schwierig sein dürfte, oder eben eine Bibliothek in Delphi/C++ und für jedes System ne eigene GUI.

[OregonGhost]

[OT]
Also, auf meinen Rechnern sind WPF und Windows Forms wesentlich schneller als jede Java-Anwendung, die ich bisher gesehen habe, während Java, egal ob AWT, SWT oder sonst was immer dahinkriecht.
[/OT]

Schonmal Qt ausprobiert? C++, "plattformunabhängig" (Unix/X11, MacOS X Native und Win32 Native), ein Quellcode für alle Plattformen und eine relativ gute Bibliothek, die den C++-STL-Murks und auch Boost überflüssig macht.

[Phoenix]

Als ob ich mit dem Performance-Argument kommen würde... :lol: . Es geht simpel um Wartbarkeit der Anwendungen.

Java wird inzwischen von QM-Unternehmen (imho zurecht) als so unwartbar angesehen, dass die z.B. Pharmaunternehmen die ISO-Zertifizierung nur noch unter der Auflage erneut zuteilen, bestehende Java-Anwendungen durch wartbare Anwendungen abzulösen. Befolgt das Unternehmen die Auflage nicht, ist das QS-Zertifikat wech.

Das war z.B. bei Phizer und Sanofi Aventis schon so.

[Angel4585]

warum soll Java unwartbar sein? :gruebel:
Also ich mach jetzt seit inigen Monaten Java. Es stimmt schon das wenn ich von 1.4 auf 1.6 gehe sich einiges ändert, aber wenn ich bei 1.6 bleibe über Jahre hinweg, ändert sich nichts an Funktionen und man muss dann wenn man die Version wechselt nur einmal alles überarbeiten, was relativ schnell geht.(Naja kanns chon paar Tage/Wochen gehn wenns viel ist, klar)
Aber wie gesagt: Ich find mich sehr gut in Java zurecht.

[Der_Unwissende]

Zitat:

Zitat von Angel4585

Es stimmt schon das wenn ich von 1.4 auf 1.6 gehe sich einiges ändert, aber wenn ich bei 1.6

Hi,
eine Geschichte die MS bisher auch nicht besser gemacht hat, schauen wir uns mal die Vorgänger von .net (COM, COM+, DCOM, DDE) an und die Entwicklung .net 1.x, 2.x, 3.x (ok 3 ist ja nur ein leicht erweitertes 2).
Was die Geschwindigkeit angeht, so ist das eh immer ein (langweilig altes) Argument, dass man mal mit heutigen JITs betrachten sollte, da relativiert sich dann doch einiges. Nebenbei gibt es auch Qt mittlerweile für Java. Qt läuft dabei nativ und wird über eine JNI (Java Native Inteface) - Brücke angesprochen. An sich kannst Du aus Java heraus eben auch native Programme in dyn. linkbaren Bibliotheken ablegen und diese nativ ausführen. Für den Aufruf und das marshaling geht natürlich etwas Zeit drauf, aber das Problem hast Du auch wenn Du Objekte verwendest.

.net ist leider als Plattformunabhängige Plattform noch ungeeignet, da es keine Implementierung für genügend Plattformen gibt (über die Wartbarkeit von Managed C++ könnte man z.B. auch streiten).

Aber es gibt trotzdem Alternativen zu Haskell, z.B. kannst Du auch auf Python, Haskell oder die universelle TuringMachine zurückgreifen (ok, das mit dem unendlichen Speicher wird schwer), was am besten geeignet ist sollte nicht pauschal festgelegt werden. Vielmehr hat jede Sprache so ihre Nische in der sie besonders toll ist (oder auch nicht).

Gruß Der Unwissende

[Angel4585]

OK, das heisst man müsste Aufgaben definieren die die Software tun soll und dann schauen welche Sprache für diesen Bereich am geeignetsten ist?

In unserem Beispiel hiesse das, das die Software sehr viele Dateien vergleicht und kopiert.
Ausserdem soll sie als Dienst laufen und übre Netzwerk kommunizieren.

Ich weis das Java schneller als C++ ist wenns darum geht Objekte zu erzeugen. da es viele Dateien sein werden und jede vmtl ein Objekt sein wird, wäre das evtl ein Vorteil oder?
Allerdings wie es mit Java auf Dateiebene aussieht weis ich nicht.

[Der_Unwissende]

Zitat:

Zitat von Angel4585

OK, das heisst man müsste Aufgaben definieren die die Software tun soll und dann schauen welche Sprache für diesen Bereich am geeignetsten ist?

Na ja, etwas mehr sollte man schon berücksichtigen. Natürlich ist es auch wichtig, welche Sprachen im Haus verwendet werden. Wenn es z.B. total super in Brainfuck gelöst werden könnte (glaube nicht, dass irgendwas gut in der Sprache lösbar ist), könnte der Code aber auf die meisten Leute doch etwas schwer Les-/Wartbar wirken. Auch wirst Du kaum für jedes Programm eine neue Sprache lernen wollen. Hast Du im Haus eine Abteilung, die für die Qualitätssicherung zuständig ist, so wirst Du sicherlich nichts nehmen dürfen, was die nicht verstehen (Verifikation des Codes wäre sonst etwas schwer).

Zitat:

Zitat von Angel4585

In unserem Beispiel hiesse das, das die Software sehr viele Dateien vergleicht und kopiert.
Ausserdem soll sie als Dienst laufen und übre Netzwerk kommunizieren.

Also was Dateien angeht, da würde ich fast mal behaupten, dass der Java-Code ähnlich flink wie der C++ Code arbeiten sollte. Es hängt hier i.d.R. viel mehr vom Code selbst (was kann der Entwickler, was berücksichtigt er, ...) ab als von der verwendeten Sprache. Ich bekomme sicherlich ein Programm in C langsamer als das Äquivalent in einer interpretierten Sprache hin, ich muss eben nur schlecht genug arbeiten. Ein pauschales schneller gibt es halt nicht. Wichtiger ist deshalb eher, ob Du besser mit C++ oder Java zurecht kommst (wo es mehr Komponenten und Bibliotheken gibt, die Du verwenden möchtest, ...).
Netzwerk ist immer so ein Wort, wo viele Leute an Java denken. Java ist nun mal mit Netzwerken groß geworden und bietet von sich aus gleich eine ganze Menge schöner gekapselter Funktionen rund um das Thema Netzwerk. In C++ ist das eventuell (kenn mich da nicht so aus) anders, hier kann es sein, dass eher auf die direkte Schnittstelle des OS zurückgegriffen werden würde. Qt abstrahiert davon, stellt auch in C++ eine unabhängige Schnittstelle für solche Dinge bereit (vielleicht hat C++ die ja ohnehin). Die .nets dürften hingegen ähnlich wie Java arbeiten (aber kaum unter Linux voll unterstützt werden).

Zitat:

Zitat von Angel4585

Ich weis das Java schneller als C++ ist wenns darum geht Objekte zu erzeugen. da es viele Dateien sein werden und jede vmtl ein Objekt sein wird, wäre das evtl ein Vorteil oder?

Ok, sagen wir mal dem ist so, der Hauptteil der Zeit vergeht aber nicht beim Erzeugen (und Freigeben) von Objekten, wichtiger erscheint doch häufig die Zeit die bei der Ausführung der Methoden vergeht, da kann das Bild dann anders aussehen (und diese Zeit dürfte die des Erzeugen häufig dominieren).

[Angel4585]

Und in welchen Bereichen ist Java jetzt genausoschnell oder gar schneller und wo ist es langsamer? :gruebel:

[OregonGhost]

Da es kaum Vergleichstests gibt, deren Vergleichsmethoden nicht irgendwie seltsam anmuten, wirst du wohl oder übel selbst testen müssen.
Was das "Objekterzeugen in Java ist schneller als in C++" angeht, das ist nur ein Teil der Wahrheit, jetzt mal ganz abgesehen davon, dass es unzählige C++-Compiler gibt. Objekte auf dem Heap zu erzeugen und zu zerstören ist in Java ebenso wie in C# und ähnlichen Sprachen schneller als in C++, wenn man sich nicht ums Speichermanagement kümmert. Aber in C++ kann man Objekte auch auf dem Stack erzeugen (das geht in Java überhaupt nicht, in C# nur, wenn die jeweilige "Klasse" dafür entworfen wurde), und man kann sein eigenes Speichermanagement zusammenbauen, wie z.B. einen MemoryPool (im Endeffekt ist das, was Java macht, auch nicht viel anders). Wenn du also ungefähr weißt, was du tust, kannst du nur durch deine eigenen Tests wirklich Performance-Unterschiede herausfinden und diese sind dann, mehr oder weniger, für dein Problem spezifisch. Von bestimmten Dingen abgesehen kann man kaum sagen, dass eine bestimmte Sprache schneller als eine andere ist.

Was C++ angeht, die C++-Bibliothek bringt in der bisherigen Standardversion ungefähr nichts mit, außer einer Hand voll umständlich zu verwendender Container und Algorithmen und einer String-Klasse. Das Ganze nennt man dann STL, stuft es als Grundwissen ein und hofft, es nie benutzen zu müssen. Mit Boost wird dann aus C++ schon eine einigermaßen benutzbare Sprache, weil Boost viele Features hinzufügt, die andere Sprachen auch können (Delegaten, Threads, Smartpointer usw.) Wirklich viel Spaß mit C++ hat man in meinen Augen aber nur mit einer Bibliothek wie Qt, die so ziemlich alles, was man benötigt, mitbringt, in einer Form, die angenehm zu verwenden und plattformunabhängig ist. Qt ist unangenehmerweise für kommerzielle Anwendungen nicht kostenlos (aber ich finde, es ist das Geld wert ;)). Zumindest anschauen solltest du es dir als Alternative zu Java auf jeden Fall.

[Der_Unwissende]

Zitat:

Zitat von Angel4585

Und in welchen Bereichen ist Java jetzt genausoschnell oder gar schneller und wo ist es langsamer? :gruebel:

Kann mich nur wiederholen, kann man nicht pauschal sagen, kommt auf den Code an. An sich ist Java (bei wirklich gleichwertigen Datenstrukturen und Algorithmen) immer etwas langsamer als ein gleichwertiges natives Programm. Häufig wird hier einfach gesagt, dass das daran liegt, dass Java-Code in einer virtuellen Maschine ausgeführt wird. Der Java Compiler (javac) erstellt nur Objektcode, der eben auf dieser virtuellen Maschine ausgeführt wird. Überall, wo es eine Implementierung der virtuellen Maschine gibt, ist dann der Code auch lauffähig (genau das macht die Plattformunabhängigkeit aus). .net verwendet das gleiche Prinzip. Anders als bei einem Interpreter ist der Code dabei schon in einen assembler übersetzt, die Korrektheit schon geprüft, die Anweisungen sind schon kodiert.
Java ist also schon mal schneller, als wenn Du wiederum exakt gleiche Algorithmen und Datenstrukturen in einem Interpreter ausführst. Da Du aber i.d.R. keine Architektur besitzt, die der der JVM entspricht, muss der Code noch in solche übersetzt werden, der von Deiner Maschine verstanden wird. Hier kommt ein Just In Time Compiler (JIT) zum Einsatz. Während dieser die Instruktionen einliest versucht der diese auf Dein System zu optimieren und übersetzt die für die Zielplattform, wo sie dann auch ausgeführt werden. Das kostet natürlich etwas Zeit und ist damit langsamer als ein gleichartiges Programm, dass schon komplett für diese Zielplattform gelinkt vorliegt. Letzteres kann eben direkt ausgeführt werden, die Übersetzung durch den JIT entfällt.

Jetzt ist es aber nicht so, dass alle Sprachen exakt gleich arbeiten. So könnte ich immer behaupten, dass C Code schneller ist als solche in ObjektOrientierter C++ Code. Einfach weil C keine Objekte kennt und diese einen gewissen Overhead mit sich bringen. Auch kümmert sich C recht wenig um Typsicherheit, in C++ sieht das anders aus. Jedes try... except bedeutet eine Verlangsamung, Indirektionen durch die Verwendung von Objekten und insbesondere bei virtuellen Methoden kommen dann noch hinzu.
Nichts desto trotz wird häufig auch Objekt Orientiert programmiert, da dies ganz andere Möglichkeiten und Vorteile als die rein imperative Programmierung bietet. Ein schönes Beispiel ist vielleicht gleich J2EE (Java 2 Enterprise Edition), deren Vorteile erst durch die OOP erreicht werden, z.B. die einfache Skalierung und die automatische Nebenläufigkeit.
Aber es gibt noch weitere Unterschiede, so verwaltet Java seinen Speicher selbst, es gibt keine (expliziten) Destruktoren. Während Du in C/C++ einfach mal einen Destruktor-Aufruf vergessen kannst und Dir damit den Speicher zumüllst, wird in Java von Zeit zu Zeit (läuft asynchron) die Garbage Collection aufgerufen, die einfach allen Speicher, der nicht mehr benötigt wird, aufräumt. Hast Du einen solchen Destruktor an einer ungünstigen Stelle vergessen, dann dürfte ein voller Speicher Dein Programm ordentlicher ausbremsen als vieles anderes.

Zudem sind natürlich die Bibliotheken in Java und C++ (oder anderen Sprachen) auch unterschiedliche aufgebaut. Je nach Implementierung (die muss auch nicht in jeder Version gleich sein, ein Vorteil von Abstraktion), kann dann die eine oder andere Sprache eine deutlich schnellere Implementierung verwenden.
Die Unterschiede zwischen C++ und Java mögen hier für die meisten Programme noch gut messbar sein, aber nicht unbedingt spürbar! Da spielen andere Faktoren eine viel wichtigere Rolle. Jeder sich bewegende Fortschrittsbalken bzw. sein Fehlen macht psychologisch doch deutlich mehr aus (da ist der Gefühlte Unterschied immens!)

[add]
Kein roter Kasten, na toll.

Zitat:

Zitat von OregonGhost

Zumindest anschauen solltest du es dir als Alternative zu Java auf jeden Fall.

Oder wie bereits erwähnt auch als Ergänzung!
[/add]

[Angel4585]

Weitere Funktion des Programms: ein Programm soll als Dienst/Daemon laufen. Gibts da Vor-/Nachteile bei Java/C++?

[OregonGhost]

Sagen wir's so, es ist vielleicht unglücklich, wenn ein Dienst noch gleich eine VM mit sich rumschleppt. Kann ein Javaprogramm überhaupt als Dienst gestartet werden?

[Angel4585]

Ja es gibt einen Wrapper mit der man die als Dienst starten kann

[Der_Unwissende]

Zitat:

Zitat von OregonGhost

Kann ein Javaprogramm überhaupt als Dienst gestartet werden?

Ein Java-Programm kann auch für das Zielsystem gelinkt werden, geht zwar nicht mit dem SUN-JDK und macht das Kompilat plattformabhängig, aber das gilt nicht für den Source!