XAaes und Iconify

[HelmutK]

Also wenn ich das richtig verstehe, tritt der Effekt der verlorenen Fenster auch ohne Zusatzprogramme auf?

M.E. kannst Du die fast alle weglassen. Ich hab im auto-Ordner:

bdconfig.sys
dev.dos
fvdi_gnu.prg
hostfs.dos
mintara.prg
nfcdrom.bos
nfstderr.bos

Dabei wird der bei bootsrap ja gar nicht abgearbeitet. Also nvdi starte ich aus mint.cnf, sonst noch ein tool um den key-repeat einzustellen, sonst nichts. ACCs hab ich auch keine. Benutzt Du überhaupt bootstrap?

Mit kernel-Treibern dürfte das auch nichts zu tun haben.

Lass mal wirklich alles weg, auch run in xaaes.cnf, so dass nur qed und teradesk im Spiel sind.

Vielleicht ist es ja nur 7up, da hab ich zwar was, aber der stürzt sofort ab

D:\7UP_209E\7UP_209E.APP

Mit qed hab ich das wie erwähnt durchexerziert, da passiert nichts.

Ich hab in teradesk unter Wndow-Options Save windows slektiert, trotzdem öffnen die Fenster nach teradesk-Neustart unikonifiziert! Was ist das denn schon wieder?

Wenn anstatt Ctrl-I Ctrl-Alt-I (shortcut für iconify) ausgeführt wird, klemmt Alt: einfach 2 Sekunden Alt drücken, dann müsste es wieder gehen.

Ich brauch immer noch mehr Infos, kann es immer noch nicht reproduzieren. Dass das ein Unterschied zwischen linux- und windows-aranym ist, glaub ich nicht.

BTW: sound geht schon ist aber ein anderes Thema.

[Goli]

Danke für die Erläuterungen.

1. bootstrap arbeitet den AUTO nicht ab, sondern startet nur die eingetragenen Programme?

2. nfcdrom.bos brauche ich doch sicher nicht, bei mir kann man nirgends direkt ein CD-Rom anschließen, sondern der Zugriff funktioniert ja über host.fs, oder? CD-ROM geht hier nur über USB.

3. bdconfig ohne beta.dos? Ich habe spdgdos.prg weil ich kein nvdi im System habe

4. Was ist fvdi_gnu.prg, ich habe fvdi.prg      372.344   23 Juli 2007

5. mintara.prg ist bei mir im /system

6. Wenn Du mir mal erklärst, was bootstrap bedeutet?

7. ich habe alle exec in mint.cnf weggelassen, außer
      exec c:\auto\fvdi.prg

8. run in xaaes schau ich mal
        So, hab jetzt auch alle runs weggelassen, außer toswin2, also bgh.prg, xasnap.prg, taskbar.prg

9. Nein der Fensterverlust ist auch ohne 7up wirksam. das habe ich nicht jedesmal gestartet. 7up hat nur den Effekt der Lücke und zwar permanent. 7up gibts bei Gerhard.

10. Ich habe save windows deselektiert und trotzdem merkt sich TeraDesk die Fensterpositionen, also auch das Iconify über den Neustart.

Sorry, habe jetzt erst entdeckt, dass es "Fenster sichern" und "Einstellungen sichern" gibt. Fenster sichern ist in dem anderen Dialog über Farben und Fonts und war bei mir immer an. So nun lege ich erneut los.

11.

Wenn anstatt Ctrl-I Ctrl-Alt-I (shortcut für iconify) ausgeführt wird, klemmt Alt: einfach 2 Sekunden Alt drücken, dann müsste es wieder gehen.

Das habe ich bisher noch nicht beobachtet, muss ich prüfen. Bei mir hat nur einmal die Tastatureingabe versagt, das kommt selten vor. Ist einer dieser undefinierten Zustände. Lässt sich meist durch schließen, öffnen, quit oder Neustart beheben. Da hatte dann auch Ctrl-I versagt und stattdessen Iconify gemacht. Vielleicht hing da ja die ALT.

12. Um sound habe ich mich noch gar nciht gekümmert.

13. Mit dem Netz bin ich einen ganzen Schritt weiter, aber die tun-Schnittstelle lässt noch keine Pings durch. Könnte das mit Firewall oder IP6 zu tun haben? Ich studiere da noch wegen Iptables und so. Jedenfalls funktioniert das eth0 bei mir nur, wenn ich aranym mit sudo starte. Anders garnicht. Weil sonst das aratapif nicht greift und das ist ein binary. Kann ich also nicht beeinflussen. Die Mac-Leute schreiben ja was von aratapif.sh. Das kenne und habe ich nicht.

[Goli]

So ich habe jetzt "Fenster sichern" rausgenommen. Das szenario bleibt trotzdem gleich, Auch die 7up-Lücke bleibt.

Neu ist, dass jetzt auch Teradesk seine Fenster (Iconifyes) verliert. Die Liste der Programme, die es überstehen bleibt ansonsten gleich.

Die überlebenden Iconifyes werden nicht neu sortiert, sondern erscheinen an der alten Position.

Das ganze passiert natürlich auch mit normalen Fenstern, ist also gar kein Iconify-spezifisches Phänomen.

[HelmutK]

Das heißt Du beendest teradesk und das highwire-Fenster ist weg?

xassnap.prg, taskbar und bgh.prg würde ich auch weglassen.

bootstrap findest Du im aranym-config. das muss man natürlich wissen!

fvdi_gnu ist meine Version (hab ich schon 101-mal gepostet):

http://home.arcor.de/zabruder/atari/fvdi_gnu.zip

Vielleicht liegt's ja sogar daran.

CD-ROM-Zugriff klappt natürlich per host-fs ohne Probleme, da braucht man ncihts zusätzlich.

[Goli]

Die Prozedur habe ich oben beschrieben und ist immer gleich. ich beende Teradesk und die Fenster der nichtüberlebenden Programme sind weg im Nirvana, Highwire ist als Programm weg, im Nirvana.

xassnap.prg, taskbar und bgh.prg würde ich auch weglassen.

Ist bereits raus und das Szenario bleibt gleich.

Was aber ist bootstrap und wie finde ich es im config? Ich vermute, dass ich das schon lange mache.

Danke für Deine Version von fvdi, aber was ist daran anders, ist sie neuer aus dem cvs, oder hast du sie gefixed oder wie? Ich hatte sie schon auf der Platte, aber noch nicht benutzt. Alles kann man nicht gleichzeitig testen.  

Sorry, jetzt habe ich erst Dein redme.hk gelesen. Vielleicht habe ich noch Fragen dazu. Du hast ja auch das aranym.sys verändert.

Es gibt auch noch einen neuen Effekt. Ich habe 3 Iconifyes auf dem Desktop, öffne nun per Doppelklick auf LW C:\ und das sich öffnende Fenster geht sofort ins Iconify und legt sich auch noch über das zweite Iconify.

Keine Ahnung wieso so etwas passiert. Aber mein Doppelklick prellt auch gerne mal, das hängt mit dem mousepad zusammen und ich erzeuge den Doppelklick meistens mit der re Maustaste auf dem der Doppelklick eingestellt ist.

Was ist mit fvdi.sys, was bedeutet z.B. das

Code: [Auswählen]

# If fVDI is not being started from the AUTO folder, comment this out.
booted

[Goli]

Das wird ne weile dauern, bis ich da irgendwelche Unterschiede feststellen kann bei Deinem fvdi_gnu.prg und aranym.sys. Bisher fällt mir nichts auf.

Das Szenario ist genau das gleiche mit allen Details wie oben beschrieben.

[HelmutK]

Nochmal: Starte XaAES ohne alles. Starte teradesk, starte highwire, beende teradesk. Ist jetzt das highwire-Fenster und highwire selbst weg?

Vielleicht bist Du mit Deinet Klick.Kunst irgendwie auf das Iconify-widget gekommen?

booted: kann so blieben, hab ich auch. Der einzige Unterschied in meinem fvdi ist, dass sich XaAES neustarten lässt.

Das bootstrap ist im aranym-config: z.B.:

Bootstrap = system/mint.prg

Dann wird der auto-Ordner nicht abgearbeitet, sonst wird's sowieso kompliziert
Wo tust Du denn die updates hin: Nach afros/system oder in den auto-Ordner?

[Goli]

Danke für Erläuterungen.

So, die erste Veränderung ist, dass qed das Prozedere überlebt. Hat es vorher nicht getan, es behält seine Fenster. Ein Programm weniger. 7up verliert es weiterhin. Highwire teste ich jetzt ganz extra noch.

Muss erstmal die ganze Liste abarbeiten.

Was für updates? Du kennst doch mein script. mintara.prg geht nach ~/Aranym/system

/auto befindet sich in ~/Aranym/drive_c/auto

mint.cnf befindet sich in ~/Aranym/drive_c/mint

/xaaes befindet sich ebenfalls in  ~/Aranym/drive_c/mint/1-19-cur/xaaes
xaaes.cnf dto.

config befindet sich auf dem Wurzelverzeichnis von /Aranym

Also  

Code: [Auswählen]

~/Aranym
 ~/Aranym/config
 ~/Aranym/system
 ~/Aranym/system/mintara.prg
 ~/Aranym/drive_c/auto
 ~/Aranym/drive_c/mint/1-19-cur/mint.cnf
 ~/Aranym/drive_c/mint/1-19-cur/xaaes/xaaes.cnf
So ist es Vorschrift von aranym. Afros verwende ich ja nicht wirklich, nur indirekt.

Ich starte aranym jetzt immer so aus dem aranym-Wurzelverzeichnis, also dort wo config sich befindet:

Code: [Auswählen]

sudo /usr/bin/aranym-jit -c config -P 350,70
im mint.cnf steht folgendes exec:

Code: [Auswählen]

exec c:\auto\fvdi_gnu.prg

#exec c:\auto\pgh.prg

#
# start XaAES
#
GEM=u:/c/mint/1-19-cur/xaaes/xaloader.prg

#
# The "echo" command is really straightforward.
#
echo Setup complete, now booting the system...
echo
In config steht

Code: [Auswählen]

Bootstrap = system/mintara.prg
BootstrapArgs = DEBUG_LEVEL=1 BOOT_DELAY=5 MEM_PROT=0 WRITE_BOOT=1
BootDrive = C
edit: Fehler in den Pfaden beseitigt

[HelmutK]

Also bootstratp

Was ich mal nachher probier: GEM=xaloader.prg. Ich boote nämlich normal immer in eine shell, und starte XaAES dann davon.

Inzwischen kannst Du das ja mal probieren, also INIT=/bin/bash -l oder so, und dann cd $SYSDIR/xaaes, und xaloader.prg starten, ob sich da was verändert. Bin gerade anderweiting busy

[Goli]

Mach ich noch.

Liste:
Also highwire stürzt weiterhin ab.
qed verliert keine Fenster mehr.
7up verliert weiterhin seine Fenster
zview ebenso
tw2 ebenso

Also nur qed hat sich verbessert durch Dein fvdi und aranym.sys.

Mehr Programme habe ich ja nicht getestet.

Hyp_view, netsurf, conholio, qed, rsm überstehen alles.

[Goli]

Dein fvdi_gnu.prg ist ja lustig. Wenn ich auf XAaes beenden gehe, wird immer Desktop.prg neu gestartet. Also genau wie XAaes neustarten. Letzteres scheint aber sauberer zu laufen. Wenn noch Programme aktiv sind, dann geht der Restart in einen längeren Flackerzustand, bis endlich der Desktop wieder kommt. Wie gesagt bei XAaes beenden, nicht bei Neustart.

[Goli]

 INIT=/bin/bash -l

Ja funktioniert, der Nachteil man hat vorübergehend keine Maus und kann daher nicht in den Host. ;-)

Aber das ändert nichts am Szenario. Xaaes neustarten killt im übrigen alles.

Doch: es gibt einen Unterschied. QED überlebt das Szenario wieder nicht mehr.
das gesamte Szenario lässt sich mehrfach wiederholen. Also ein geringer Unterschied besteht da.

[HelmutK]

Also ich hab jetzt alles mögliche probiert - es bleibt immer alles i.O., kein Fenster verschwindet oder so.

Wenn Du XaAES per GEM= startest ist das normal, dass er neustartet. Dann ist ja nichts mehr da, also startet xaloader XaAES gleich neu. Das hat allerdings nichts mit fvdi zu tun, außer dass das Original da abstürzt.

Das einzige was mir noch einfällt:
Drück mal Ctrl-Alt-F1 bevor Du teradesk beendest. Dann müsste auf der host-Konsole einiges an Ausgaben erscheinen. Fallls dann wieder Fenster oder Programme verschwunden sind, schick mir den ganzen Krempel und auch xa_boot.log.

[Goli]

Also ich hab jetzt alles mögliche probiert - es bleibt immer alles i.O., kein Fenster verschwindet oder so.

Wenn Du XaAES per GEM= startest ist das normal, dass er neustartet. Dann ist ja nichts mehr da, also startet xaloader XaAES gleich neu. Das hat allerdings nichts mit fvdi zu tun, außer dass das Original da abstürzt.

Ich habe aber jetzt, siehe oben, INIT= gestartet. Und das Beenden von XAaes macht einen Neustart zum Desktop. Das war auch früher so, nur, dass der Desktop dann nicht mehr richtig funktionierte. Ein sauberes Herunterfahren ging bei mir schon immer nur per shutdown aus dem Desktop. Xaaes ist nie sauber heruntergefahren, wenn noch andere Programme aktiv waren. Jetzt aber gibts immer ein Neustart.

Das einzige was mir noch einfällt:
Drück mal Ctrl-Alt-F1 bevor Du teradesk beendest. Dann müsste auf der host-Konsole einiges an Ausgaben erscheinen. Fallls dann wieder Fenster oder Programme verschwunden sind, schick mir den ganzen Krempel und auch xa_boot.log.

Dazu muss ich Dein helmut starten? Das mache ich jetzt sowieso, gestern Nacht gabs noch kein vom Datum im repo. Und mein script verölangt natürlich jetzt immer das vom aktuellen Datum.

Funktioniert bei mir nicht. Es kommen nur die üblichen Meldungen, die immer beim beenden kommen, vom schließen der einzelnen Prozess etc.

Ich bin aber gar nicht sicher, dass DU das alles reproduzieren können musst, da Du doch sowieso einen anderen Rechner hast. Es wäre wohl erfolgversprechender, wenn ich ein bestimmtes Testprogramm oder ein Testszenario kriegen könnte, was ich hier ausprobiere. Wie gesagt, eine geringe Änderung gibt es zwischen fvdi und fvdi_gnu, und auch zwischen GEM= und INIT=. QED spielt nur im mittleren Szenario mit, sonst nicht. Woran könnte das liegen? Und was kann man da testen. Das mit debugging, mache ich natürlich noch.

xa.log - dazu muss ich das logging doch erst wieder anstellen, und wie?

[Goli]

Code: [Auswählen]

Detected scancode offset = 8 (key: 'k' with scancode $2d)
pid   9 (xaloader): run_km(xaaes040.km) ok (bp 0x8E8A160)!
pid   9 (xaloader): run_km: run=0x8E8A260
pid  36 (DESKTOP): p->name=DESKTOP:8D0C61C pgrp=36
pid  36 (DESKTOP): p->name=XaSYS:8E2661C pgrp=20
pid  36 (DESKTOP): SIGTERM -> XaSYS (pid 20)
pid  36 (DESKTOP): p->name=aesthred:8E3661C pgrp=0
pid  36 (DESKTOP): p->name=AESSYS:8E8061C pgrp=18
pid  36 (DESKTOP): SIGTERM -> AESSYS (pid 18)
pid  36 (DESKTOP): p->name=xaloader:8F1261C pgrp=0
pid  36 (DESKTOP): p->name=bash:8F1A61C pgrp=0
pid  36 (DESKTOP): p->name=fvdi_gnu:8F2261C pgrp=0
pid  36 (DESKTOP): p->name=update:8F6E61C pgrp=0
pid  36 (DESKTOP): p->name=MiNT:BE534 pgrp=0
pid  36 (DESKTOP): Close open files ...
pid  36 (DESKTOP): done
pid  36 (DESKTOP): Syncing file systems ...
pid  36 (DESKTOP): done
pid  36 (DESKTOP): Unmounting C: ...
pid  36 (DESKTOP): Unmounting D: ...
pid  36 (DESKTOP): Unmounting E: ...
pid  36 (DESKTOP): Syncing file systems ...
pid  36 (DESKTOP): done
### Compile Block statistics
Number of calls to compile_block : 254000
Total emulation time   : 1052.4 sec
Total compilation time : 3.8 sec (0.4%)
Sorting out untranslated instructions count...
Rank  Opc      Count Name
000: 007c   34841663 ORSR
001: 40c2   19198160 MVSR2
002: 46c2   19197972 MV2SR
003: f228   11305971 FPP
004: 4e73    8663831 RTE
005: 40c3    5395544 MVSR2
006: 46c1    4312518 MV2SR
007: 46c3    3780095 MV2SR
008: 4e69    2826568 MVUSP2R
009: f328    2826557 FSAVE
010: 4e61    2826498 MVR2USP
011: f368    2826442 FRESTORE
012: 40c1    2697188 MVSR2
013: 4e6f    2476969 MVUSP2R
014: 40c6    1895066 MVSR2
015: 46c6    1895023 MV2SR
016: 40c0    1892171 MVSR2
017: 46c0    1892166 MV2SR
018: 40e8    1888899 MVSR2
019: e7f9    1627771 ROLW
[david@Acer Aranym]$


[Goli]

So, ich bin jetzt auf helmut. CTRL-ALT-F1 macht bei mir gar nichts.

xa_boot.log gibts bei mir kein aktuelles. Das letzte ist vom 16.Februar und das kennst Du schon.

[HelmutK]

Dann drück das mal öfter, aber vielleicht ist das bei linux ja auch auch anders.

Ach ja: Diese shortcuts gehen ans host-terminal. Dann musst Du im aranym-config unter BootstrapArgs
DEBUG_LEVEL=2
hinzufügen.

Natürlich wird jedesmal ein xa_boot.log geschrieben. Entweder Du guckst nicht richtig, oder Dein filesystem ist i.A., oder das ist sonst irgendwie deaktiviert.

Was mich noch stutzig macht, sind die vielen unübersetzten Befehle. Bei mir (AMD-dual-core) ist die eigentlich leer: Vielleicht ist Dein Prozessor ja unzulänglich?

[Goli]

Ich glaube dei Funktionstasten sind bei mir auf den Host fokussiert, oder gehen gar nciht in Aranym. kann jeztt nicht denken, was ich für shortcuts mit Fx schon benutzt hätte.

DEBUG_LEVEL=2

Achso, mache ich.

Das xa_log wurde doch abgeschaltet, darum gings doch dauernd in der mailingliste.

Unübersetzte Befehle, davon habe ich keine Ahnung. Ich habe ein Atom-Prozessor, ist natürlich kein Dual-Core, aber doch recht neu und absolut Intel.

Aber das was ich gepostet habe ist doch schon die deinitialisierung, als das Herunterfahren des Systems.

[Goli]

Mmmh, damit habe ich ja schon beim Start unendlich viele debugging-Ausgaben. Willst Du die alle sehen? Nun schreibt er auch wieder ins xa_boot.log. Ist das nun helmut, oder Debuglevel=2? Das Protokoll ist so umfangreich, dass mein bash-buffer garnicht ausreicht.

Was mich noch stutzig macht, sind die vielen unübersetzten Befehle. Bei mir (AMD-dual-core) ist die eigentlich leer: Vielleicht ist Dein Prozessor ja unzulänglich?

Dafür funktioniert es eigentlich zu gut.

Die letzten Zeilen passieren unmittelbar bei Absturz highwire (TeraDesk quit), oder geht das schon früher los? Dann schicke ich mehr:

Code: [Auswählen]

pid   8 (DESKTOP): ufree(0x10BFE40, XaAES:../xa_rsrc.c,1817)
pid   8 (DESKTOP): ufree(0x10B9EFC, XaAES:../xa_rsrc.c,1821)
pid   8 (DESKTOP): freeing p_sigacts for highwire
pid   8 (DESKTOP): ufree(0x10CB000, XaAES:../xa_appl.c,897)
pid   8 (DESKTOP): ufree(0x10B9F4C, XaAES:../xa_appl.c,906)
pid   8 (DESKTOP): ufree(0x10B9F2C, XaAES:../xa_appl.c,908)
pid   8 (DESKTOP): freeing p_fd for DESKTOP
pid   8 (DESKTOP): do_close(terminal): flags=2002 links=7 pgrp=0/8
pid   8 (DESKTOP): do_close(terminal): flags=2002 links=6 pgrp=0/8
pid   8 (DESKTOP): do_close(terminal): flags=2002 links=4 pgrp=0/8
pid   8 (DESKTOP): do_close(terminal): flags=2002 links=14 pgrp=0/8
pid   8 (DESKTOP): do_close(terminal): flags=2002 links=13 pgrp=0/8
pid   8 (DESKTOP): do_close(terminal): flags=2002 links=12 pgrp=0/8
pid   8 (DESKTOP): do_close(terminal): flags=2002 links=11 pgrp=0/8
pid   8 (DESKTOP): freeing p_cwd for DESKTOP
pid   8 (DESKTOP): freeing p_mem for DESKTOP
pid   6 (XaSYS): system process, calling signal handler 0x8EA62DA (20)(XaSYS) directly
pid   6 (XaSYS): freeing p_sigacts for DESKTOP



[HelmutK]

Hab mir fast gedacht, dass es ein Atom ist.

Mit dem xa_boot.log: keine Ahnung.

Schick mir ruhig alles, also die Konsole-Ausgaben, und das xa_boot.log.  Richtig interessant ist natürlich nur der Teil, ab dem teradesk beendet wird.

Ich glaube aber inzwischen fast, dass der atom, auch wenn er von intel ist, evtl. nicht so ganz x386 ist, da ist ja schon einiges dabei, nichtmal RTE wird verstanden, wie soll das denn überhaupt laufen?
Da kann dann alles mögliche passieren, und Du bist als Tester gleich disqualifiziert