Montag, 23.08.04 Michael Heydekamp schrub...
Hi!
> J�rg Tewes <[EMAIL PROTECTED]> wrote on 20.08.04:
>> Freitag, 20.08.04 Michael Heydekamp schrub...
>> Jepp Fenster ist gemeint mit einer Festschriftart 10x13. Wie
>> hie�en die Fonts noch gleich?
> Du meinst vermutlich Bitmap-Fonts.
Jepp.
>>> 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,
NAja ich hab hier ein eher langsames Board mit einem AMD 2000+, aber
das Verhalten war unter einem DUron 1000 schon genauso.
> und b) hast Du vielleicht nicht so hohe Anspr�che an das
> Reaktionsverhalten.
Das mag nat�rlich sein.
>> Was war TameDOS nochmal?
> Siehe www.tamedos.com.
Ahja.
> 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%.
Mu� ich mal probieren. Wobei ich erinnere mich da an kleine
Seltsamkeiten damals als dar�ber das erste mal diskutiert wurde.
>>> [...]
>>>>> 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.
Brauchst du nicht mehr machen. Ich habe kurz nach abschicken mal auf
Datum der Datei geguckt und das ver�nderte sich wenn man die PIF Datei
direkt bearbeitete aber nicht wenn man die Eigenschaften des Fensters
bearbeitete. Jetzt hab ich auch keinen Plan wo das gespeichert werden
w�rde.
>>> 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.
Naja du nimmst ja auch hin das dir das komplette System bei Win9x
wegstirbt blo� weil eine Anwendung nen Fehler macht. Und daf�r das du
den Fehler mit den Einstellungen irgendwo finden k�nntest ist DOS wohl
zu wenig verbreitet. Es wird wohl noch genutzt aber nicht in dem Ma�e
als das sowas auffallen w�rde.
>>> 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?
Nein jedes Programm soll seine Temp Dateien in deinem
UserverzeichnisTemp ablegen. Unter Dokumente und Einstellungen....,
welches auch standardm��ig eingestellt ist. Als normaler User hast du
nicht mal Zugriff aufs Windowsverzeichnis.
> [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?
Liegt wohl am Command.Com Fenster von WinXP. Mit dem CMD.EXE gibts da
keine Probleme. Also vielleicht auch an Crosspoint welches immer den
Command.com bei externen Aufrufen nutzt.
>>>> 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).
Nein die DOS Anwendung macht das �ber Windows. Es schreibt nicht
direkt in den Bildspeicher, sonst g�bs keine Probleme mit den
seltsamen Zeilendarstellungen der anderen XPs unter WIndows bei z.B.
36 Zeilen.
Und Tsch�ss J�rg
--
"Hey, how about I call you an idiot in public and you can convict me
for revealing state secrets."
(Matthew Stoner (to Garibaldi), "Soul Mates")
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
