none
Netframework 4 fehlt für Linux, MacOS und ist somit nicht plattformunabhängig RRS feed

  • Frage

  • Hallo!

     

    Java ist plattformunabhängig aber nur für das 32 bit Sun Java für Windows vorhanden j2re-1_4_2_19-windows-i586-p.exe, j2re-1_3_1_20-windows-i586-i.exe. Für das 64-bit Sun Java Windows x64: 1_4_2_19-windows-x64.exe, j2re-1_3_1_20-windows-x64.exe fehlt. Java Web Start lässt sich nicht installieren.  Das Netframework 4 für Linux, Macos fehlt. Das Netframework 4: Windows mit Erweiterung *.exe, Linux mit der Erweiterung *.tar.gz und MacOS mit der Erweiterung *.dmg sollte automatisch das Betriebssystem mit den zugehörigen Erweiterungen zuordnen und finden. Was muss gesehen damit Netframework plattformunabhängig wird? 

    Samstag, 31. Juli 2010 17:27

Antworten

  • Hallo Patrick,

    Das .NET Framework gewährleistet eine gewisse Portabilität innerhalb der Windows-Produktfamilie. Wenn Du jenseits von Windows plattformunabhängig programmieren mußt, dann könntest Du Dir vielleicht das Mono-Projekt ansehen. Es unterstützt zwar nicht die neueste .NET-Version, aber wenn es wirklich plattformunabhängig werden soll, ist dies m.E. sowieso Nebensache. Worauf es ankommt und wie Du am besten Deine Anwendung für die Portablilität vorbereitest, kannst Du u.a. hier lesen:

    MONO - Guidelines: Application Portability
    http://mono-project.com/Guidelines:Application_Portability 

    Gruß
    Marcel

     

     

    Samstag, 31. Juli 2010 18:03
  • Hallo Patrick

    Vorab, woher hast du jene JRE Java Dateinamen? (die scheinen mir gefährlich alt)
    Bist du wirklich SW-Entwickler oder Anwender (=falsches Forum)?

    Betreffend Java als (Entwickler-) Plattform:
    mit der Übernahme von sun durch Oracle ist die (kommerzielle) Zukunft von Java auf dem PC-Desktop (und insbesondere Windows) nochmals viel fraglicher geworden.
    Selbst etwa einer der 'Erfinder' von Java hat Zweifel:
    http://www.infoworld.com/d/developer-world/gosling-oracle-gets-server-side-java-confused-about-desktops-cell-phones-766

    Beachte auch,
    .NET (genauer, die hoch-portable Basis 'CLI') ist offiziell ein 'offener Standard' gemäss ECMA/ISO Normen, getragen von diversen Firmen:
    http://msdn.microsoft.com/en-us/netframework/aa569283.aspx

    Soweit ist Java gar nie gekommen, dort entscheidet über Lizenzen schlussendlich immer nur Oracle alleine, auch wenn inzwischen der Sourcecode als 'Open Source' weiterentwickelt wird!

    Teile des .NET Sources waren unter 'SSCLI' verfügbar und andere sind aktuell als 'Reference Source 'einsehbar'.
    Auf Basis der CLI-Normen und Microsofts Dokumentationen haben andere Hersteller/Communities bereits Portierungen auf weitere Plattformen vorgenommen  (wie bereits erwähntes Mono-Project).

    Wer SW spezifisch für ein Apple-OS entwickelt, ist 100% an einen Hersteller per SW _und_ absolut auch an deren HW gebunden!

    IMHO scheint die 'Plattformunabhängigkeit' in der SW-Entwicklung heute markant weniger wichtig geworden als noch einige Jahre zuvor. Denn es gibt nur noch wenige wirklich grosse, aber recht unterschiedliche Plattformen, die man daher oft am besten separat 'bedient'.

    Nach dem (IMHO:irrsinnigen) Wunsch von diversen Grössen (beginnend bei Google, MS usw) wird die 'Plattformunabhängigkeit' wohl am liebsten eh in der Cloud/im Browser stattfinden, weil dort die Kunden-Bindung/Kontrolle sowie Lizenzierung/Verrechnung (plus Werbung) am 'direktesten' ist, zu jeder Sekunde!

    Samstag, 31. Juli 2010 19:04
  • und dann auch aktuell zum Thema:

    Zitat: "Novell will mit seinen MonoTools Entwicklern das Portieren von .NET-Anwendungen auf andere Plattformen erleichtern. Dazu integriert sich das Werkzeug in Microsofts VisualStudio, der üblichen .NET-Entwicklungsumgebung. In Version 2 lassen sich damit erstmals auch Anwendungen nicht nur für Linux, sondern auch für Mac OS X und Windows erstellen. Auf allen drei Betriebssystemen springt das freie Mono für Microsofts .NET-Framework ein.

    Die Unterstützung für Mono-Anwendungen unter Windows begründet Novell vor allem mit praktischen Überlegungen: Das Portieren werde vereinfacht, wenn man nicht ständig zwischen Betriebssystemen wechseln müsse. Zur Beschleunigung der Arbeit sollen komprimierte Ressource-Dateien und eine Technik beitragen, die nur noch geänderte Files auf das Zielsystem überträgt. Das verkürze die Wartezeiten zwischen Codeänderungen und ihrem Test.

    Die MonoTools kosten zwischen 99 (Einzellizenz) und 2499 US-Dollar (Enterprise-Lizenz für fünf Entwickler). "

    [Quelle]


    ciao Frank
    Sonntag, 1. August 2010 06:03

Alle Antworten

  • Hallo Patrick,

    Das .NET Framework gewährleistet eine gewisse Portabilität innerhalb der Windows-Produktfamilie. Wenn Du jenseits von Windows plattformunabhängig programmieren mußt, dann könntest Du Dir vielleicht das Mono-Projekt ansehen. Es unterstützt zwar nicht die neueste .NET-Version, aber wenn es wirklich plattformunabhängig werden soll, ist dies m.E. sowieso Nebensache. Worauf es ankommt und wie Du am besten Deine Anwendung für die Portablilität vorbereitest, kannst Du u.a. hier lesen:

    MONO - Guidelines: Application Portability
    http://mono-project.com/Guidelines:Application_Portability 

    Gruß
    Marcel

     

     

    Samstag, 31. Juli 2010 18:03
  • Hallo Marcel Roma und andere!

    Das Monoprojekt ist in Win32 für Windows 32-bit ohne 64-bit Aufwärtskompatibilät geschrieben anstatt getrennt von Win32 für Windows 32-bit und Win64 für Windows 64-bit mit 32-bit Abwärtskompatilität. Wann werden dies die Entwickler erkennen.

    Samstag, 31. Juli 2010 19:02
  • Hallo Patrick

    Vorab, woher hast du jene JRE Java Dateinamen? (die scheinen mir gefährlich alt)
    Bist du wirklich SW-Entwickler oder Anwender (=falsches Forum)?

    Betreffend Java als (Entwickler-) Plattform:
    mit der Übernahme von sun durch Oracle ist die (kommerzielle) Zukunft von Java auf dem PC-Desktop (und insbesondere Windows) nochmals viel fraglicher geworden.
    Selbst etwa einer der 'Erfinder' von Java hat Zweifel:
    http://www.infoworld.com/d/developer-world/gosling-oracle-gets-server-side-java-confused-about-desktops-cell-phones-766

    Beachte auch,
    .NET (genauer, die hoch-portable Basis 'CLI') ist offiziell ein 'offener Standard' gemäss ECMA/ISO Normen, getragen von diversen Firmen:
    http://msdn.microsoft.com/en-us/netframework/aa569283.aspx

    Soweit ist Java gar nie gekommen, dort entscheidet über Lizenzen schlussendlich immer nur Oracle alleine, auch wenn inzwischen der Sourcecode als 'Open Source' weiterentwickelt wird!

    Teile des .NET Sources waren unter 'SSCLI' verfügbar und andere sind aktuell als 'Reference Source 'einsehbar'.
    Auf Basis der CLI-Normen und Microsofts Dokumentationen haben andere Hersteller/Communities bereits Portierungen auf weitere Plattformen vorgenommen  (wie bereits erwähntes Mono-Project).

    Wer SW spezifisch für ein Apple-OS entwickelt, ist 100% an einen Hersteller per SW _und_ absolut auch an deren HW gebunden!

    IMHO scheint die 'Plattformunabhängigkeit' in der SW-Entwicklung heute markant weniger wichtig geworden als noch einige Jahre zuvor. Denn es gibt nur noch wenige wirklich grosse, aber recht unterschiedliche Plattformen, die man daher oft am besten separat 'bedient'.

    Nach dem (IMHO:irrsinnigen) Wunsch von diversen Grössen (beginnend bei Google, MS usw) wird die 'Plattformunabhängigkeit' wohl am liebsten eh in der Cloud/im Browser stattfinden, weil dort die Kunden-Bindung/Kontrolle sowie Lizenzierung/Verrechnung (plus Werbung) am 'direktesten' ist, zu jeder Sekunde!

    Samstag, 31. Juli 2010 19:04
  • Patrick,

    wirklich 'plattformunabhängige' SW (also: non-WebBrowser based) gibt es nicht, es braucht immer erst (per einmaliger Installation) eine _plattformabhängige_ 'Runtime',  bei .NET, java, usw genauso wie beim mono-project.

    Eine 'Runtime' muss also erst mal portiert werden (= recht grosser Entwicklungsaufwand) , was nur ab einer gewissen Nachfrage (kommerziell/Community) Sinn macht.

    Deine obige Frage
      ("...in Win32 für Windows 32-bit ohne 64-bit Aufwärtskompatibilät geschrieben...")
    ist sehr unverständlich,
    aber generell gilt da auch, dass diverse aktuelle 64-Bit Betriebssysteme ebenso 32-Bit Apps ausführen können. Von dem her ist der Bedarf/Zwang für 64-Bit Apps momentan noch nicht ganz so gross.

    Das mono-project ist aber eine recht 'ordentliche' Implementation für diverese (32+64-Bit) Plattformen:
    http://www.mono-project.com/Supported_Platforms

    ich sehe nicht wer/was man da 'erkennen' soll?

    Samstag, 31. Juli 2010 19:27
  • Hallo!

    Netframework 4 für Windows 32-bit ohne 64-bit Aufwärtskompatibilät : dotnetfx40_full_win32_setup.exe, Netframework 4 für Windows 64-bit mit 32-bit Abwärtskompatilität: dotnetfx40_full_win64_setup.exe Netframework 4 für Linux: dotnetfx40_full_setup.tar.gz, Netframework 4 für Macos: dotnetfx40_full_setup.dmg, usw

    Samstag, 31. Juli 2010 20:19
  • Hallo Patrick,

    und was willst Du uns damit sagen?

    Windows, Linux/Unix und MacOS haben andere Installationsmechanismen.
    Eine Softwareverteilung ist auf jedem der Systeme anders,
    unabhängig vom .NET Framework.

    Was das geringste Problem sein sollte, denn Testen mußt Du
    jede Software für jede Plattform (und nicht nur den Setup ;-)

    Gruß Elmar

    Samstag, 31. Juli 2010 20:45
    Beantworter
  • Patrick,

    Microsoft bietet selber halt nur die 'Runtime' für die eigene Plattform (=Windows).
    Aber bei mono-project bekommt man die 'Runtime' für diverse andere Plattformen (linux, MacOS usw).

    Entscheidend ist da:
    ein Entwickler kann (unter Einhaltung aller dokumentierten Regeln der Portabilität) eine 'MeineApp.exe' erstellen (zB mit C#), welche dann unter Windows und (zB mit Mono) auf anderen Plattformen ausführbar ist.

    Da heute für die allermeisten/allerwichtigsten Desktop-Anwendungen sowieso Windows zum Zuge kommt (>90%), ist man ebenso mit einer .NET-App schon mal bestens 'positioniert'.
    Für alles darüber hinaus kann mono-project eine Lösung sein.

    Samstag, 31. Juli 2010 21:49
  • und dann auch aktuell zum Thema:

    Zitat: "Novell will mit seinen MonoTools Entwicklern das Portieren von .NET-Anwendungen auf andere Plattformen erleichtern. Dazu integriert sich das Werkzeug in Microsofts VisualStudio, der üblichen .NET-Entwicklungsumgebung. In Version 2 lassen sich damit erstmals auch Anwendungen nicht nur für Linux, sondern auch für Mac OS X und Windows erstellen. Auf allen drei Betriebssystemen springt das freie Mono für Microsofts .NET-Framework ein.

    Die Unterstützung für Mono-Anwendungen unter Windows begründet Novell vor allem mit praktischen Überlegungen: Das Portieren werde vereinfacht, wenn man nicht ständig zwischen Betriebssystemen wechseln müsse. Zur Beschleunigung der Arbeit sollen komprimierte Ressource-Dateien und eine Technik beitragen, die nur noch geänderte Files auf das Zielsystem überträgt. Das verkürze die Wartezeiten zwischen Codeänderungen und ihrem Test.

    Die MonoTools kosten zwischen 99 (Einzellizenz) und 2499 US-Dollar (Enterprise-Lizenz für fünf Entwickler). "

    [Quelle]


    ciao Frank
    Sonntag, 1. August 2010 06:03
  • Hallo!

    Die Installationsroutinen können auf das Betriebssystem angepasst werden. Natürlich ist besser Installationsroutinen für jede Betriebssystem den einfachen Mausklick einzuführen und damit könnten sich die Installationsroutinen von Netframework 4 vereinheitlicht bleiben. Du hast recht das geringste Problem sein sollte, denn Testen mußt Du
    jede Software für jede Plattform (und nicht nur den Setup ;-)

    Sonntag, 1. August 2010 13:34
  • Hallo!

    Mono sollte eher eine Visual Studio Unterstützung anbieten anstatt Visual Studio in Mono einzubinden.

    Sonntag, 1. August 2010 13:37
  • Hallo Patrick,

    Mono sollte eher eine Visual Studio Unterstützung bitten anstatt Visual Studio in Mono einzubinden.

    aber genau das machen diese Tools doch. Sie sind ein Add-In für Visual Studio und erlauben unter Visual Studio für Mono zu entwickeln. Hier wird nicht Visual Studio in Mono eingebunden.

    Hier hat Microsoft Recht auf Wettbewerbsregelverletzung zu klagen weil Mono Visual Studio einbaut ohne dass andere Herrsteller eine Chance haben.

    Das entbehrt jeder Grundlage. Naja, in Bayern haben die Ferien begonnen.. 


    Thorsten Dörfler
    Microsoft MVP Visual Basic
    vb-faq.de
    Sonntag, 1. August 2010 13:47
    Beantworter
  • Hallo,

    die Umgebungen unterscheiden sich (nicht nur) an der Stelle so massiv,
    dass ein gemeinsame Installation illusorisch ist.

    Da ich meine Entwicklerkarriere mit Unix (diverse Derivate, zu großen Teilen pre-Linux)
    begonnen habe, kann ich Dir eines mit Sicherheit sagen:
    Eine Vereinheitlichung wird so nie stattfinden.

    Mit Linux hat sich zwar eine gemeinsame Kernelbasis gebildet,
    aber man schaue sich nur die Zahl der Distributionen an.

    Zuviele Teams konkurrieren dort um die "beste Lösung".
    Anstatt die Entwicklung auf wenige zu konzentrieren,
    wird noch ein Window Manager, noch ein Installationssystem usw. usw.
    aus der Taufe gehoben.
    Und so wird viel Energie verschwendet und Vorteile verschenkt.
    Und bis heute sind viele Unix Anwendungen Komandozeilen-Anwendungen,
    weil niemand die Zeit und Energie mit den Portierungen verschwenden mag.

    So hatte ich bereits Ende der 90er einen (kleineren) 64-Bit Port
    (auf SGI IRIX ) vorgenommen, als Microsoft gerade mal NT und
    (echtes) 32 Bit einführte!
    (Und eine 32/64Bit Unterstützung für .NET ist im Vergleich dazu
    ein Sonntagsspaziergang ;-)
    Seitens SGI wurde damals eine MIPS RISC Maschine angeboten,
    die man aber dort nicht ernst nahm (zu wenig innovativ, Spielkram).
    Der NT Support ist schnell wieder gestorben und mittlerweile ist SGI
    (in der damaligen Form) Geschichte (und andere Hersteller auch)
    (Und die MIPS Patente liegen irgendwo in China, währen Intel,
    damals schnarchend langsam, sich dumm und dämlich verdient)

    In Zukunft werden die Smart/Mobile/Sonstwas-Phones,
    die nach und nach gleiche Möglichkeiten wie Desktop-Rechner haben werden,
    eine weitere Plattformvielfalt auslösen und ernsthafte Konkurrenten sein.

    Frameworks wie Java und .NET haben da IMO eine bessere Überlebenchance
    (so lange man den plattformspezifischen Teil klein halten kann).

    Moral der Geschichte:
    Schau zuerst, wo Du Dein Geld verdienen willst (oder glaubst es zu können).
    Derzeit macht es Apple mit seinen abgeschotteten Plattformen vor.
    Eine lange Liste von unterstützten Plattformen bringt vielleicht Anerkennung,
    Geld verdienen tut man damit in den wenigsten Fällen.

    Gruß Elmar
    Sonntag, 1. August 2010 14:30
    Beantworter
  • Hallo!

    Wenn Ich richtig verstehen Mono hat ein Addon für Visual Studio. Muss Ich unter Linux dass Mono mit Visul Studio programmieren und welches Tool gibt es unter Linux. Die Prirorität sollte auf Windows 64-bit legen anstatt IRIX mit 64-bit. Ich wollte die Aussage zurückziehen Hier hat Microsoft Recht auf Wettbewerbsregelverletzung zu klagen weil Mono Visual Studio einbaut ohne dass andere Herrsteller eine Chance haben. Es ist zu spät weil es geschrieben ist. Aber für ein Prozess wende Ich kein Geld auf. Linux ist überladen zu viele Anwendungen, Solaris x64 hat ein idotisches Verhalten dass 32-bit Java als Vorraussetzung ist. Wirklich stupid. MacOS kann auf einen PC nicht installiert werden. Danke für die Antworten.

      

    Montag, 2. August 2010 00:25
  • Hallo! Der Einbau von Emulatoren und die Verwendung von Emulatoren, sollte mit harten finanziellen Mittel bestraft werden. Wenn nicht Java Net4 für Windows ia64, Windows x64, Windows x86, Linux ia64, Linux x64,Linux x86. Eine lange Listen erspart das die gleiche Anwendung zweimal programmiert werden muss. Ihr zwingt mich unter Windows ia64, Windows x64, Windows x86 und GCC unter Linux ia64, Linux x64, Linux x86 die gleiche Anwendung zweimal neu programmieren muss. Datenschutzrecht und Privatphärenschutzrecht: welche Anwendung programmiert wird dass geht keinen was an.
    Mittwoch, 4. August 2010 19:53
  • Der Einbau von Emulatoren und die Verwendung von Emulatoren, sollte mit harten finanziellen Mittel bestraft werden. Wenn nicht Java Net4 für Windows ia64, Windows x64, Windows x86, Linux ia64, Linux x64,Linux x86. Eine lange Listen erspart das die gleiche Anwendung zweimal programmiert werden muss. Ihr zwingt mich unter Windows ia64, Windows x64, Windows x86 und GCC unter Linux ia64, Linux x64, Linux x86 die gleiche Anwendung zweimal neu programmieren muss. Datenschutzrecht und Privatphärenschutzrecht: welche Anwendung programmiert wird dass geht keinen was an.


    Moin Patrick,

    hast Du was falsches gefrühstückt? Irgendwie finde ich in deinen Postings grad nur ein zusammenhangsloses Gewirr von Worten. Geht das auch so, dass man irgendwas damit anfangen kann?

    Kleiner Nachtrag: Bist Du ein Bot? Wenn man sich manch anderes (älteres) Postings im Netz so anschaut, könnte man auf die Idee kommen, dass Eliza 0.7 hier postet.

     


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community
    Mittwoch, 4. August 2010 21:04
    Moderator
  • Hallo!

    Ich bin nicht Eliza 0.7.

    Einige Angelegen hat Eliza 0.7 Recht.

    Ihr habt auch Recht das Ich Geld verdienen sollte.

    Darf Ich das Netframework 4 und Java für Windows x86 portieren und Windows x64, Linux64, Linux x86 umprogrammieren? 

    Was ist ein Bot?

     

    Donnerstag, 19. August 2010 19:50
  • Moin Spambot,

    Ich bin nicht Eliza 0.7.

    Einige Angelegen hat Eliza 0.7 Recht.

    Also doch :)

    Ihr habt auch Recht das Ich Geld verdienen sollte.

    Lieber nicht.

    Darf Ich das Netframework 4 und Java für Windows x86 portieren und Windows x64, Linux64, Linux x86 umprogrammieren? 

    Nö.

    Was ist ein Bot?

    Siehe Spiegel.

    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community
    Donnerstag, 19. August 2010 21:17
    Moderator
  • Hallo!

    Mono hat früher nie richtig funktioniert, somit ist das Netframework besser.

    Ich habe keine andere Möglichlichkeiten als eure Verbote für die Umprogrammierung von Java und Netframework zu brechen weil es keine andere Lösung gibt.

    Freitag, 20. August 2010 20:28