sorry, das hört sich nach Resignation an aber mal ehrlich, meinen wir im Kontext der Entwicklung von wine und wine-staging das Gleiche?
Der .Net Moloch von MS ist und bleibt eine riesige Ansammlung von Libraries und Windows COM/COM++, DDE und etc. Komponenten.
Mal ganz im Ernst, MS liefert immer neue .Net Frameworks 1.x, 2x, 3, 3.5, 4, 4.5… und von den Fix Packs und Patch-Orgien mal ganz zu schweigen. Teilweise brauchen Programme anderer Hersteller nicht nur ein sondern mehrere Framework-Versionen.
Zudem muss man bedenken, dass all die tollen Windows Programme ohne die binären Framework-Komponenten überhaupt nicht funktionieren würden! Also schnell mal ein Windows Tool, ca. 500 K aus dem I-Net geladen um dann bei der Installation schnell noch 300 oder mehr MB .NET Framework zu installieren. Ohne Framework hat das super Tool keine Funktion und ohne binären MS Code in den „eigen“ erstellten Programmen keine Komfort-Funktionen von Windows. Schon mal eine Event-Queue oder das Window Handle Management der Windows GUI per Hand programmiert ?
Ach ja, die Freigabe der Core Variante seitens MS ist nur passiert weil MS das für seine A… Cloud braucht. Wirklich etwas damit anfangen kann anscheinend selbst das Mono Team nicht wirklich.
Wine versucht ja nicht das .NET Framework 1.2.3... nach zu programmieren
Wie auch immer, wine ist ein mächtiges Projekt und ein komplexes Betriebssystem wie Windows abzubilden eine echte Herausforderung. Zudem wird hier am lebenden, sich entwickelnden Objekt gearbeitet. Also bitte nicht Äpfel mit Birnen vergleichen.
sorry, das hört sich nach Resignation an aber mal ehrlich, meinen wir im Kontext der Entwicklung von wine und wine-staging das Gleiche? Der .Net Moloch von MS ist und bleibt eine riesige Ansammlung von Libraries und Windows COM/COM++, DDE und etc. Komponenten. Mal ganz im Ernst, MS liefert immer neue .Net Frameworks 1.x, 2x, 3, 3.5, 4, 4.5… und von den Fix Packs und Patch-Orgien mal ganz zu schweigen. Teilweise brauchen Programme anderer Hersteller nicht nur ein sondern mehrere Framework-Versionen.
Ich verstehe das Problem! meine 'Trauer' bezieht sich ja nicht auf mangelndes Engagement oder Fähigkeiten der Wine-Entwickler! Du hast ja Recht, dass die Anwendungsprogramme ständig neue net-Frameworks brauchen
Klar kann wine nichts dafür! Aber es ist fakt, dass immer mehr Programme nicht laufen, weil diese Dinge eben da sein müssen und nicht installiert werden können.
Ich habe viele Jahre eine Finanz.-Software verwendet, die tadellos unter Wine lief. Jetzt nicht mehr. Verlangt net-irgendwas, was ich nicht mehr installieren kann. Alternativprogramme, die früher liefen, tun auch nicht mehr.
IMHO ist Wine nicht dazu da, neueste Windows-verseuchte Software zum Laufen zu bekommen (mit all ihren wachsenden Abhängigkeiten zu .Not etc.), sondern um bei *alten* Systemen (also Bestand) eine Migration auf ein brauchbares Betriebssystem zu ermöglichen. Bestand würde ich übrigens fast so definieren, dass man ein System <= Windows 7 hat, dessen Systemverhalten man auf eine flexible, freie, NICHT GÄNGELNDE/ZWINGENDE Arbeitsweise *reparieren* will. (und das setzt natürlich ein Stück weit voraus, dass man schon vor seinen Windows-Emulations-Anstrengungen ein paar Schritte auf das Zielsystem zugemacht hat, durch Einsatz von LO, Inkscape, Cross-Platform-Datenbanken etc.)
Wer zu Zeiten eines hoch-integrierten *) massiven Windows-10-Spyware-Systems immer noch Windows-Software einsetzt (und oft dann noch in neuester, massiv abhängiger Form), der hat wohl so manches nicht verstanden (oder eben wirklich harte berufliche Rahmenbedingungen).
Viele Grüße von einem historisch ziemlich aktiven Wine Developer, der Windows-only-Programme heutzutage in jeder Hinsicht nicht mehr verwenden will. Gilt übrigens leider zumindest teilweise auch für Apple, Android.
Obligatorischer Schlusssatz:
Vielen Dank an CodeWeavers, Version 2.0 sieht nach großartiger Arbeit aus! (disclaimer: former CodeWeavers worker...)
*) ein *Mix* aus nötigen *und* "unnötigen" (hah!) System-Services geht auf die gleiche, *hardcoded* Mafia$oft data center IP irgendwo in Südamerika
Hi,
sorry, das hört sich nach Resignation an aber mal ehrlich, meinen wir im Kontext der Entwicklung von wine und wine-staging das Gleiche?
Der .Net Moloch von MS ist und bleibt eine riesige Ansammlung von Libraries und Windows COM/COM++, DDE und etc. Komponenten.
Mal ganz im Ernst, MS liefert immer neue .Net Frameworks 1.x, 2x, 3, 3.5, 4, 4.5… und von den Fix Packs und Patch-Orgien mal ganz zu schweigen. Teilweise brauchen Programme anderer Hersteller nicht nur ein sondern mehrere Framework-Versionen.
Zudem muss man bedenken, dass all die tollen Windows Programme ohne die binären Framework-Komponenten überhaupt nicht funktionieren würden! Also schnell mal ein Windows Tool, ca. 500 K aus dem I-Net geladen um dann bei der Installation schnell noch 300 oder mehr MB .NET Framework zu installieren. Ohne Framework hat das super Tool keine Funktion und ohne binären MS Code in den „eigen“ erstellten Programmen keine Komfort-Funktionen von Windows. Schon mal eine Event-Queue oder das Window Handle Management der Windows GUI per Hand programmiert ?
Ach ja, die Freigabe der Core Variante seitens MS ist nur passiert weil MS das für seine A… Cloud braucht. Wirklich etwas damit anfangen kann anscheinend selbst das Mono Team nicht wirklich.
Wine versucht ja nicht das .NET Framework 1.2.3... nach zu programmieren
Wie auch immer, wine ist ein mächtiges Projekt und ein komplexes Betriebssystem wie Windows abzubilden eine echte Herausforderung. Zudem wird hier am lebenden, sich entwickelnden Objekt gearbeitet. Also bitte nicht Äpfel mit Birnen vergleichen.
VG
Lars
Ich verstehe das Problem! meine 'Trauer' bezieht sich ja nicht auf mangelndes Engagement oder Fähigkeiten der Wine-Entwickler!
Du hast ja Recht, dass die Anwendungsprogramme ständig neue net-Frameworks brauchen
Klar kann wine nichts dafür! Aber es ist fakt, dass immer mehr Programme nicht laufen, weil diese Dinge eben da sein müssen und nicht installiert werden können.
Ich habe viele Jahre eine Finanz.-Software verwendet, die tadellos unter Wine lief. Jetzt nicht mehr. Verlangt net-irgendwas, was ich nicht mehr installieren kann. Alternativprogramme, die früher liefen, tun auch nicht mehr.
Nein - nicht Resignation - Bedauern.
IMHO ist Wine nicht dazu da, neueste Windows-verseuchte Software zum Laufen zu bekommen (mit all ihren wachsenden Abhängigkeiten zu .Not etc.), sondern um bei *alten* Systemen (also Bestand) eine Migration auf ein brauchbares Betriebssystem zu ermöglichen.
Bestand würde ich übrigens fast so definieren, dass man ein System <= Windows 7 hat, dessen Systemverhalten man auf eine flexible, freie, NICHT GÄNGELNDE/ZWINGENDE Arbeitsweise *reparieren* will.
(und das setzt natürlich ein Stück weit voraus, dass man schon vor seinen Windows-Emulations-Anstrengungen ein paar Schritte auf das Zielsystem zugemacht hat, durch Einsatz von LO, Inkscape, Cross-Platform-Datenbanken etc.)
Wer zu Zeiten eines hoch-integrierten *) massiven Windows-10-Spyware-Systems immer noch Windows-Software einsetzt (und oft dann noch in neuester, massiv abhängiger Form), der hat wohl so manches nicht verstanden (oder eben wirklich harte berufliche Rahmenbedingungen).
Viele Grüße von einem historisch ziemlich aktiven Wine Developer, der Windows-only-Programme heutzutage in jeder Hinsicht nicht mehr verwenden will.
Gilt übrigens leider zumindest teilweise auch für Apple, Android.
Obligatorischer Schlusssatz:
Vielen Dank an CodeWeavers, Version 2.0 sieht nach großartiger Arbeit aus!
(disclaimer: former CodeWeavers worker...)
*) ein *Mix* aus nötigen *und* "unnötigen" (hah!) System-Services geht auf die gleiche, *hardcoded* Mafia$oft data center IP irgendwo in Südamerika