Dauerthema: Windows 10

Begonnen von Mam, April 05, 2017, 08:20:06

« vorheriges - nächstes »

Mam

gut gebrüllt Löwe  ;D

Nur, wollen wir die Kirche doch mal im Dorf lassen, der TS Doc macht es Windoof auch nicht wirklich einfach, ihn funktionieren zu lassen.

a) Verwendung einer "systemfremden" Sprache (aka: Dein Compiler, Dein Problem...)
b) verharrend in der aussterbenden 32bit Emulation ( Chance verpasst bei 2.x )
c) Verwenden von "soon to be deprecated" Funktionen wie DirectShow usw.

Du hast Dich viel zu lange um Exoten wie WINE oder den MAC Kram gekümmert, Dich dabei immer weiter von Windows entfernt und auf immer tiefere "gemeinsame Nenner" drücken lassen.

Akzeptier mal langsam, dass Microsoft den Sack bald zu macht, Windows 7 und 8 sind dann tot, ohne Support, ohne Updates. Neue Kisten haben zwangsläufig 10 und neuere Hardware (z.B. Intel CPUs) bieten gar keine Treiber für <10 mehr an.

Das Ganze kommt nicht wirklich überraschend, das Ganze war angedroht und auch sehr vorhersehbar (wenn schon Verschenken angesagt war, dann will man den Altkram so schnell wie möglich loswerden um zumindest Manpower einsparen zu können).
Und es war auch recht blauäugig zu glauben, sie würden grandios scheitern und das Rad zurückdrehen.

Also hör auf zu jammern, finde Dich mit dem Gedanken ab und fang endlich an, die verpennten letzten 2 Jahre aufzuarbeiten.

:-*

Cypheros

Zitata) Verwendung einer "systemfremden" Sprache (aka: Dein Compiler, Dein Problem...)

Was soll denn eine "systemfremde" Sprache sein? Ich weiß nicht wer Dir das erzählt hat aber weder Windows, noch Microsoft ist eine Programmiersprache. Das Problem mit KB4013429 betrifft übrigens auch den "Windows Media Player". Ist der wohl auch mit einer "systemfremden" Sprache programmiert?


Zitatb) verharrend in der aussterbenden 32bit Emulation ( Chance verpasst bei 2.x )

64bit bringen keinen signifikanten Vorteil, nur den Nachteil auf 32bit-Systemen nicht mehr zu laufen oder, dass ich mich mit zwei Anwendungen (32bit,64bit) rumschlagen muss.


Zitatc) Verwenden von "soon to be deprecated" Funktionen wie DirectShow usw.

Die meiste kommerzielle Software für Windows verwendet immer noch DirectShow (Nero,Adobe,Cyberlink,Magix, etc.)


Wenn Dein Windows 10 so toll ist, dann ist es doch erstaunlich, wieviele Kunden noch mit Windows XP und Windows 7 arbeiten. Hier die Statistik von meinem Web-Server von Anfang des Jahres:
[attachimg=1]

Mam

#2
a) "systemfremd" sind in diesem Falle alle Sprachen, die nicht interpretiert werden, aber auch keinen Code für die "Common Runtime Library" erzeugen. Bei denen besteht halt die Gefahr, dass Updates keine Rücksicht auf deren Runtime nehmen, weil sie nicht im normalen Testzyklus enthalten sind.

b) natürlich können Updates immer irgendwelche Bugs produzieren, Du weist selber, dass man gar nicht alle möglichen Kombinationen und Konfigurationen testen kann, um jegliche Reaktion vorab zu überprüfen. Das gilt für ein einzelnes Progrämmchen, aber noch viel mehr für ein kompliziert verwobenes Geflecht derselben, wie es nun mal ein Betriebssystem mit hunderten von Anwendungen so ist.

c) ich sag nicht, dass 64 Bit Vorteile bringen, ich sag nur, sie sind im Begriff nativ zu werden. Windows Server gibt es schon seit 2 Generationen nicht mehr als 32 Bit, die Arbeitsplätze werden zwangsläufig folgen. Das spart Ressourcen, Platz und Servicezeit. Es gibt ja wohl auch schon seit einiger Zeit keine Hardware mehr zu kaufen, die auf 32 Bit angewiesen ist. Mit Deiner Weigerung Dich endlich mal zu beginnen Dich zu bewegen, riskierst Du nur, irgendwann wirklich vor "Game Over" dazustehen und musst von heute auf morgen was Neues aus dem Hut zaubern.
Wen interessieren die Anderen? Du musst doch selber zusehen, wo Du bleibst. Und da helfen Schmollen und Scheuklappen nicht wirklich weiter.

(ist übrigens immer noch nicht "mein Windows 10;D Ich hasse das ganze Gedödel und hab ja alles rausgeschmissen, was nach App oder so aussieht. Bedient sich so, wie Win 7, läuft aber stabiler und schneller inzwischen)

also, setz Dich hin, nimm ein Visual Studio, leg ein Projekt an (kannst sogar "egal welche" CPU einstellen, das funktioniert dann überall), nimm Dir ne Microsoft unabhängige Sprache, wie z.B. C++, und fang von vorne an...

Teilnehmer

Ich bin kein Entwickler. Aber aus weltanschaulicher Sicht liest sich Mam besser.

Grüße in die Runde

MiVaFo

Mam, ich glaube ehrlich gesagt nicht, dass deine sicher gut gemeinten Vorschläge zur höheren Stabilität des TS Doctors führen werden (weder unter Win 10 noch unter einem älteren Windows). Im Gegenteil, eine bewährte API wie DirectShow rauszuwerfen und durch irgendwas weniger ausgereiftes zu ersetzen, oder ohne Not auf 64-Bit umzustellen wird das Programm nicht stabiler machen. Und die Programmiersprache oder den Compiler zu wechseln ganz sicher auch nicht.

Wo ich dir aber recht gebe: das Win10-Bashing nervt. Kann ja sein, dass da unter der Haube einiges verschlimmbessert wurde, aber dafür kann ich mir nix kaufen. Millionen Anwender (zu denen ich auch gehöre) habe Win 10 und werden nicht wieder auf Win7 downgraden. Ich vertraue aber darauf, dass du - Cypheros - den "Doc" auch weiterhin unter der aktuellen Windows-Version "am Leben" hälst.

Gute Nacht  8)

Cypheros

Natürlich bemühen wir uns den TS-Doctor immer aktuell zu halten und unter so vielen Betriebssystem-Versionen wie möglich, möglichst stabil laufen zu lassen.

Zur Zeit werden alle Windows-Versionen zwischen XP und 10 unterstützt. Selbst der Betrieb unter Linux und MacOS ist möglich über Wine oder Crossover.

Windows 10 liegt mir sehr am Herzen aber wir werden immer wieder enttäuscht von den Zwangsupdates, die jede Menge Support-Anfragen erzeugen und sehr viele Mannstunden an Fehleranalyse um dann festzustellen, dass aus Redmond mal wieder ein fehlerhaftes Update geliefert wurde.

Manche Kunden sind dabei sehr unfreundlich, weil sie uns nicht glauben, das unsere Software OK aber das letzte Windows-Update fehlerhaft ist. Sowas war unter Windows 7 sehr selten, unter Windows 10 sehr viel häufiger. Viele Windows-Updates bei Windows 10 passieren unbemerkt im Hintergrund, so dass die Kunden auch nicht unbedingt merken, wie Microsoft ihr bisher stabiles System verändert.

Mam

Zitat von: MiVaFo am April 05, 2017, 22:43:09
Mam, ich glaube ehrlich gesagt nicht, dass deine sicher gut gemeinten Vorschläge zur höheren Stabilität des TS Doctors führen werden

Nein, natürlich nicht, höchstwahrscheinlich sogar zum Gegenteil.  :o

Aber, darum ging es mir ja gar nicht, sondern darum, dass irgendwann in nicht allzuferner Zukunft Microsoft die Schotten dicht macht, und z.B. keine 32Bit Programme mehr starten lässt. "Altlasten" werden schon seit Jahr(zehnten) immer bei Gelegenheit rausgeworfen, Du kannst heute z.B. keine 16 Bit Programme mehr starten, oder das Posix Subsystem installieren (dafür gibts nun Ubuntu als Docker). Klar, das kratzt auch nun niemanden mehr, aber in der Übergangszeit gab es immer Stress.

Und mein Hauptanliegen besteht darin, dass er sich JETZT, wo die 2.x eigentlich rund läuft und wenig Updates erfordert, mal in Ruhe hinsetzt und sich überlegt, wie und wohin es weitergeht, am Besten mit einem Neuanfang.

MiVaFo

#7
Zitat
Aber, darum ging es mir ja gar nicht, sondern darum, dass irgendwann in nicht allzuferner Zukunft Microsoft die Schotten dicht macht, und z.B. keine 32Bit Programme mehr starten lässt.

Darüber würde ich mir erst dann Gedanken machen, wenn 128-Bit-Prozessoren im Consumer-Markt auftauchen und MS erste Anzeichen erkennen lässt, ein dazu passendes 128-Bit-Windows rauszubringen, dass dann wahrscheinlich nur noch 64 und 128-Bit-Programme unterstützen würde. Da seh ich aber derzeit nicht annähernd den Nutzen, der dem damaligen Nutzen beim Sprung von 16 auf 32 Bit entspricht. Hab' dann danach mal gegoogelt und dazu ein interessantes Posting von Aviad Ezra, einem Microsoft-Mitarbeiter, auf Quora gefunden:

https://www.quora.com/Why-isn%E2%80%99t-there-any-128-bit-Windows

Der teilt meine Einschätzung, und weist zudem noch darauf hin, dass auch Programme wie Visual Studio und Outlook immer noch 32-bittig sind und wohl auf absehbare Zeit noch bleiben werden. Und da MS sich garantiert hierfür nicht selber die Plattform entziehen wird (von den Aberhunderttausend 32-Bit-Programmen anderer Hersteller ganz abgesehen), bin ich da recht zuversichtlich, dass wir auf ein Windows ohne 32-Bit-Unterstützung noch mindestens ein oder zwei Dekaden  warten müssen.

Mam

#8
Zitat von: MiVaFo am April 08, 2017, 01:13:29
Da seh ich aber derzeit nicht annähernd den Nutzen, der dem damaligen Nutzen beim Sprung von 16 auf 32 Bit entspricht. Hab'
Aha, lass mich raten, Dein PC hat nur 3 oder 4Gb (ungenutzt) Ram?
Mehr geht nämlich nicht mit 32 Bit...
Natürlich bringt die Arithmetik mit 64 Bit nicht denselben Quantensprung wie von 16 auf 32 Bit, aber für die Adressregister ist es eine komplett neue Welt, da man (endlich!!! nach nur 30 Jahren!!!) von dieser doofen Segmentierung wegkommt und mehr als 4Gb am Stück verwalten kann. Das spart reichlich Tabellenplatz in Kernel und Programmen.
Außerdem ist 64bit bei Floating Point Operationen eigentlich ein Muß, denn so können die Zahlen auch "in einem Rutsch" verarbeitet werden, anstatt nacheinander in LowDword und HighDword mit mehreren Befehlen gespeichert/geladen zu werden.
Und, unbemerkt von Deiner Aufmerksamkeit, gibt es schon seit einiger Zeit 128 Bit Befehle!
Die findest Du in den SSE Befehlen der CPU, sie werden meist für Graphikberechnungen verwendet, erlauben aber auch das direkte Laden / Speichern von 128Bit Registern. (Ich geb allerdings zu, das sind keine "General Purpose" Befehle, die man in einem Betriebssystem braucht  ;D )

Zitat
Der teilt meine Einschätzung, und weist zudem noch darauf hin, dass auch Programme wie Visual Studio und Outlook immer noch 32-bittig sind und wohl auf absehbare Zeit noch bleiben werden.
Du solltest vielleicht nicht mehr Artikel aus dem letzten Jahrhundert lesen, natürlich gibts Outlook inzwischen in 64 Bit (wie das gesamte Office übrigens) und Visual Studio ist so eine spezielle Sache, da ist recht wenig dran ein "richtiges" Programm, die meisten Teile sind Skripts und/oder CLR, werden also interpretiert. Als CPU Typ ist dort meist "ANY" vorgesehen, die Runtime entscheidet also.
[attachimg=1]
(ich glaub, das erste 64Bit Office war schon zu Weiland XP Zeiten, also entweder 2007 oder 2010)

Du hast Deinen Artikel (und dessen Kommentare) wohl etwas falsch verstanden. Die reden davon, ob es SINNVOLL ist, 64Bit zu benutzen für Visual Studio oder Outlook, und ja, sie haben insofern Recht, dass es für diese beiden Kandidaten wenig Sinn macht, da sie sich meist nur mit Editorfähigkeiten rumplagen und recht überschaubare Datenmengen händeln.
Bei Outlook wird es dann sinnvoll, wenn man genug genervt ist von der 2Gb Grenze von PST Dateien und keine Nachrichten mehr in die Archive ablegen kann, bei Visual Studio wird es unbedingt erforderlich, wenn man 64Bit Programme erstellen und Debuggen will (wobei der Compiler selbst ruhig 32Bit breit sein darf, aber spätestens der Debugger muß mehr können).

Der TSDoc wirft jedoch mit Videodateien durch die Gegend, und die sind nunmal naturgemäss GROSS, meist viel grösser als die leidigen 4Gb. Und bei solchen Anwendungen bringt 64Bit Arithmetik wirklich massig Performancegewinn, denn alle Berechnungen (Sprungaddressen, Offsets usw) können nun in einem einzigen Assemblerbefehl durchgeführt werden anstatt Orgien von Umspeichern von halben Zahlen, Belegung von mehreren Registern und Beachtung des Carryflags. Das spart Platz und CPU Zyklen.

Also, werd wach und komm in dieses Jahrhundert...

parameter

Zitat von: Mam am April 08, 2017, 06:36:53
(ich glaub, das erste 64Bit Office war schon zu Weiland XP Zeiten, also entweder 2007 oder 2010)
Das erste war Office 2010 und wie der Name schon sagt ...
TS-Doctor 1.2.184

MiVaFo

#10
ZitatAha, lass mich raten, Dein PC hat nur 3 oder 4Gb (ungenutzt) Ram?
Mehr geht nämlich nicht mit 32 Bit...

Nö, mein PC hat deutlich mehr RAM, PC und OS sind 64-bittig, und darum geht's auch nicht. Dass die Umstellung einer 32-Bit-Applikation auf 64-Bit in bestimmten Fällen hochgradig sinnvoll sein kann, daran hab ich auch gar keinen Zweifel - es betrifft nur nicht mehr (gefühlt) 98% aller real existierenden Programme (wie seinerzeit beim Sprung von 16 auf 32 Bit), sondern vielleicht 2% aller Applikationen. Ob der TSDoc zu diesen 2% gehört, mag Cypheros beurteilen. Aber an seiner Stelle würde ich auch keine zwei Applikationen parallel pflegen wollen.

Kein Grund dagegen, auf 64 Bit umzusteigen, ist der urbane Mythos, MS würde in absehbarer Zeit die 32-Bit-Unterstützung aus Windows entfernen. Den Artikel, den ich dazu gefunden habe, war auch nicht "aus dem letzten Jahrhundert", sondern, vom letzten Jahr.

ZitatAußerdem ist 64bit bei Floating Point Operationen eigentlich ein Muß, denn so können die Zahlen auch "in einem Rutsch" verarbeitet werden, anstatt nacheinander in LowDword und HighDword mit mehreren Befehlen gespeichert/geladen zu werden.

Das ist ebenso ein Mythos. 64-bit-Floating-Point ist auf halbwegs modernen Maschinen in 32-Bit-Prozessen genauso schnell wie in 64-Bit-Prozessoren, schau mal hier: http://stackoverflow.com/questions/28297228/double-precision-operations-32-bit-vs-64-bit-machines

ZitatUnd, unbemerkt von Deiner Aufmerksamkeit, gibt es schon seit einiger Zeit 128 Bit Befehle!
Was meiner Aufmerksamkeit entgangen oder nicht entgangen ist, beurteile ich lieber selbst. Ich weiss Mam, dass es dir schwer fällt, persönlichliche Angriffe in deinen Antworten wegzulassen, aber ein wenig nervt das mitunter schon - lass uns bitte weiterhin sachlich diskutieren. Die 128-Bit-SSE-Befehle sind genauso in 32-Bit-Prozessen verfügbar und AFAIK auf Maschinen mit 64-Bit-Bus genauso schnell wie in 64-Bit-Prozessen.

ZitatDie reden davon, ob es SINNVOLL ist, 64Bit zu benutzen für Visual Studio oder Outlook, und ja, sie haben insofern Recht, dass es für diese beiden Kandidaten wenig Sinn macht, da sie sich meist nur mit Editorfähigkeiten rumplagen und recht überschaubare Datenmengen händeln.

Genau. Es geht um die Frage sinnvoll oder nicht, und VS und Outlook sind keine kleinen Applikationen, die dienten hierbei ja auch nur als repräsentatives Beispiel dafür, dass selbst recht große Applikationen in der Regel nicht wirklich davon profitieren, wenn man sie 64-bittig macht.

ZitatBei Outlook wird es dann sinnvoll, wenn man genug genervt ist von der 2Gb Grenze von PST Dateien und keine Nachrichten mehr in die Archive ablegen

Outlook-PST hat schon seit 2003 kein 2GB-Limit mehr, und die maximale Größe von PST-Dateien hängt auch nicht davon ab, ob man ein 32- oder 64-Bit-Outlook verwendet. Schau mal hier: https://www.lifewire.com/outlook-pst-files-size-limit-1173344

ZitatDer TSDoc wirft jedoch mit Videodateien durch die Gegend, und die sind nunmal naturgemäss GROSS, meist viel grösser als die leidigen 4Gb. Und bei solchen Anwendungen bringt 64Bit Arithmetik wirklich massig Performancegewinn, denn alle Berechnungen (Sprungaddressen, Offsets usw) können nun in einem einzigen Assemblerbefehl durchgeführt werden anstatt Orgien von Umspeichern von halben Zahlen, Belegung von mehreren Registern und Beachtung des Carryflags. Das spart Platz und CPU Zyklen.

Daran könnte vielleicht was dran sein, allerdings vertut man sich mit solchen Einschätzungen auch leicht, wenn man den Flaschenhals nicht nachmisst. Das muss schon Cypheros selber beurteilen, und dessen Meinung dazu hast du ja schon gelesen. Hängt wahrscheinlich vor allem davon ab, wieviele Daten der Doc für welche Funktion im einzelnen "am Stück" im Hauptspeicher braucht bzw. z.B. als Cache verwenden kann.

Ich vergaß noch zu erwähnen - ich habe selber schon reale Applikationen von 32 auf 64-Bit umgestellt (weil dort die prozessbezogenen Speicherlimits nicht mehr reichten). Meine Erfahrung damit war immer dieselbe - entgegen der landläufigen Meinung werden die in der Regel nicht wirklich schneller.

Cypheros

Also ich sehe das ähnlich wie MiVaFo. 64bit ist ein "nice to have", mehr nicht. Trotzdem behalte ich das im Auge und werde meine Komponenten und Units Stück für Stück 64bit tauglich machen. Hart wird das bei den optimierten Assembler-Routinen.

Die nächste Delphi-Version 10.2 Tokyo ist bereits geordert, die nun auch alle wichtigen Betriebssysteme wie Windows, MaxOS, IOS, Android und Linux unterstützt. Will damit aber nicht sagen, dass es bald einen TS-Doctor fürs IPhone gibt oder sowas. Crossplattform-Entwicklung ist schwierig und man muss das bereits bei der Planung einer Applikation berücksichtigen.

Werde heute anfangen und mein Entwicklungssystem von Windows 7 auf Windows 10 umstellen, damit ich die Probleme besser und schneller reproduzieren kann. Das wird mich bestimmt bis Ostern beschäftigen.

Mam

Zitat von: Cypheros am April 08, 2017, 09:57:18
Werde heute anfangen und mein Entwicklungssystem von Windows 7 auf Windows 10 umstellen, damit ich die Probleme besser und schneller reproduzieren kann. Das wird mich bestimmt bis Ostern beschäftigen.

DAS ist doch schon mal ein Anfang  ;D
Nur Selberleiden macht schlank  :-*

Tscha, der "hochoptimierte Assemblercode" mag hinterher wirklich komplett anders aussehen, aber wenn er wirklich so hochoptimiert wäre, würde er ja schon lange spezielle Opcodes verwenden, die dann ja eh schon breit-bittig sind.
Man sollte, glaube ich, diesen Teil einfach erstmal weglassen (bzw. "normal" programmieren) und später vielleicht mal zum Assembler greifen und alle (werden wohl mehrere, durch Unterschiede von Intel und AMD) Versionen benchmarken.
Dann kann man immer noch, je nach Prozessor, die eine, oder die andere Funktion aufrufen..

Ansonsten bin ich ein Feind dieser "Glaubenskriege", der letzte, an dem ich aktiv teilnahm, hieß "6502 oder Z80 - welcher Prozessor ist der Bessere?" (und auch bei dem gab es schon keine Gewinner)

Cypheros

Kannst Du mir die Dienste und Apps nennen, die man am besten bei Windows 10 weglässt oder deaktiviert ohne, dass die Funktionalität eingeschränkt wird?
Ich brauch kein Cortana, keinen Shop, keinen Remotezugriff und meine Telemetriedaten sollen auch im Hause bleiben.
Es gibt da zwar ne Menge Tools, die das angeblich machen, traue denen aber nicht so recht über den Weg.

Mam

#14
Zitat von: Cypheros am April 08, 2017, 14:03:57
Kannst Du mir die Dienste und Apps nennen, die man am besten bei Windows 10 weglässt oder deaktiviert ohne, dass die Funktionalität eingeschränkt wird?

Ich hab Dir doch mal ein nettes rundes Sample geschickt. Die Scheibe nimmst Du (oder kopierst alle Dateien in ein UV) und startest dort "Setup.exe".
Da werden ALLE unnötigen M$ Apps weggelassen (auf eine Art, wie Du sie manuell nie erreichen kannst). Die Schnüffelkreuze musse Dir aber selber wegklicken (das machen hier die GPOs).
Dafür ist dann gleich ein Firefox und VLC onboard (wobei beide inzwischen etwas veraltet sind, also auch nach Updates schreien).

Er sollte ein Update durchführen, alle Deine Apps und Settings sollten erhalten bleiben. Er prüft das aber vorab und warnt, wenn irgendwas nicht konvertiert werden kann.

Alternativ kannste natürlich auch davon booten (bevorzugt im UEFI Modus) und mit einer Neuinstallation alles platt machen.

Wenn Du es ganz modern haben willst, nimmst Du die DVD, löscht unter "Sourcen" die "Install.Wim", saugst Dir mit dem Mediacreation Tool die neuste Microsoft DVD ("Creators Edition") und kopierst von der "Sources\Install.EDL" rüber auf meine DVD.
Dann hast Du denselben Effekt, allerdings bleiben noch die neuen 3D Apps über, die bin ich gerade am prüfen und entsorgen.
Aber das Groß wie Store und die ganze Werbebanner sind dann auch gleich weg.

;D

(Wobei der geneigte Leser erkenne mag, ich nehm nur die Original DVD und lösche bei der Installation alle nicht gewollten Apps, BEVOR sie im Benutzerprofil kopiert wurden. Das ist wichtig, denn alle Tipps, die man so bei Chip & Co findet, basieren darauf, dass erstmal alles überall installiert wird und später dann beim Benutzer gelöscht wird. Das ist dann aber nur die Kopie und ein anderer User hat den Kram dann immer noch an der Backe. Da musst Du für jeden User einzeln löschen. Bei mir ist gleich für alle User weg und kommt auch bei neuen Usern nicht mehr wieder)

Ach ja, ich vergaß zu erwähnen. Die meisten "bösen" Dienste sind nach Installation ebenfalls deaktiviert, manche sogar komplett gelöscht. Leider gibt es einen "Synchronisationshost" (oder so), der wird erst bei der Profilbildung des Benutzers erzeugt, den kann ich also leider nicht verhindern. Zusätzlich erschwert M$ es einen, indem der Dienst jeweils einen anderen Dienstnamen erhält (und Weglassen ist eh nicht, denn es ist mal wieder einer dieser meistgehassten svchost.dll Dinger)


www.cypheros.de