Anzeige

Am Puls von Microsoft

Anzeige

Chrome-Erweiterungen und Verfügbarkeit: Was Microsoft zum neuen Edge sagt - und was nicht

Ich bin sehr gespannt, wie Microsoft das umsetzen wird und lasse mich am besten überraschen. Ich glaube, ich will es einfach nicht wahr haben, dass Microsoft schon wieder eine UWP-App begräbt und in Windows 10 kein durchgängiges Konzept und Design hinbekommt. Der Edge ist so schick und fügt sich nahtlos in Windows 10 ein. Ich arbeite so gerne damit und "spiele" mit dem Fluent Design. Ich schaue mich gleich mal bei den MacBooks um. Langsam habe ich keine Lust mehr und da bin ich lieber vorbereitet, falls der Edge zu merkwürdig wird. Alles nur meine Meinung, ich weis selbst dass der Edge nur im einstelligen Prozentbereich bei den Nutzerzahlen liegt.
 
Anzeige
Wie sieht es eigentlich mit der Sicherheit aus? Bisher war Edge eine UWP-App. Sollte nun auf Win32 umgestellt werden, bietet das dann mehr Angriffsflächen als bisher die UWP in der Sandbox? Oder lief Edge niemals in einer Sandbox, weil er zu tief im System verankert war/ist?
 
KnSN schrieb:
@Stahlreck
UWP hin und her ... Nützt einem das am Desktop etwas? Ist dadurch irgendwas anders, besser? Ich meine, nein!
Ich beobachte durchaus einen Nachteil in UWP, und dieser besteht in der nativen Rendering-Engine, zumeist auf der DirectX-API: Das klingt erst einmal falsch ausgedrückt, weil ein natives Rendering immer am besten ist, abgesehen von Ausnahmefällen, weil es für sehr wenig CPU-Load sorgt, aber um darauf konkreter einzugehen ... Nutzt Du den Rivatuner Statistics Server? Nutzt Du den MSI Afterburner? - Dieser bringt den Rivatuner Statistics Server mit sich und die meisten User bedienen sich diesem Zusatz, einige vorwiegend dessen.

Hand aufs Herz! Wem kotzt es an, dass ich die ZDF-App öffne, um eine Fußball-Partie zu schauen, oder sei es etwas vergleichbares wie Microsoft Filme & TV, und permanent blenden die Sensoren zur Hardware ein?

Anhang anzeigen 191119

Mal abgesehen von den hohen Frametimes gewinne ich aus der Sensorik keine brauchbare Erkenntnis.

Ich denke, es betrifft die meisten Anwender, ich gehe sogar von allen aus. Woran liegt das? - An der betonten Rendering-Engine der UWP-Apps, diese entweder von der DrectX-API berechnet werden oder von der OpenGL-API. Was ist die einzige Lösung, um diesen loszuwerden? Den MSI Afterburner beenden, damit beendet sich der Rivatuner Statistics Server sogleich. Was nun? Der Grafikkarte Lüfter schalten sich ab und die Grafikkarte heizt auf, mitunter in so weit, dass die Lüfter anfangen zu nerven. Ist das im Interesse der Anwender. Was geht alternativ? Nun, die Settings vom MSI Afterburner aufrufen und bei einem jeden der zehtausenden Sensoren das Häkchen zur Anzeige dieser entfernen: In rückgängig, nachdem wer sich an einem seiner Schmuddelbilder ergötzt hat, geht dieser Umstand in umkehrter Reihenfolge von vorne los, oder wie? Soll es das noch einfacher machen? Was geht am einfachsten? - Die Programmoberfläche des Rivatuner Statistics Server aufrufen, dazu muss man mitunter den MSI Afterburenr beenden, wenn dieses Tool nicht schon vorab ins Tasktray gesetzt ist, keine Standardeinstellung, und dann ein neues Profil erstellen, mit dem passenden Programm, in diesem die Anzeige der Sensoren deaktiviert wird. Nur wie soll das mit einer UWP-App gehen? - Diese besteht doch aus keinem Executable File. Was anstelle hinzufügen? - Es geht nicht!!!

Ich bin ja inzwischen schon froh, dass Microsoft Fotos mit der Einführung von der Build 1809 diese Sensoren nicht mehr anzeigt, was auch immer das Geheimnis dafür ist, denn in den Bildern ist die Anzeige der Sensoren der absolute Quatsch! Oder muss ich im Bild wissen, dass es bei 60 FPS stehengeblieben ist, dass die CPU sich vor Tortur langweilt? Sie könnte sich ja bei dem Bild-Rendering überhitzen.

So sah das mal aus, unter Build 1803 (vielleicht ist dem noch so), auch in den anderen Microsoft-Apps - und kommt hoffentlich nie wieder:
https://www.drwindows.de/windows-10-desktop/150700-erhalte-dateipfade-apps-2.html#post1633012

Ich gebe ja zu, die Performance der UWP-Apps ist dank ihrer nativ angebundenen Graphics-Engine hervorragend und entlastet mobile Geräte hervorragend, aber deswegen muss ich mir in Apps noch lange keine Sensoren antun - diese interessieren mich in Games, Benchmarks, Stresstests und so weiter, aber nicht im Video von bspw. Microsoft Filme & TV.

Fehlt mir nur noch, dass das ganze Windows \\\'ne UWP ist, oder schon der Windows Explorer ausreichend, bei dem diese Sensorik nicht herausgefiltert wird wie aktuell unter Build 1809, dann sehe ich in einem jeden Fenster diese, sogar in den Bildern auf dem Desktop. Ne\\\'!

Ich weiß ja nicht wie es mit veralteten Versionen von RivaTuner ist aber bei mir (7.2.0) gibt es ganz oben den Slider "Show On-Screen Display" und mit diesem kann man das On-Screen Display komplett ausschalten (und wieder einschalten) ohne alles neu zu konfigurieren oder Afterburner auszuschalten. Auch kann ich das Programm problemlos mit einem doppelklick öffnen bzw. wieder in den Vordergrund bewegen.
 
@Waxel
Das ist mir im Nachhinein auch eingefallen, aber zum entsprechenden Nachtrag kam es leider nicht mehr, weil ich mich indes auf ein Problemfall eines Users konzentriert habe. Manchmal treffen einem solche blitzartigen Einfälle immer erst zu spät.

Dennoch hätte mit dieser Option die Programmoberfläche des Rivatuner Statistics Server zuerst einmal auf die Schnelle geifbar sein müssen, also entweder erstmal der MSI Afterburner beendet sein müssen, dann beende es auch den Rivatuner Statistics Server, dieser dann mit seiner Programmoberfläche gestartet werden kann, oder ist es schon die ganze im Systray, aber so viele Tools brauche ich da nun auch nicht alltäglich. Aber es stimmt, was Du sagst! Dennoch kann das keine zufriedenstellende Lösung sein. Ich möchte Executable Files haben, keine UWPs, diese ich im Rivatuner Statistics Server in einem eigenständigen Profil davon ausschließen kann. ^^

Man mag es kaum glauben, aber auch der "PotPlayer" in 64-Bit-Version ist davon betroffen (die 32-Bit-Version nicht), ebenso die Hauptoberfläche des "Nero Start Launcher".

Unbenannt.PNG

PotPlayer 64 bit und Nero Start mit aktiviertem Profil des Rivatuner Statistics Server:

1.jpg 2.jpg
 
Zuletzt bearbeitet:
Wie sieht es eigentlich mit der Sicherheit aus? Bisher war Edge eine UWP-App. Sollte nun auf Win32 umgestellt werden, bietet das dann mehr Angriffsflächen als bisher die UWP in der Sandbox? Oder lief Edge niemals in einer Sandbox, weil er zu tief im System verankert war/ist?

Wird man sehen müssen. Wobei das für mich auch eine interessante Entwicklung wird. Chromium selber hat eigentlich eine relativ gute Sandboxing-Technologie, das Problem sind bei Chrome im Speziellen viel eher die Erweiterungen. Dass Microsoft allerdings kein Safebrowsing einbauen wird, sondern hier auch SmartScreen zum Einsatz kommen wird, kann man an einer Hand abzählen. Die grundlegende Technologie haben sie ja schon. Mit der Windows Defender Browser Protection haben sie im April ne entsprechende Chrome-Erweiterung veröffentlicht, sie müssten es im Prinzip also nur nativ implementieren.

Wird ohnehin spannend, wie viele Microsoft-Services sie da nativ einbauen. Sowas wie der Microsoft Translator muss da mit rein, wollen sie sich nicht zum Affen machen (wobei okay, wenn ich daran denke, was fürn Kauderwelsch der MS Translator manchmal ausspuckt. ;) ).
 
Ich wette das funktioniert nicht. Könnte mir vorstellen, dass dies auch wieder nicht angenommen wird.

Warten wir es ab aber am Ende scheitert es für die Masse wieder an der doch minimalen Optik und dem Problem mit dem suchanbieter. Neuer tab aber Google öffnet sich nicht. Dieses gehampel da immer.

Nutze den Edge selbst aber der neue Motor wird nix.
 
AT mister, das Problem wird wieder sein, dass ms erneut eine Baustelle eröffnet. Der Plan ist wieder in der Theorie prima. Von Zeit zu Zeit bemerkt man man, dass es nur langsam vorran geht und nur noch Kosmetik-Korrektur betreibt. Die Gedanken sind immer gut gemeint. Die Umsetzung ist dann wieder langsam und unvollständig.
 
Dass die Updates entsprechend nicht über den Store, sondern via Windows Update kommen, ist entsprechend auch klar.

Keine Idee, warum das für dich so klar ist. Man kann mittlerweile doch beliebige Win32 Programme über den Store verteilen. Warum soll Microsoft nicht auch einen neu entwickelten Edge auf diese Weise verteilen? Alles sonst wäre doch Unsinn!

Und ich nehme an, dass es für Microsoft kein Problem sein sollte, die eigenen Richtlinien für den Store so weit aufzuweichen, dass neben EdgeHTML basierten Apps auch ein neuer, Blink-basierender Edge erlaubt werden.

Also verteilt man über den Store alle paar Tage oder Wochen halt aktuelle Edge Builds, genau wie man das jetzt schon mit Apps oder Desktop-Programmen auch macht. Warum auch nicht? Keine Idee, was du da mit LTS schreibst. Es geht um einen Browser, eine einzelne App, nicht um irgendwelche wilden Systemupdates.
 
@Martin, "Dass UWPs auf der alten Engine sitzen bleiben..." wurde so aber auch nicht gesagt. Der Wortlaut ist "Existing UWP apps (including PWAs in the Store) will continue to use EdgeHTML/Chakra without interruption. We don't plan to shim under those with a different engine. We do expect to offer a new WebView that apps can choose to use based on the new rendering engine". Also bereits existierende. Man möchte (und das ist natürlich ebenfalls kein versprechen) schon auch die neue Engine in WebViews anbieten.
 
Keine Idee, warum das für dich so klar ist. Man kann mittlerweile doch beliebige Win32 Programme über den Store verteilen. Warum soll Microsoft nicht auch einen neu entwickelten Edge auf diese Weise verteilen? Alles sonst wäre doch Unsinn!.


Wenn die Portierungen auch so gut funktionieren würden.....Store-Office lässt den Explorer crashen

Der Browser resp dessen Technik, ist doch für mehrere Aufgaben im System verantwortlich? Möglicherweise kann eine StoreAPP die Funktionen nicht ersetzten.
 
Schon interessant zu beobachten, wie News mit vielen Konjunktiven immer wieder zu solch emotionalen Debatten führen, zumal hier noch nichts handfestes durchgedrungen ist. Es ist ein Browser, keine Weltreligion ;)
 
Keine Idee, warum das für dich so klar ist. Man kann mittlerweile doch beliebige Win32 Programme über den Store verteilen. Warum soll Microsoft nicht auch einen neu entwickelten Edge auf diese Weise verteilen? Alles sonst wäre doch Unsinn!

Und ich nehme an, dass es für Microsoft kein Problem sein sollte, die eigenen Richtlinien für den Store so weit aufzuweichen, dass neben EdgeHTML basierten Apps auch ein neuer, Blink-basierender Edge erlaubt werden.

Also verteilt man über den Store alle paar Tage oder Wochen halt aktuelle Edge Builds, genau wie man das jetzt schon mit Apps oder Desktop-Programmen auch macht. Warum auch nicht? Keine Idee, was du da mit LTS schreibst. Es geht um einen Browser, eine einzelne App, nicht um irgendwelche wilden Systemupdates.

1. Wenn ein Win32-Programm über Project Centennial in den Store kommt, ist es kein Win32-Programm mehr, sondern es basiert genauso auf UWP, wie es eine ganz normale Universal App tun würde. Microsoft Edge wird aber ein klassisches Win32-Programm, was seine eigene Engine mitbringen wird und - von den eigentlichen Windows Updates entkoppelt - seine eigenen Updates über Windows Update bekommen wird.

2. UWP-Apps bringen keine eigene Engine mit, sondern greifen auf das zurück, was ihnen Microsoft vor die Füße wirft. Das ist derzeit EdgeHTML, irgendwann in der Zukunft müssen sie das gegen Chromium und Blink tauschen, weil die alte Engine irgendwann Kompatibilitätsprobleme mit Webinhalten bekommen wird. Ersetzt Chromium das, muss es in irgendeiner Form als langzeitunterstützte Variante ähnlich tief mit Windows 10 verbunden werden, wie es EdgeHTML heute ist. Sowas existiert heute im reinen Chromium noch nicht, allerdings mit einigen Frameworks, die oft ziemlich alte Versionen von Chromium ausliefern. Es wurde ja gemunkelt, dass Electron die Rolle übernehmen könnte, bestätigt ist da noch nichts.

3. Es gäbe zwar die theoretische Möglichkeit, dass Apps wählen können, ob sie die Systemversion oder die von Microsoft Edge nehmen, aber das ist ziemlich unwahrscheinlich. Chromium bringt einen ganzen Batzen an Abhängigkeiten mit und bei Browsern ist es heute in der Regel üblich, dass die UI mit HTML und CSS auf Basis von Technologien wie React und Redux (jetzt nur als Beispiel) mit gezeichnet wird. Kurz gesagt. Die UI sitzt direkt auf der Engine auf, entsprechend kann die Shell auch nicht von der Engine losgelöst über den Store aktualisiert werden. Also bliebe Edge, weil seine UI ebenfalls auf seiner neuen Engine aufsetzen würde, nur die LTS-Version. Die soll er aber nicht bekommen, weil er mit dem aktuellen Chromium ausgeliefert werden soll.

4. Microsoft Edge ist nicht nur ein Browser, er ist genau wie der Internet Explorer eine zentral verankerte Systemapp. Punkt. An dem Status ändert sich auch mit Chromium nichts, der eine geht, der andere kommt. Wenn Edge über den Microsoft Store aktualisiert werden soll, bedeutet das, dass mit Zugriff auf die LTS-Variante vom Systemkern weiterhin nur die Shell aktualisiert werden kann. Die Engine bliebe gleich und müsste von Microsoft, weil es eine zentrale Systemkomponente ist, weiterhin über komplette Systemupgrades aufgewertet werden. Edge soll aber immer die aktuellste Engine bekommen, das geht nur, wenn seine Version vom Systemkern entkoppelt ist und eigenständig aktualisiert werden kann. Deswegen kommt für sowas schon per se nur Windows Update in Frage, ein integrierter Updater macht wenig Sinn, weil Edge eben der Systembrowser ist und bleibt, auch nach dem Wechsel.

5. Browser sind nunmal keine einfachen Programme, sondern eigenständige Plattformen. Darauf kann man nicht die gleichen Regeln anwenden wie für einen Mediaplayer oder eine Office-Suite. Abgesehen davon, dass die Entwickler eben sehr eigen ticken, gelten für Store-Apps da nochmal besondere Bedingungen.

Im Übrigen ist es jetzt auch mal gut. Ich habs euch jetzt in aller Ausführlichkeit in mehreren Threads lang und breit erklärt. Ich glaube nicht, dass das jetzt in irgendeiner Art und Weise missverstanden werden konnte. In diesem Sinne...
 
Zuletzt bearbeitet:
Kevin Kozuszek schrieb:
Im Übrigen ist es jetzt auch mal gut. Ich habs euch jetzt in aller Ausführlichkeit in mehreren Threads lang und breit erklärt. Ich glaube nicht, dass das jetzt in irgendeiner Art und Weise missverstanden werden konnte. In diesem Sinne...
Ah ja, so macht diskutieren Spass...

Naja, da du aber wohl etwas frustriert bist lassen wir es lieber. Wir sehen ja dann was passiert. Ich persönlich sehe nicht wo MS Limits hätte ob sie Edge nun als UWP oder Win32 machen würden. Beide Plattformen gehören ihnen, also kann auf beiden alles laufen was MS will...ohne Limits. Bin dann gespannt wie sie es für "PRODUCT_LITE" hinbiegen werden. Spätestens dann muss Edge ne reine UWP App sein oder dieses neue OS wird doch noch viele Altlasten von Win32 mit sich tragen müssen...und wäre somit ja dann doch wieder Windows.

Schauen wir mal, ich hoffe das MS immerhin die gute Integration von Edge in W10 mitnehmen wird und den Tablet Mode nicht vergisst.
 
Wieso wird hier so engagiert diskutiert? Jeder, der hier mitschreibt, kann lediglich den Einblick haben, den ein Entwickler von Windows-Anwendungen, UWP-Apps, usw. haben kann. Das ist nicht mal ein Bruchteil des Wissens der Microsoft-Entwickler. Die können ob mit oder ohne UWP viel mehr anstellen, als sich das jeder hier vorstellen kann. Selbst Fluent Design oder zumindest etwas, das so aussieht, dürfte für die auch ohne UWP möglich sein.
 
Bin dann gespannt wie sie es für "PRODUCT_LITE" hinbiegen werden. Spätestens dann muss Edge ne reine UWP App sein oder dieses neue OS wird doch noch viele Altlasten von Win32 mit sich tragen müssen.

Sind wir jetzt schon so sicher, was Product Lite genau ist? M.E waren es bisher lediglich Spekulationen was sich hinter dieser Bezeichnung verbergen könnte.
 
@Stahlreck
Ich habe kein Problem, mit euch zu diskutieren, aber wenn ich euch x-mal schon vorgekaut habe, dass die Umsetzung von Edge als Win32 von mehreren Leuten bestätigt wurde und ihr auch wissen solltet, dass eine Win32-Anwendung, die über die Bridge in den Store kommt, dann eine UWP- und damit eben keine Win32-Anwendung mehr ist, dann vergeht mir auch irgendwann die Lust. Anstatt immer nur gegenan zu stinken, könnte man gewisse Dinge auch einfach mal als gegeben hinnehmen und so stehen lassen, solange Microsoft nicht auf der Build oder irgendwo anders was anderes sagt oder es durch die Magazine rauskommt. Punkt. Ob Edge dann gleichzeitig bei "Windows Lite" eine echte UWP-App sein muss, ist auch noch nicht gesagt. Die Grenzen zwischen .appx und .exe/.msi werden durch das neue .msix-Format gerade aufgebrochen und es ist mehr als möglich, dass Edge auf diese Weise eingebunden wird. Dann hat er die Vorteile aus beiden Welten, allerdings wird ihm Chromium, sofern das nicht gesplittet wird (Chromium über Windows Update, die Shell über den Store) oder das Lite-OS komplett um Edge herum gebaut wird (was wegen der angedachten Unterstützung für UWP eher unwahrscheinlich wäre), immer noch Grenzen setzen.

Ihr verkennt eine Sache ganz erheblich: Microsoft Edge in seiner jetzigen Form ist einer von ganz, ganz wenigen Browsern, wo die Shell, also die GUI, noch völlig von der eigentlichen Engine getrennt ist und das entsprechend getrennt aktualisiert werden könnte. Bei den meisten Chromium-Browsern und spätestens seit Quantum auch zum überwiegenden Teil bei den Gecko-Vertretern wird die UI direkt mit HTML und CSS gezeichnet und liegt damit direkt auf der Engine auf, ist also untrennbar mit ihr verbunden. Würde Microsoft Edge so über den Store kommen, müssten sie praktisch die gesamte Engine nehmen und über den Store bereitstellen. Mag bei Edge dann noch klappen, hilft aber anderen Store-Apps, die dann Blink zum Rendern irgendwann nutzen sollen, nicht weiter. Die Funktionsfähigkeit der jeweiligen UI ist abhängig von der jeweiligen Chromium-Version, mit der es ausgeliefert wurde. Würde Microsoft also keine Blink-Version entwickeln, die tief im System verankert ist und so aktualisiert wird wie EdgeHTML heute, würden solche Apps irgendwann ihre Funktionsfähigkeit verlieren. Wäre für Apps, die auf Electron aufbauen und somit eine feste Chromium-Version hätten, noch verschmerzbar, da gebe ich dir recht, aber nicht jeder hat die Ressourcen, eine eigene Engine einzubinden. Es verlassen sich nicht umsonst viele Anwendungen auf das, was Windows da dann selber bereitstellt. Das meinte ich mit LTS.

Auch wenn Edge nachher auf Chromium basieren wird, ist und bleibt er eine tief verankerte Systemkomponente und ist deswegen mit normalen Browsern wie Chrome und Firefox nicht ansatzweise vergleichbar. Worauf ich hoffe, ist, dass sie Edge von Anfang an als .msix-Paket umsetzen, dann wäre es ein Hybrid und wir müssten diese Diskussion hier gar nicht weiter führen, weil sich dann gewisse Spielräume ergeben. Trotzdem wäre eine Verteilung über Windows Update dann wesentlich wahrscheinlicher, allerdings hat Edge dann den Vorteil, dass er - den Store ausgenommen - trotzdem weitgehend alle Möglichkeiten von UWP zumindest ansatzweise mit nutzen könnte.

Ihr macht euch das manchmal ziemlich einfach, Leute. Ich bin weißgott kritikfähig und gestehe auch gerne ein, wenn ich einen Fehler gemacht habe oder sich etwas anders entwickelt hat. Aber weder bin ich ein Tonband, was sich alle paar Stunden gerne wiederholt, noch lasse ich mich halbwegs als Dummchen hinstellen, der nicht weiss, wovon er redet. Bevor ich etwas rausposaune, könnt ihr euch sicher sein, dass ich intensiv recherchiere und bei Unklarheiten auch nachfrage. Genau das habe ich hier auch getan, ansonsten würde ich das nicht sagen.

Und damit ist es jetzt auch gut.
 
Zuletzt bearbeitet:
..., dass eine Win32-Anwendung, die über die Bridge in den Store kommt, dann eine UWP- und damit eben keine Win32-Anwendung mehr ist, ...

Äh? Nein!

Eine Win32-Anwendung (WinAPI), die über die Desktop Bridge in den Store kommt ist nach wie vor eine Win32-Anwednung; die lediglich dann in einen App-Container gepackt wird und somit über den Store verteilt werden kann und so natürlich der Installer entfällt. Die Abhängigkeiten zur Win32 API sowie Architektur bleiben unverändert. Erst wenn der Entwickler im Nachhinein seine App umschreibt, wird die Win32-Anwedung über einen sehr langen Prozess irgendwann mal zu einer reinen UWP-App die dann UWP-APIs (WinRT / .Net Standard 2.0) nutzt und dadurch auf diversen Geräte-Plattformen sowie Architekturen lauffähig sein kann.

Die Desktop Bridge kann keine Win32-Anwenungen in UWP-Apps konvertieren! 
 
@STP
Gut, dann liege ich in diesem Punkt falsch, danke für die Aufklärung. Trotzdem ändert das an dem, was man bisher über den neuen Edge-Browser in Erfahrung bringen konnte, rein gar nichts.
 
Anzeige
Oben