News Windows 10 Insider Preview: Build 19564 mit erweitertem GPU-Menü freigegeben

[I'm unknown]

Ich denke Du weißt schon sehr genau, dass Microsoft sich seit jeher sehr wortkarg mit Informationen zum Kernel begibt.

Genau deshalb bin ich kein Fan von Vermutungen alles wird schon neu sein weil ein paar Infos bekannt sind (ob die Informationen immer korrekt sind ist dann die nächste Frage).

Damit erhält auch @xexex Aussage eine gewisse Gewichtung. Ein Windows Kernel ohne w32 Unterbau lässt sich schlecht ohne einen generellen re-write des Kernel erklären oder annehmen. Ich denke soweit gehst Du mit, oder?

Und genau weil es kaum brauchbare Infos gibt weiß von uns keiner ob nur die API nach außen nicht sichtbar ist oder es ein "neuer" (anderer) Kernel ist .

 

[Sun_set_1]

Und genau weil es kaum brauchbare Infos gibt weiß von uns keiner ob nur die API nach außen nicht sichtbar ist oder es ein "neuer" (anderer) Kernel ist

Ach komm, nichtmal Microsoft wäre so bescheuert eine API nur umzuschreiben, damit Sie nach außen hin neu aussieht. Du mapst doch auch keine REST auf eine XML-Schnitstelle per Script, damit Du nach außen hin sagen kannst: “Ich hab ne neue REST“ 😂

Das wäre mehr Arbeit, als das Interface nativ anzuflanschen. Das macht doch wirklich keiner.

Aber ja, zu sagen das 100% der Code-Basis neu sind, ist auch Spekulation. Da ist allerdings die Frage was man als “Neu“ definiert. Alles ab 95? Alles ab NT? Alles ab Win7 (NewNT)? Die Kernelentwicklung ist ja nen laufendes Projekt, von daher ist da jedweder Determinismus arg relativ.

 

[I'm unknown]

Ach komm, nichtmal Microsoft wäre so bescheuert eine API nur umzuschreiben, damit Sie nach außen hin neu aussieht.

So war es auch nicht gemeint. Habe nur meine Zweifel, dass MS dann einen Kernel für Core OS und einen fürs "alte" Windows pflegt. Also Neuerungen rein, Win32 aber nicht (komplett) raus.

Da ist allerdings die Frage was man als “Neu“ definiert.

In Foren wird gerne mal herum posaunt es sei mit einer neuen Version ja alles neu. So stimmt es einfach nicht, nur weil ein paar Details überarbeitet wurden. Ab wann was neu ist finde ich als berechtigte Frage, über die wir bei Closed source jedoch wirklich nur noch spekulieren können .

Die Kernelentwicklung ist ja nen laufendes Projekt, von daher ist da jedweder Determinismus arg relativ.

Richtig - und beim Windows-Kernel nach wie vor eine vergleichsweise sehr zähe und langsame Angelegenheit.

 

[xexex]

Aber ja, zu sagen das 100% der Code-Basis neu sind, ist auch Spekulation.

Man sollte die Diskussion schon im ganzen betrachten, meine Aussage bezog sich hierauf.

Mal abgesehen von dem "32bit ist nicht mehr Zeitgemäß" Quatsch, hat Microsoft mit dem OneCore genau das gemacht. Man hat den Kernel von den ganzen früheren Altlasten befreit, alles was auf das "klassische" Windows ausgelegt war entfernt oder in der Usermode verlagert und der Kernel an sich komplett entschlackt und skalierbar gemacht.

Anders wäre letztlich auch der Einsatz des gleichen Kernels von IoT und Hololens bis zum Datacenter Server nicht möglich, noch bis "vor kurzem" hatte Microsoft dafür zig verschiedene Kernel gebraucht. Wer meint das man dafür nur ein paar Zeilen am bestehenden Kernel umzuschreiben braucht, der soll in diesem Glauben leben.

Also Neuerungen rein, Win32 aber nicht (komplett) raus.

Win32 ist nur ein Subsystem von vielen. Basieren die Hololens Anwendungen auf Win32? Waren die Apps für Windows 10 Mobile Win32? Ich glaube die Frage kannst du dir selbst beantworten.

 

[new Account()]

Habe nur meine Zweifel, dass MS dann einen Kernel für Core OS und einen fürs "alte" Windows pflegt. Also Neuerungen rein, Win32 aber nicht (komplett) raus.

Bewege mich jetzt auf dünnem Eis, aber afaik ist Win32 nur eine API. Von daher kann darunter beliebiges liegen:

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

(Link mit TimeStamp)

Richtig - und beim Windows-Kernel nach wie vor eine vergleichsweise sehr zähe und langsame Angelegenheit.

?
Woher ziehst du das denn jetzt raus?

 

[I'm unknown]

hat Microsoft mit dem OneCore genau das gemacht. Man hat den Kernel von den ganzen früheren Altlasten befreit, alles was auf das "klassische" Windows ausgelegt war entfernt oder in der Usermode verlagert und der Kernel an sich komplett entschlackt und skalierbar gemacht.

Und gibt es eine brauchbare Quelle welche genau das belegt?

Wer meint das man dafür nur ein paar Zeilen am bestehenden Kernel umzuschreiben braucht, der soll in diesem Glauben leben.

Das kann mangels Code nur ein Kernel-Entwickler von MS beantworten. Ich sage es ja nicht gerne, hast du über das Ausmaß eine brauchbare Quelle?

Ergänzung (13. Februar 2020)

Win32 ist nur ein Subsystem von vielen. Basieren die Hololens Anwendungen auf Win32? Waren die Apps für Windows 10 Mobile Win32? Ich glaube die Frage kannst du dir selbst beantworten.

Und du kannst belegen, dass in den jeweiligen Kerneln alle Win32 (Überreste) komplett draußen waren?

Bewege mich jetzt auf dünnem Eis, aber afaik ist Win32 nur eine API.

Die Win32-API stellt zum Teil Kernel-Funktionen bereit. Wie das genau aufgeteilt ist - ich weiß es nicht. Auf Wikipedia sind zumindest die API-DLLs benannt: https://de.wikipedia.org/wiki/Windows_Application_Programming_Interface#Win32

Woher ziehst du das denn jetzt raus?

Wenn ich das mit dem Linux-Kernel so vergleiche (siehe dazu auch das Kernel-Log von heise) sehe ich hier alle ~6 Wochen sehr viel Bewegung. Zumindest gefühlt kommt da von MS deutlich weniger.

 

[Sun_set_1]

Man sollte die Diskussion schon im ganzen betrachten, meine Aussage bezog sich hierauf.

Hey, alles gut. Das war gar nicht komplett auf dich gemünzt, sondern einfach gegen den Generalismus bezogen. Hab meine Gedanken dazu (für wen, ist genau was denn eigentlich neu?) ja noch weiter ausgeführt.

@‘w32 Thema,


Naja. w32, wie ich es meine, ist schon ein wenig mehr als ‚ein Subsys von vielen‘. Aber auch hier wieder, natürlich ist die Aussage technisch 100%ig korrekt. Gemeint sind aber damit natürlich auch sämtliche relativ bezogene Funktionen wie der generelle instruction Aufbau, das driver-management, die Registry etc. etc.

Du kannst, soweit man es bei closed source vermuten kann, diesen Teil nicht einfach rausnehmen außer dabei gleichzeitig ein Groß des kompletten Kernel umbauen zu müssen. Wie sollte das funktionieren?
Da bin ich 100%ig bei @xexex.

Spannend wird darauf bezogen allerdings dann zukünftig die Performance älterer, nicht umgeschriebener Apps und Treiber. Wenn der Kernel wirklich komplett umgeschrieben wurde, müssten diese ja von nun an über einen weiteren, zusätzlichen Knoten/Layer gejagt werden. Performance-technisch sicherlich nicht so der Burner.

Oder sie schleppen die ‚Altlasten‘ weiter mit. Dann hätte @iamunknown durchaus wieder einen berechtigten Punkt. Aber: Von dem was MS an die devs verlautbart, ist das nicht der Fall.

Man darf aber gespannt sein, wie die Industrie auf gestiegene Latenzen bei wichtigen Applikationen reagiert (reagieren würde), die auf w32 relayen. Ich kann mir auch wirklich nicht vorstellen, dass MS den Mut hat das wirklich durchzuziehen.
Wer zahlt, bekommt ja auch weiterhin Support für W7

 

[new Account()]

Die Win32-API stellt zum Teil Kernel-Funktionen bereit.

Naja, das ist ja genau der Sinn von APIs.

Wenn ich das mit dem Linux-Kernel so vergleiche (siehe dazu auch das Kernel-Log von heise) sehe ich hier alle ~6 Wochen sehr viel Bewegung. Zumindest gefühlt kommt da von MS deutlich weniger.

Performance-Verbesserung, Feature, Feature, Performance-Verbesserung, Support für XY, Performance-Verbesserung - so mein Eindruck.

Da beeindruckt mich ehrlich gesagt sowas viel mehr: https://arstechnica.com/information...-all-how-windows-everywhere-finally-happened/
Das sind richtig große architekturelle Änderungen.
Treiber hinzufügen, hier etwas durch was besseres austauschen - sowas ist nichts verglichen mit Sachen, die die komplette Struktur über den Haufen werfen. Also wenn wir schon über Gefühle sprechen
Jetzt wissen wir natürlich genauso viel wie vorher.

Auch muss man berücksichtigen: Am Windows-Kernel sind vielleicht 2k Leute dran: https://www.quora.com/How-many-people-worked-in-designing-Windows-10
Bei Linux hängen 20k Coder dran: https://www.phoronix.com/scan.php?page=news_item&px=Linux-Git-Stats-EOY2019
(wobei ggf. der Vollzeitanteil womöglich deutlich geringer ist)

 

[I'm unknown]

Naja, das ist ja genau der Sinn von APIs.

Also ist es doch noch im Kernel von den anderen Geräten enthalten? Wir drehen uns im Kreis...

Da beeindruckt mich ehrlich gesagt sowas viel mehr: https://arstechnica.com/information...-all-how-windows-everywhere-finally-happened/

Ist bei Linux schwer möglich da schon lange so umgesetzt. Skaliert besser und läuft auf erheblich mehr unterschiedlicher HW.

Das sind richtig große architekturelle Änderungen.

Und wo ist nun die Quelle wie viel geändert wurde?

ist nichts verglichen mit Sachen, die die komplette Struktur über den Haufen werfen.

Quelle? Ist ja nicht so dass man es im Code nachsehen könnte .

 

[Sun_set_1]

Quelle? Ist ja nicht so dass man es im Code nachsehen könnte

Spätestens da wäre aber wieder die einzige Gegenvariante, bzw. implizite Vorwurf, dass MS eine neue API als zusätzlichen Layer auf einer alten API entwickeln würde. Ernsthaft, Nein. Das macht nichtmal für MS Sinn. Da dreht ihr euch dann argumentativ auch im Kreis.

Es ist closed source, ihr werdet da bis zum fertigen Endprodukt auf keinen gemeinsamen Nenner kommen.
Hakt es ab.

 

[new Account()]

Also ist es doch noch im Kernel von den anderen Geräten enthalten? Wir drehen uns im Kreis...

???
Vielleicht? Vielleicht auch nicht?
Theoretisch kann die WIn32 API da sein und dahinter der ganze Kernel ausgetauscht (d.h. keine Zeile ist mehr im neuen Kernel) sein und keiner merkt was.
Das ist genau der Sinn von APIs.

Ist bei Linux schwer möglich da schon lange so umgesetzt. Skaliert besser und läuft auf erheblich mehr unterschiedlicher HW.

Irrelevant, ging ja darum was beindruckendes voran geht.

Und wo ist nun die Quelle wie viel geändert wurde?

Lines Of Code? Imho Irrelevant. Es ging mir ja um den Eindruck.

Quelle? Ist ja nicht so dass man es im Code nachsehen könnte .

Man hat i.d.R. eine Struktur, an welche Treiber andocken können (Modularität). Neuer Treiber wäre vermutlich lediglich ein weiteres Element hinzuzufügen.
Architekturbetreffende Refactorings sind generell wuchtiger als ein schon vorhandenes modulares Design zu nutzen.
So meine Intuition als Softwareentwickler jedenfalls.

BTW. Du kannst nicht für meine Gefühle Quellen verlangen, aber selbst für die eigenen keine liefern ("das was auf heise steht schaut ziemlich viel aus, und was ich bei MS, das closed source ist, so sehe beeindruckt mich garnicht").

 

[I'm unknown]

Lines Of Code? Imho Irrelevant. Es ging mir ja um den Eindruck.

Nicht nur die Lines of code - auch was wirklich geändert werden musste. Und da rede ich nicht von Gefühlen.

BTW. Du kannst nicht für meine Gefühle Quellen verlangen, aber selbst für die eigenen keine liefern.

Das einzige was in meinem Posting ein "Gefühl" war ist die Menge an Änderungen. Ich habe nirgends behauptet "Das sind richtig große architekturelle Änderungen." ohne dann was zum Aufwand zu verlinken...

 

[new Account()]

Das einzige was in meinem Posting ein "Gefühl" war ist die Menge an Änderungen.

Das war auch das, auf was ich geantwortet habe, und das auf was ich mich bezog.

Wenn ich das mit dem Linux-Kernel so vergleiche (siehe dazu auch das Kernel-Log von heise) sehe ich hier alle ~6 Wochen sehr viel Bewegung. Zumindest gefühlt kommt da von MS deutlich weniger.

Ich habe nirgends behauptet "Das sind richtig große architekturelle Änderungen." ohne dann was zum Aufwand zu verlinken...

Ist doch schwupps. Die architekturellen Änderungen sind trotzdem groß - egal wie viel Aufwand (oben habe ich noch einen Link gepostet: wenn man dem traut, ist die Windows Kernel-Entwicklung 2000-Entwickler aufwendig -k.A. ob dir das jetzt persönlich hilft).
Und die Auswirkungen sieht man: Windows-Kernel auf ARM, Hololens, Xbox, Desktop, Tablet, Raspberry PI,(Smartphone falls es das geben würde?) uvm.
Das ist Bewegung!

 

[I'm unknown]

Ist doch schwupps.

Wenn das so ist,

Die architekturellen Änderungen sind trotzdem groß - egal wie viel Aufwand

dann muss auch das stimmen.

k.A. ob dir das jetzt persönlich hilft

Nein, ich stehe lieber auf Fakten.

 

[new Account()]

Wenn das so ist, [...] dann muss auch das stimmen.

K.a. ob du mich jetzt trollen willst, aber mal ein Versuch von kleine/große architekturelle Änderung (aus meiner Sicht):

• große architekturelle Änderung: z.B. Migration eines Monolith zu MicroService-Architektur (sehr extrem); Hybridkernel statt Microkernel oder Monolithkernel oder auch Mergen/Zerstückeln von verschiedenen OS-Kernels
• kleine architekturelle Änderung: Änderung des Printerhandlings eines OS (Windows-Beispiel: V4 Printer Drivers https://docs.microsoft.com/en-us/windows-hardware/drivers/print/v4-printer-driver)

Die Aufwände einer architekturellen Änderung können jeweils je nach vorherigem Code ganz unterschiedlich groß ausfallen:
Kann man die Komponenten einfach neu zusammenwürfeln (z.B. einfach nur einen Abstraktionslayer hinzufügen) oder muss man Komponenten zerstückeln, neue Komponenten entwickeln, etc?

Nein, ich stehe lieber auf Fakten.

Die kann ich dir als jemand, der nicht bei MS Personaler ist, leider nicht handfest liefern.

 

[Sun_set_1]

 

[cbtestarossa]

Die wurden nach Win7 alle entlassen und man bedient sich wieder an EGA Farben

Du meintest CGA.
EGA war gegen Win10 ein Traum.
Auch konnte EGA schon hohe Auflösungen und hey die Schriften waren damals schon besser lesbar als alles was nach Win 3.11 kam.

Und die richtig guten Leute wurden schon zu XP Zeiten entlassen.
Und davor wahrscheinlich auch ein paar als DOS ausstarb.

 

[xexex]

Und gibt es eine brauchbare Quelle welche genau das belegt?

Genau das hat Microsoft auf der von mir velinkten Seite erklärt, du wiederholst dich. Glaubst du das hätte man mit einem Windows Vista Kernel gekonnt?

Wieso hat man noch bis vor kurzem Windows CE für Enbedded gehabt und einen eigenen Kernel für Windows Mobile entwickelt? Ja es gibt hunderte "brauchbare" Quellen, die es erklären.

Wie das genau aufgeteilt ist - ich weiß es nicht.

Da sind wir uns schon mal einig, stellt sich dann nur die Frage wieso du dann von deinem Standpunkt so überzeugt bist.

Ich empfehle dazu übrigens:

https://www.amazon.de/dp/0735684189

Wenn ich das mit dem Linux-Kernel so vergleiche (siehe dazu auch das Kernel-Log von heise) sehe ich hier alle ~6 Wochen sehr viel Bewegung.

Ein gutes Stichwort! In den Jahren 2011 und 2012 hat Microsoft mit die meisten Zeilen Code zum Kernel von Linux beigetragen, Hintergrund dessen war eine bessere Integration von Hyper-V.
https://arstechnica.com/information...s-of-code-and-microsoft-is-a-top-contributor/

Dabei ist Virtualisierung auch nur einer der Features, der seit Windows 7 im Windows Kernel konstant ausgebaut und optimiert wurde und hier nicht nur auf der Client, sondern auch Serverseite.

Wieso man trotzdem bei Linux mehr Änderungen sieht? Linux hat einen monolithischen Kernel.

Im Vergleich dazu ist bei Windows das meiste davon nicht im Kernel, weshalb man diesen auch nicht auf jede Architektur einzeln anzupassen braucht. Das meiste was du bei Linux an Kerneländerungen siehst, wird bei Windows simpel in Form von Treibern gepflegt.

 

[Nebula123]

Im Geräte-Manager ausgeblendete Geräte Anzeigen lassen, unter Monitore alle PNP-Monitore und Nicht-PnP-Monitore rausschmeißen außer die 2 aktiven und für diese gleich die .inf-Datei vom Hersteller einspielen. Hat schon mehrmals geklappt

das habe ich schon hinter mir, hat bei leider nichts gebracht

 

[I'm unknown]

Genau das hat Microsoft auf der von mir velinkten Seite erklärt, du wiederholst dich. Glaubst du das hätte man mit einem Windows Vista Kernel gekonnt?

Wo habe ich denn behauptet es sei keine Weiterentwicklung? Nur sehe ich weiterhin diese Punkte durch einen Screenshot mit vielen Kernen von einem Windows-Server nicht als belegt:

Man hat den Kernel von den ganzen früheren Altlasten befreit, alles was auf das "klassische" Windows ausgelegt war entfernt oder in der Usermode verlagert und der Kernel an sich komplett entschlackt und skalierbar gemacht.

Wenn du dafür Details hast gerne. Gerade was vom Mikrokernel entfernt bzw. in den Usermode gewandert ist wäre interessant - viel ist da aus meiner Sicht nicht.

Da sind wir uns schon mal einig, stellt sich dann nur die Frage wieso du dann von deinem Standpunkt so überzeugt bist.

Anscheinend weißt du in welchem Layer welche Funktion steckt und in welcher DLL welche API zur Verfügung gestellt wird. Ich nicht, ist mir in dem Detailgrad bei Closed Source - dessen Kernel nicht Echtzeitfähig ist - auch egal. Brauche ich nicht.

Ich empfehle dazu übrigens:

Du empfiehlst mir also für den OneKernel ein Buch zur Architektur vom Stand Windows 7? Ernsthaft?

Ein gutes Stichwort! In den Jahren 2011 und 2012 hat Microsoft mit die meisten Zeilen Code zum Kernel von Linux beigetragen, Hintergrund dessen war eine bessere Integration von Hyper-V.

Die Hyper-V Treiber mussten sie offen legen: https://lkml.org/lkml/2009/7/20/167 Wie man sieht war die Qualität am Anfang nicht sonderlich gut, sonst wäre der Code nicht im Staging-Bereich gelandet.
Um die Umfänge der Commits (aus deiner eigenen Quelle) noch darzustellen:

According to the Linux Foundation's statistics, volunteer developers contributed 16 percent of total changes in 2011.

Davon sind dann schon 17% auf Platz 1 und 2 der Top Unternehmens-Beiträger gefallen, MS hat es in diesem Bereich auf Platz 17 geschafft. Lobenswert, aber Top-Beiträger würde ich das nicht nennen.

Dabei ist Virtualisierung auch nur einer der Features, der seit Windows 7 im Windows Kernel konstant ausgebaut und optimiert wurde und hier nicht nur auf der Client, sondern auch Serverseite.

Wenn du schon immer vom Mikrokernel von Windows sprichst, der Hypervisor ist bei weitem nicht komplett im Kernel.

Wird auch von Microsoft so dargestellt, nicht nur bei Wikipedia (Bild ist ein Link).

Wieso man trotzdem bei Linux mehr Änderungen sieht? Linux hat einen monolithischen Kernel.

Klar, da werden auch Treiber mal zum Highlight. Andere Architektur - aber gerade im Kernel-Log sieht man wie viele Queues und I/O-Dinge optimiert werden (das wäre auch in Windows zum größten Teil im Kernel).

Das meiste was du bei Linux an Kerneländerungen siehst, wird bei Windows simpel in Form von Treibern gepflegt.

Nicht nur - man bekommt vieles wie du richtig dargelegt hast (leider) auch nicht mit.