J�rg Tewes <[EMAIL PROTECTED]> wrote on 20.08.04:
> Freitag, 20.08.04 Michael Heydekamp schrub...
>>> Nein ich habe weder bei W2k SP4 noch bei WinXP SP1 eine merkliche
>>> Verlangsamung.
>> Aha, so herum. Ein weiteres Mysterium. Wir sprechen �ber Fenster,
>> nicht Vollbild (nur zur Sicherheit).
> Jepp Fenster ist gemeint mit einer Festschriftart 10x13. Wie hie�en
> die Fonts noch gleich?
Du meinst vermutlich Bitmap-Fonts. Festbreitenschriftarten sind das
alles (auch der True Type Font Lucida Console), denn
Proportionalschriftarten sind f�r den Konsolenbetrieb untauglich.
>> Und der Cursorbalken flitzt in Men�s, User-�bersicht usw. richtig
>> fl�ssig?
> Nein nicht so wie unter DOS oder Win9x, aber eben nicht signifikant
> langsamer und eben nicht ruckelig. Ich kann das schlecht beschreiben.
Dann kommt bei Dir vielleicht zweierlei zusammen: a) Aufgrund der
Gesamtperformance Deines Systems wirkt sich das Problem nicht so extrem
aus, und b) hast Du vielleicht nicht so hohe Anspr�che an das
Reaktionsverhalten.
>> Das einzige, was man bisher machen kann, ist das bereits von Frank
>> Mollenhauer erw�hnte TameDOS. Ich habe das hier mal ausprobiert
>> und es hilft wirklich massiv.
> Was war TameDOS nochmal?
Siehe www.tamedos.com.
BTW und IMO auch unter Win2K ganz sinnvoll, denn ein weiterer angenehmer
Nebeneffekt (bzw. das ist der eigentliche Effekt) ist die nennenswerte
Reduzierung der CPU-Last. Ich komme selbst bei permanent gedr�ckter
Taste im Editor mit aggressiver "Console Update"-Einstellung von 1ms nie
�ber 17% (mit der Default-Einstellung von 100ms sogar nie �ber 10%),
ohne TameDOS liege ich im Editor bei 70-85% und beim Scrollen in Men�s
sogar bei 95%.
>> [...]
>>>> Ich habe die Eigenschaften des Fensters ge�ndert, z.B. in "11"
>>>> (Lucida Console). Wenn ich jetzt in den Eigenschaften der PIF
>>>> nachsehe, steht da immer noch der vorherige Wert.
>>> Das ist bei mir auch so,
>> Oben schriebst Du aber, die Einstellungen w�rden in die PIF-Datei
>> �bernommen werden. Jetzt best�tigst Du, da� das nicht der Fall
>> ist.
> Sie sind zumindest nicht �ber den Dialog erreichbar. Ich vermute ganz
> stark das die beiden Dialoge die man sieht, einmal beim direkten
> bearbeiten der PIF und das andere Mal beim einstellen �ber das
> Systemmen�, beides Mal in die PIF geschrieben werden, blo� an
> verschiedenen Stellen.
Das lie�e sich ja leicht verifizieren. Backup der PIF anlegen,
Einstellungen �ber das Systemmen� �ndern und mit fc /b pr�fen, ob sich
was ge�ndert hat.
Mache ich vielleicht mal, glauben daran tue ich im Moment nicht.
>> Da� sie *irgendwo* (in Bezug auf Hardware-Zugriff usw.) eingeschr�nkt
>> wurden (meinetwegen auch werden mu�ten), ist eine allgemeine Aussage
>> ohne Wert. Daraus kann man doch nicht ableiten, da� die seitens
>> Windows selbst (via PIF) angebotene Einstellungen (die ja mit der
>> DOS-Emulation nichts zu tun haben) ignoriert werden.
> Naja es k�nnte durchaus sein das die Einstellungen dort eigentlich
> garnicht hin sollten. Sie wurden dann aber nie mehr angefasst und so
> sind sie halt vorhanden aber ohne Funktion.
Ist alles m�glich. Mich irritiert aber auch, mit welcher
Selbstverst�ndlichkeit so etwas von den Anwendern hingenommen wird, denn
au�er von mir selbst habe ich noch nichts gelesen, wo das schon mal
bem�ngelt oder wenigstens angemerkt worden w�re.
>>> Nein eben nicht nur Hardware. XPoint kann z.B. nicht in das Windows
>>> Temp Verzeichnis schreiben. Weswegen Uwe damals einige Batch Dateien
>>> umschreiben mu�te.
>> Ich kann hier problemlos in das TEMP-Verzeichnis von Windows
>> schreiben (unter WinXP, und unter Win9x sowieso).
> Du hast WInXP auf einer NTFS Partition installiert?
Ja klar.
>> Und wenn das nicht geht, mag das mit der Rechtevergabe zu tun
>> haben, ist aber ebenfalls nichts, was als generelle Einschr�nkung
>> der VDM zu sehen w�re.
> Ich bin mir nicht mehr 100% sicher, und kann es auch nicht mehr
> nachgucken, aber auf jeden Fall ging es nicht. Und es war keine Sache
> von falschen Benutzerrechten, weil es sogar als Admin nicht ging.
Dann ist da irgendwas faul, das kann ja nicht der Normalzustand sein.
Das globale Temp-Verzeichnis ist ja nun gerade dazu da, da� dort jedes
Programm seine Tempor�rdaten ablegen kann, wozu steht's sonst per
Default in einer Umgebungsvariablen?
[Nicht zur�ckgesetzter Fenstertitel nach Netcall]
>>>> Es ist in beiden F�llen aber dasselbe UKAW... Was folgt jetzt
>>>> logisch daraus?
>>> Das UKAW sich unter WinXP anders verh�lt als unter Win9x?
>> Eher nicht. Du sagtest ja selbst, da� UKAW keine Probleme mit der
>> 32bit-Konsole haben sollte, jetzt willst Du das Verhalten UKAW in
>> die Schuhe schieben?
> Es sollte keine Probleme haben hei�t doch nicht das es keine Probleme
> hat.
Also was ist jetzt Deine Position in dem Punkt? UKAW ist schuld oder
WinXP?
>>> Ebenso kann man direkt in den Bildschirmspeicher schreiben.
>> Kann man unter WinXP doch auch...?
> Nicht aus einer DOS Anwendung.
Doch, auch aus einer DOS-Anwendung. XP macht das ja z.B., wenn es im
Vollbild interne Fonts l�dt (jedenfalls verstehe ich das so, mein
Fachgebiet sind dieses hardwarenahen Sachen auch nicht gerade).
Ob und wie Windows das intern abf�ngt, �bersetzt und wie auch immer an
was auch immer weitergibt, entzieht sich meiner Kenntnis. Auf jeden
Fall geht's prinzipiell.
> BTW. Ich habe gerade einen MSKB Artikel kurz �berflogen in dem von
> 16bit Anwendungen die Rede ist wo der Bildschirm nicht oder langsamer
> als �blich aktualisiert wird. Als Beispiel wird da edit.com erw�hnt.
> Der Fehler wurde unter W2k mit SP4 und unter WinXP mit SP1 behoben.
> Allerdings tritt das erst bei Rechnern ab 2 Ghz Prozessorfrequenz auf.
> Scheint also f�r unser Problem nicht relevant zu sein.
Richtig. Der Artikel ist bekannt, darauf hatte Franklin schon mal vor
l�ngerer Zeit hingewiesen. Der Patch bringt - au�er eben vielleicht auf
2GHz-Maschinen, aber auch da nicht immer - genau gar nichts.
Michael
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
