J�rg Tewes <[EMAIL PROTECTED]> wrote on 30.08.04:
> Montag, 30.08.04 Michael Heydekamp schrub...
>>> UKAW bzw. die Programme E-Agent, E-News und E-Mail laufen als
>>> eigenst�ndige 32bit Consolenprogramme wenn sie aus Crosspoint
>>> heraus aufgerufen werden.
>> Eben - und genau deshalb wird dazu eine CMD.EXE gestartet (*weil*
>> es aus einer COMMAND-Umgebung heraus aufgerufen wurde).
"COMMAND-Umgebung" ist unpr�zise bis falsch, "NTVDM-Umgebung" w�re
richtiger gewesen, ich benutze das oft synonym.
Aber die Aussage gilt f�r eine COMMAND-Umgebung (weil auch das ein
16bit-Programm und somit eine NTVDM-Umgebung ist) nat�rlich genauso.
> Kann ich hier nicht so sehen. Wenn ich den E-Agent aufrufe ist nur
> der E-Agent im Taskmanager zu sehen.
> Kein Hinweis auf die CMD.EXE.
Es geht doch, wie Du selbst schreibst, um das Szenario "wenn sie aus
Crosspoint heraus aufgerufen werden".
Das ist was anderes, als wenn Du E-AGENT solo (z.B. Doppelklick auf
E-AGENT.EXE) startest. Da siehst Du nat�rlich keine CMD.EXE.
>> Jedenfalls sehe ich das im Task-Manager so, wenn ich ein anderes
>> 32bit- Konsolenprogramm (OpenXP) aus einem COMMAND.COM heraus
>> starte (das ist damit etwas komfortabler zu testen als mit UKAW).
> Wie startest du OpenXP aus einem COMMAND.COM?
Start/Ausf�hren, "command" eintippen, <Enter>. :) Am Prompt dann
"openxp" eintippen (vorher ggf. ins entsprechende Verzeichnis wechseln).
So, wie das schon unter Win9x ging.
> Ich rufe OpenXP immer direkt auf und dann steht auch nur die
> OpenXP.EXE im Taskmanager.
Nochmal: Es ging um die Reproduktion des Szenarios "UKAW (32bit) aus XP
(16bit) heraus starten".
Das ist prinzipiell dasselbe wie "OpenXP (32bit) aus COMMAND (16bit)
heraus starten", nur da� es komfortabler zu testen ist, weil man es
nicht w�hrend eines Netcalls machen mu� und mehr Zeit zum Nachsehen hat,
was passiert.
In beiden F�llen wird eine CMD.EXE gestartet und lungert auch bis zur
Beendigung des 32bit-Programms als besch�ftigungsloser Task herum.
Das nur mal als Fakt. Was man daraus jetzt schlie�en kann, ist wieder
eine andere Frage, dazu unten mehr.
>> Und an letzterem kann es schlecht liegen, denn wir sind uns ja bei
>> allen Differenzen wohl zumindest darin einig, da� UKAW *nicht* in
>> einem COMMAND.COM l�uft, oder? Nur das wollte ich mal festhalten,
>> bevor wir uns wieder in andere Aspekte verzetteln.
> Aber das COMMAND.COM Fenster von Crosspoint ver�ndert sich doch in
> der Gr�sse.
Wann jetzt? Und was vor allem schlie�t Du daraus bzw. was beweist das
und worauf willst Du hinaus?
Falls Du beim UKAW-Netcall meinst: Das habe ich auch schon beobachtet
(siehe auch mein FAQ-Posting), aber zwingend ist das Verhalten
vermutlich nicht. Ich werde das noch genauer testen. Es hat aber mit
der eigentlichen Frage nix zu tun.
> Was da jetzt zum Zeitpunkt des UKAW Aufrufs aktiv ist kann ich nicht
> feststellen. Im Taskmanager ist allerdings beim Mail holen/
> wegschicken und beim posten nur die E-Agent.exe und die NTVDM.EXE
> aktiv.
Glaub' ich nicht. Vermutlich hast Du "cmd.exe" in der ganzen Latte
anderer Tasks (*nur* E-AGENT und NTVDM kann ja sowieso nicht sein, dann
w�rde Windows nicht laufen) schlicht �bersehen.
Anyway, um das vielleicht mal zum Abschlu� zu bringen:
Ich hab' mich auf anderer Ebene nochmal etwas schlauer machen lassen.
Es ging ja um die Frage, ob eher Windows oder UKAW f�r das Verhalten
verantwortlich ist, da� nach einem Netcall der Fenstertitel nicht auf
den bisherigen zur�ckgesetzt wird.
Wenn ein 32bit-Programm aus einem 16bit-Programm heraus ausgef�hrt wird,
wird CMD.EXE wohl quasi als "Launcher" ben�tigt, damit das 32bit-
Programm �berhaupt gestartet werden kann (deshalb der oben von mir
beschriebene Effekt des Ladens der CMD.EXE). COMMAND.COM oder XP als
16bit-Programme "d�rfen" keine 32bit-Programme ausf�hren, daher bedient
sich WinXP der CMD.EXE.
Da� die CMD.EXE bis zur Beendigung des 32bit-Programms als Task
herumlungert, hat vermutlich den Zweck, dem 16bit-Programm eine
Information zukommen zu lassen, da� das 32bit-Programm beendet ist und
das 16bit-Programm jetzt weiterlaufen darf.
Man kann daraus jetzt keine zwingenden Schl�sse hinsichtlich der
Beantwortung der eigentlichen Frage ziehen. Da unter Win9x aber der
Fenstertitel restauriert wird und unter WinXP nicht, neige ich eher
dazu, die "Schuld" Windows in die Schuhe zu schieben.
Was ich mir vorstellen bzw. zusammenreimen k�nnte: UKAW setzt den Titel
prinzipiell schon zur�ck, �bergibt diese Information aber an das
Programm, von dem es aufgerufen wurde - also an die immer noch im
Hintergrund lauernde CMD.EXE.
Die nimmt das zwar zur Kenntnis, beendet sich dann aber, ohne diese
Information an das Fenster weiterzureichen, in dem das aufrufende
16bit-Programm (in diesem Fall XP) l�uft (und in dem UKAW vorher
gelaufen ist).
Aber auch das ist letztlich nur vermutet, wenn auch mit etwas mehr Hand
und Fu� als es die bisherigen Vermutungen hatten.
[Blinkender Cursor nach UKAW-Netcall in Zeile 11]
>> Siehe oben - unmittelbar nach dem Netcall in User- oder Brettliste
>> (also im Hauptfenster von XP). Ob es *nur* nach UKAW-Netcalls
>> auftritt, wei� ich noch nicht, aber danach auf jeden Fall immer.
> Ich achte beim n�chsten Mal genau drauf ob nach dem UKAW NEtcall
> passiert.
Und?
Michael
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
