Probleme eine .bat Datei zu öffnen!

[antred]

Au Backe, das sieht wieder mal nach Software aus, die die Welt nicht braucht. Schreiben wir doch mal eben irgend was ins Windows-System-Verzeichnis, kopieren einen Haufen Dateien in irgend ein Verzeichnis nach C:\ und kümmern uns auch generell nicht um Fehlerbehandlung. Einen gescheiten, konfigurierbaren Installer bauen? Wozu das denn ...

Ich glaube, anstatt Schulungssoftware zu schreiben, sollten diese Sontagsprogrammierer erst mal selber ein paar Schulungen zum Thema robuste, flexible Software-Entwicklung besuchen.

EDIT: Sorry, mein kleiner Wutanfall hilft dir natürlich nicht die Bohne weiter, aber da ich häufig selbst mit dermaßen mies zusammengeschusterter "Software" zu tun habe, krieg ich immer die Krätze, wenn ich so was sehe.

 

[Zwinke]

Nun, ich habe den XP Mode gestartet. Dieser Modus erkennt zwar auch meinen Stick, auf dem die Software ist, jedoch kann ich den Stick nicht öffnen bzw die Datei herüberziehen.

Wie bringe ich das nun Zustande, diesen Ordner mit dem Programm in den XP Mode zu bekommen?

 

[Out_of_CTRL]

Wie bringe ich das nun Zustande, diesen Ordner mit dem Programm in den XP Mode zu bekommen?

Ich bezweifle, dass das unter XP laufen wird. Nun denn, Stick mit Fat32 formatiert?

 

[cbtestarossa]

@ antred

das war früher bis 98 gang und gäbe.
Da war man schon froh wenn die Programme ihre DLLs in ihrem eigenen Ordner installiert haben.

Gab auch Spiele die über ein installiertes DX7 ein DX5 ungefragt drüberbügelten und dann war mal wieder die Hölle los da MS da keinen Schutz eingebaut hatte im DX-Installer..
Bei diversen runtimes war das ebenso.

Die alten OS prüften da nicht wirklich und Usertrennung gab es nicht.
Alles lief mit Admin Rechten naja und mit Fat16/32

 

[asdfman]

tbctestrosa: Warum reitest du dich denn immer weiter rein? Ist doch nicht schlimm, wenn man sich mal vertut. Du hast doch auch was davon, wenn du deinen Irrtum für dich korrigierst.

Im einzelnen:

seltsamerweise laufen batch-dateien in CMD schneller als in BAT. (Selber Code) wird schon was dran sein.
zumindest bei 32bit Win

Dieses Gestammel ergibt von vorn bis hinten überhaupt keinen Sinn. "Batch-Dateien in CMD schneller"? Meinst du mit CMD die NT-Konsole? Wenn ja, was soll dann "in BAT" ausführen sein? Und was hat den selben Code wie was jetzt überhaupt?
Meinst du vielleicht, dass der Interpreter der NT-Konsole das selbe Skript schneller ausführt, wenn es die Endung .cmd hat, im Vergleich zu .bat? Wie hast du das gemessen? Und wie soll das überhaupt zustande kommen, wenn das selbe Skript im selben Interpreter ausgeführt wird?
Ob man den Vergleich unter 32Bit oder 64Bit NT macht, kann auch keinen Einfluss haben. Beide Male wird der selbe Interpreter benutzt. Unter 32Bit NT hat man zwar eine NTVDM, aber was spielt das denn für eine Rolle? Wenn kein 16Bit-Code (PE, MZ oder COM Binary) ausgeführt wird, wird sie überhaupt nicht angesprochen.

hm unter win3.11 gab es glaub sogar schon win32s, ist schon lange her

Win32s hat nichts mit dem Win32-Subsystem von NT zu tun. Es ist eine Teilimplementierung der Win32-API für 16bit Windows. Und selbst die vollständige Win32-API ist vom Win32-Subsystem unabhängig. Denn die gab es auch in Betriebssystemen, die überhaupt kein NT waren (Windows 95, 98, etc).

@ antred

das war früher bis 98 gang und gäbe.
Bla fasel schwurbelwurbel wuseldusel

Komplett an antreds Beitrag vorbei gelabert. Der ärmste.

 

[cbtestarossa]

@asdfman
Und was du von dir gibst intressiert mich nicht im geringsten.
Darum bist du auch auf ignore ab jetzt.

 

[BloqueNegro]

Und was du von dir gibst intressiert mich nicht im geringsten.

Was ein Pfosten. Sind deine Beiträge immer so qualitativ hochwertig

Zur Erklärung: Eine BAT-Datei enthält mehrere Shell-Commands für die alte CommandLine, welche seit Urzeiten verfügbar ist. Wir kennen die heute als cmd.exe. Diese stellt eine Interpreter-Funkrtion bereit, kann diese Textanweisungen nun in Maschinencode umwandeln und ausführen.

command.com ist der Vorgänger der CMD.exe, aus Gründen der Abwärtskompatiblität kann die cmd.exe alles was früher die com konnte (und mittlerweile auch mehr).

Ich rate dir: Setz in einer VM (VirtualBox o.ä.) ein Win7 x86 oder sogar ein XP auf und lass die Software dadrin laufen. Diesen Installationsprozess willst du nicht auf einem PC, und schon gar nicht auf einem produktiven (also ein Gerät mit dem Geld verdient wird) PC laufen lassen

 

[cbtestarossa]

nein es geht um den Unterschied der Geschwindigkeit beim Aufruf einer .BAT oder einer .CMD mit selben Code drinnen.
Ich hab es getestet und beide Dinge ausgeführt. Der Speed ist ein gewaltiger Unterschied.
War XP32. Kann sein dass es sich nicht überall gleich auswirkt.

 

[BloqueNegro]

Ich hab es getestet und beide Dinge ausgeführt. Der Speed ist ein gewaltiger Unterschied.
War XP32. Kann sein dass es sich nicht überall gleich auswirkt.

Wie? Welche Messparameter hast du da genommen? Beides wird, schon seit Win2k, an die cmd.exe übergeben. Ein Unterschied ist somit quasi unmöglich.

 

[cbtestarossa]

Der Code ruft hintereinander eine EXE auf und die scannt damit alle Laufwerke auf ADS.
Mit .BAT kannste toll mitlesen. Mit .CMD siehst du den Text nur so vorbeifliegen und der Scanvorgang ist auch schneller fertig.

Es ist ein Unterschied und der ist auch messbar.

 

[VikingGe]

Code, mit dem das ganze reproduzierbar ist, or it didn't happen. Oder haben die Leute auf Stackoverflow jetzt plötzlich auch alle keine Ahnung?

 

[thecain]

@echo off
set "startTime=%time%"
for /L %%n in (1,1, 10000) do <nul set /p "="
set "stopTime=%time%"
call :timeDiff diff startTime stopTime
echo %diff% milli seconds
pause
goto :eof

:timeDiff
setlocal
call :timeToMS time1 "%~2"
call :timeToMS time2 "%~3"
set /a diff=time2-time1
(
  ENDLOCAL
  set "%~1=%diff%"
  goto :eof
)

:timeToMS
::### WARNING, enclose the time in " ", because it can contain comma seperators
SETLOCAL EnableDelayedExpansion
FOR /F "tokens=1,2,3,4 delims=:,.^ " %%a IN ("!%~2!") DO (
  set /a "ms=(((30%%a%%100)*60+7%%b)*60+3%%c-42300)*1000+(1%%d0 %% 1000)"
)
(
  ENDLOCAL
  set %~1=%ms%
  goto :eof
)

Habe jetzt extra getestet... "Didn't happen" triffts... Man sieht auch, dass zwei mal cmd.exe aufgerufen worden ist.

Kannst ja gerne mal auf Windows xp ausführen

 

[Yuuri]

@echo off
setlocal enabledelayedexpansion

echo start @ %time%

for /L %%x in (0,1,1000000) do (
	set /A a=%%x-%%x
)

echo end @ %time%

20 * 1.000.000 Iterationen:

Durchschnitt pro Lauf (Server 2008 R2 x64):
bat: 51.696923072521 s
cmd: 53.235897443233 s

Fazit: gleiche Abarbeitungszeit

 

[cbtestarossa]

hm, eventuell liegt es am XP32 dass da noch etwas mitgeschleift wird im Hintergrund und ab vista nicht mehr.
Finde auch den Beitrag nicht mehr wo es stand.
Naja lebenswichtig ist es eh nicht.

 

[Yuuri]

Obige Batch in einer relativ jungfräulichen XP Prof. x86 SP3 VM (nur zum Testen vom IE 6 benötigt + Office 2007 installiert).
bat: 7.3856410246629 s
cmd: 8.2138461455321 s

 

[cbtestarossa]

hm, naja die batch die ich getestet habe ruft halt noch ne exe auf die wiederum auf der Platte herumsucht
seltsam ist es weil es echt schneller lief

 

[Out_of_CTRL]

Mich würde ja mal interessieren, ob der Ersteller dieses Themas das Ding zum Laufen gebracht hat?!?

 

[cbtestarossa]

in ner vm wahrscheinlich schon

 

[Darlis]

Der Code ruft hintereinander eine EXE auf und die scannt damit alle Laufwerke auf ADS.
Mit .BAT kannste toll mitlesen. Mit .CMD siehst du den Text nur so vorbeifliegen und der Scanvorgang ist auch schneller fertig.

Klarer Fall: Bei ersten Durchlauf werde die Daten in den (Datei-)Cache geschrieben, beim 2. wird daraus gelesen. So kann man jeden Benchmark verfälschen.

 

[BloqueNegro]

Der Code ruft hintereinander eine EXE auf und die scannt damit alle Laufwerke auf ADS.
Mit .BAT kannste toll mitlesen. Mit .CMD siehst du den Text nur so vorbeifliegen und der Scanvorgang ist auch schneller fertig.

gegen derart wissenschaftliche Vorgänge habe ich natürlich keinerlei Chance