Dienstag, 05.10.04 Michael Heydekamp schrub...
Hi!
> J�rg Tewes <[EMAIL PROTECTED]> wrote on 04.10.04:
>> Sonntag, 03.10.04 Michael Heydekamp schrub...
>>> J�rg Tewes <[EMAIL PROTECTED]> wrote on 02.10.04:
>>>>> Ich kann nur �ber die Batches sprechen, die ich schreibe. Und
>>>>> da bin ich �ber Fallen gestolpert, die ich mir nicht habe
>>>>> tr�umen lassen.
>>>> Damit mu� man rechnen wenn man unter verschiedenen Plattformen
>>>> entwickelt.
>>> Ach, sach blo�... Warum, glaubst Du, werfe ich die Batch von
>>> Zeit zu Zeit auf den WinXP-Rechner, um die wichtigsten Routinen
>>> zu testen? Ganz bestimmt nicht, weil ich nicht damit rechne.
>> Deine Aussage h�rt sich so an. Oder wie w�rdest du "h�tte ich mir
>> nicht tr�umen lassen" interpretieren?
> Gar nicht, ich w�rde vor allem den ganzen Satz und auch die davor
> lesen (aka den Zusammenhang zu erkennen versuchen).
Habe ich gemacht und bin zum selben Ergebnis wie vorher gekommen.
> Da� es Inkompatibilit�ten gab, war ja allgemein bekannt und dar�ber
> haben wir schon vor Jahren in den XP2-Gruppen ansatzweise
> diskutiert (da ging's noch um Win2K). Daran k�nntest Du Dich
> vielleicht erinnern, jedenfalls warst Du da anwesend.
Klar erinnere ich mich dunkel.
> Die Aussage war also nicht, da� ich mir nicht habe tr�umen lassen,
> *da�* es Fallen gibt, sondern ich habe mir nicht tr�umen lassen
> *welche* Fallen es gibt. Da� sowas Simples wie "echo 1>test.txt"
> nicht mehr funktioniert, war jedenfalls f�r mich erstmal neu und
> �berraschend.
Aber wieso war es �berraschend? Doch wohl nur weil du erstmal
angenommen hast der command.com der WinNT Derivate funktioniere
genauso wie der von DOS und Win9x. Aber genau das ist das Problem, die
WinNT Derivate haben mit DOS garnichts und mit Win9x bis auf den Namen
nicht mehr sehr viel gemeinsam. Das ein command.com �berhaupt
"mitgeliefert" wird ist nur der Kompatibilit�t geschuldet. Also genau
der Grund warum z.B. Win9x so h�ufig abst�rzt oder gar nur 512 Mbyte
Speicher sinnvoll verwalten und nicht beliebig lange durchgehend
laufen kann. Man m��te also wenn man Batches f�r mehrere OS schreibt
abfragen ob ein command.com vorhanden ist und l�uft oder ob eine CMD-
Shell l�uft. Wenn man das nicht macht, oder spezielle Tools nutzt,
wird man fr�her oder sp�ter auf die Nase fallen.
>>> wes willst Du damit sagen? Da� man auch nicht auf die Idee
>>> kommen d�rfe, da� Batches, die unter dem COMMAND.COM von Win9x
>>> noch gelaufen sind, auch noch unter dem COMMANDN.COM von WinNT
>>> laufen?
>> Genau das! Hatte FreeXP nicht auch Probleme unter einer DOS-Emu
>> unter Linux (ich gehe mal davon aus das auch dort ein command.com
>> zum Einsatz kommt)?
> Es gab was mit Filehandles und DOSBOX, aber nix mit Dosemu. Wobei
> man beides �berhaupt nicht vergleichen kann.
Ahja.
> Wir reden hier �ber Batches. Schon mal "echo 1>tst.txt" unter
> Dosemu oder DOSBOX probiert?
Nein wie sollte ich denn, habe ja kein Linux. Mir war das nur im
Ged�chtnis das es da was spezielles f�r gab.
>> Da hat aber niemand etwas komisch gefunden. Nur weil unter Win NT
>> von dergleichen Firma kommt nimmt man an es w�re dasselbe.
> Oh Mann...
>
> Ich wei� nicht, wer das annimmt. Jedenfalls ist es eine sich
> fortsetzende Linie ein- und desselben Herstellers, und es gibt den
> Support f�r DOS in WinNT aus Gr�nden der Abw�rtskompatibilit�t.
> Und nicht, weil NT selbst den br�uchte.
Ja blo� treibt man gl�cklicherweise diese Abw�rtskompatibilit�t nicht
so weit das das System selbst instabil wird wie bei Win9x. Damit will
ich nicht sagen das der Echo Fall hier etwas gegen die System-
stabilit�t t�te, aber wohin sowas f�rht hat man ja gesehen. Und nein
Win2k/WinXP ist nicht die weiterf�hrende Linie von Win9x oder gar DOS.
Es sind blo� alles OS aus dem Hause Microsoft. Ansonsten hat Win2k/
WinXP bis auf den Namnen nix mit Win9x zu tun.
> Da w�re es nat�rlich zun�chst mal �berhaupt nicht abwegig
> anzunehmen, da� es sich eben auch um eine solche (also
> Kompatibilit�t) handelt.
Wenn man deine Annahmen als gegeben annimmt ja ansonsten nein. Ich und
die meisten die mit den WinNT Derivaten arbeiten tun das nicht. Da
ists ein Wunder wenn es funktioniert. Weil es normalerweise nicht
gedacht ist als Ersatz f�r DOS herzuhalten.
>>> Auch wenn man eine Umgebung emuliert, ist es m�glich, nicht
>>> solche Fallen einzubauen. Die Differenzen
>>> Linux<=>COMMAND/CMD(WinNT) mit den Differenzen
>>> COMMAND(Win9x)<=>COMMAND/CMD(WinNT) gleichzusetzen, ist ja wohl
>>> ein schlechter Scherz.
>> Nein finde ich nicht. Beides Mal ists ein v�llig andere OS.
> Iss klar... Eigentlich sind sich Windows und Linux viel �hnlicher
> als Windows und DOS. <g>
In der Behandlung der Commandzeile sicherlich.
>>> Alleine schon, weil Linux keine DOS-Batches kennt,
>>> COMMAND/CMD(WinNT) aber schon.
>> In der DOS Emulation kennt auch Linux DOS Batches.
> H��lf����....
>
> Du hattest doch IIRC von Linux-Scripten gesprochen, von denen
> keiner auf die Idee k�me, da� sie unter DOS (oder Windows?) laufen
> k�nnten, richtig? Also reden wir von perl u.�., richtig?
Nein, Perl ist ne eigene "Sprache" ich rede von sowas
if test -n "$1"; then
type="$1"
else
type="fast"
fi
time cdrecord \
-v \
speed=99 \
dev=0,5,0 \
blank=$type \
-force
> Sicher, die DOS-Unterst�tzung bei WinNT/2K/XP mu� man sich erst
> nachtr�glich von einem third-party-Hersteller besorgen.
Nein nat�rlich nicht. Hat aber nix zu tun damit.
>>> Mit derselben Argumentation k�nntest Du darlegen, da� man nicht
>>> auf die kommen d�rfe, DOS-Programme (statt DOS-Batches) w�rden
>>> unter WinXP noch laufen.
>> Und wenn DOS Programme unter Windows nicht 100%ig so laufen wie
>> unter reinem DOS ist das was?
> Sorry, es ging nicht darum, wie sie laufen, sondern darum, *ob* sie
> laufen:
Naja ich war davon ausgegangen das du nur bem�ngelst das sie nicht
ganz das machen was du m�chtest aber im Prinzip schon funktionieren.
> ----------8<----------
>>>> Niemand w�rde auf die Idee kommen, das Scripts die unter Linux
>>>> entwickelt und verwendet werden unter DOS oder Windows laufen.
> ----------8<----------
> Daraus war Deine Schlu�folgerung, da� man bei Batches auch nicht
> auf die Idee kommen w�rde.
Ok Fehler meinerseits, "nicht auf die Idee kommen d�rfte" war gemeint.
Aber es ging eigentlich ja darum das es nicht funktioniert wie
gew�nscht. Also es kommt nicht die Fehlermeldung das der Batch kein
Windows Programm w�re sondern es funktioneirt nicht wie gew�nscht. Im
Endeffekt komts nat�rlich auf dasgleiche raus, obwohl ich nicht wei�
was der nicht funktioneirende Echo Befehl hier f�r eine Wirkung hat,
aber im Prinzip funktioniert die Batchdatei ja.
>> Ich meine nat�rlich kann man auf die Idee kommen das DOS Programme
>> unter Windows laufen,
Ich f�ge das von dir nicht zitierte mal hier wieder ein, sonst
entsteht noch der Eindruck du w�rdest sinnentstellend zitieren.
[*Zitat*]
Ich meine nat�rlich kann man auf die Idee kommen das DOS Programme
unter Windows laufen, aber man sollte sich nicht wundern wenn sie
nicht so laufen wie unter reinem DOS.
[*Zitat Ende*]
> Ach, doch jetzt?
Man kann auf ganz andere Ideen kommen, man sollte sioch blo� wie schon
oben geschrieben nicht �ber das Ergebnis wundern.
> Also gibt's schon einen ganz kleinen Unterschied in der Bewertung
> DOS<=>Windows und Linux<=>Windows?
Sicher gibts einen Unterschied. Allerdings eben nur einen kleinen. Bei
Linux mu� man DOS Unterst�tzung besorgen bei Windows NT ist sie dabei.
Wohlgemerkt DOS Unterst�tzung keine 100%ige Kompatibilit�t.
>> Das Problem d�rfte doch eher sein das es fr�her nur DOS und Win9x
>> gab, was zumindest f�r DOS Programme dasselbe ist,
> Nope. Schon da gibt's Unterschiede, auch in der Batchverarbeitung.
> Was es nicht besser macht.
Schwerwiegende Unterschiede?
> Es ist technisch durchaus m�glich, eine DOS-Emulation zu bauen, die
> wie bisher "echo 1>test.txt" kann. Selbst f�r Microsoft.
Ja aber eben nicht gewollt. Nehme ich mal an, vielleicht haben sie es
ja auch einfach nur vergessen.
Und Tsch�ss J�rg
--
"Life is life, whether it's wrapped in skin, scales, or feathers.
Now if you respected these beings instead of constantly trying to
murder them, you'd appreciate that!"
(Dr. Franklin (to his father), "GROPOS")
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
