ArcaOS startet nach dem Hochfahren 20 Editoren
-
- Beiträge: 469
- Registriert: Di 19. Aug 2014, 09:30
ArcaOS startet nach dem Hochfahren 20 Editoren
Ich habe ein ganz merkwürdiges Verhalten: ArcaOS startet nach dem Hochfahren 20 Editoren aus überwiegend demselben Verzeichnis. Ich habe schon geschaut, es ist kein Arbeitsordner. Ich konnte das jetzt unterdrücken, indem ich in der config.sys geschrieben habe:
SET RESTARTOBJECTS=NO
Aber wie kommt das? Ich habe OS/2 wirklich schon lange, das habe ich aber noch nie erlebt. Es scheint in der Ini-Datei etwas schiefzulaufen. Wenn ich in der config.sys die Einstellung rückgängig mache, kommt wieder dasselbe Verhalten.
SET RESTARTOBJECTS=NO
Aber wie kommt das? Ich habe OS/2 wirklich schon lange, das habe ich aber noch nie erlebt. Es scheint in der Ini-Datei etwas schiefzulaufen. Wenn ich in der config.sys die Einstellung rückgängig mache, kommt wieder dasselbe Verhalten.
Danach sollte endgültig Ruhe sein:
Code: Alles auswählen
SET RESTARTOBJECTS=STARTUPFOLDERSONLY,REBOOTONLY
... und wenn es mit STARTUPFOLDERSONLY immer noch Ärger geben sollte (eher unwahrscheinlich):
Die Einstellung, dass ein Ordner als OS/2-Startordner funktioniert, ist in OS2.INI, PM_Workplace:Startup gesichert. Dort sollte genau ein Eintrag stehen. Wenn man die XWP-Startordner verwendet, braucht da auch kein Eintrag zu sein. Die sichern diese Eigenschaft anders.
Die Einstellung, dass ein Ordner als OS/2-Startordner funktioniert, ist in OS2.INI, PM_Workplace:Startup gesichert. Dort sollte genau ein Eintrag stehen. Wenn man die XWP-Startordner verwendet, braucht da auch kein Eintrag zu sein. Die sichern diese Eigenschaft anders.
Andreas Schnellbacher
-
- Beiträge: 469
- Registriert: Di 19. Aug 2014, 09:30
Code: Alles auswählen
SET RESTARTOBJECTS=STARTUPFOLDERSONLY,REBOOTONLY
In der Ini-Datei sind fünf Einträge:
6BE9=Y
9DF2=Y
AABB=Y
C4C2=Y
E423=Y
Sind das interne WPS-Kennungen von WPS-Objekten? Welcher ist der, der bleiben soll?
Wenn Du davor eine 3 (3 für Dateisystemobjekte) ergänzt und den Wert "=Y" weglässt, sind das Object-Handles.
Welche Einträge ungültig sind, findest Du so heraus (gilt nicht für XWP-Startup-Ordner):
o Kontextmenü des Startup-Ordners öffnen.
o Seite "Icon".
o Knopf "Details..."
o Unter "Object handle" findest Du den gültigen Wert.
Den Eintrag, den Du unter "PM_Workplace:Startup" behalten musst, erhältst Du dadurch, dass Du von dem gefundenen Object-Handle "0x3" am Anfang entfernst.
Welche Einträge ungültig sind, findest Du so heraus (gilt nicht für XWP-Startup-Ordner):
o Kontextmenü des Startup-Ordners öffnen.
o Seite "Icon".
o Knopf "Details..."
o Unter "Object handle" findest Du den gültigen Wert.
Den Eintrag, den Du unter "PM_Workplace:Startup" behalten musst, erhältst Du dadurch, dass Du von dem gefundenen Object-Handle "0x3" am Anfang entfernst.
Andreas Schnellbacher
- Sepp Mayr
- Beiträge: 150
- Registriert: Mo 13. Jan 2014, 11:28
- Wohnort: Bayern, oda wos hobt ihr dachd?
- Kontaktdaten:
Merkwürdige Sache, hatte ich früher bei Warp4 oft. Da hat es meist geholfen diese beiden Tools laufen zu lassen:
Henk Kelder's Checkini (WPTools)
Carsten Arnold's Cleanini
Oder die Einträge in PM_Workplace:Startup zu löschen. Aber ist lange her …
Henk Kelder's Checkini (WPTools)
Carsten Arnold's Cleanini
Oder die Einträge in PM_Workplace:Startup zu löschen. Aber ist lange her …
Mia san mia
Ich hatte das natürlich auch schon. Evtl. kommt es dadurch, dass man mit der WPS den Desktop (oder Unterverzeichnisse) einer anderen OS/2-Installation öffnet. Die Schablonen vermehren sich dadurch nämlich ganz ordentlich. Warum nicht auch diese Einträge?
Seitdem ich darauf achte, dass nicht mehr mit der WPS zu machen (FM/2 ist OK, weil nur PM), ist beides nicht wieder aufgetreten.
Seitdem ich darauf achte, dass nicht mehr mit der WPS zu machen (FM/2 ist OK, weil nur PM), ist beides nicht wieder aufgetreten.
Zuletzt geändert von aschn am Fr 15. Jun 2018, 17:49, insgesamt 1-mal geändert.
Andreas Schnellbacher
Bei mir passierte das sehr oft. Ich habe drei eCS-Installationen parallel. Es öffneten dann manchmal hunderte von Fenstern nach dem Boot. Seitdem ich regelmäßig alle zwei Wochen die INIs reinige (nacheinander mit INImaint, CleanINI und Xfix; auf diesen PCs funktioniert CheckINI nicht mehr) ist Ruhe auf der WPS.
Kann das der Fehler bei CHECKINI sein?
/T
Use this switch to enable the disk scan function of CHECKINI.
This will amongst other things repair non-functioning Startup
folders.
NOTE: THIS SWITCH SHOULD NOT BE USED IF YOU HAVE MORE THEN ONE
VERSION OF OS/2 INSTALLED ON YOUR SYSTEM.
/T
Use this switch to enable the disk scan function of CHECKINI.
This will amongst other things repair non-functioning Startup
folders.
NOTE: THIS SWITCH SHOULD NOT BE USED IF YOU HAVE MORE THEN ONE
VERSION OF OS/2 INSTALLED ON YOUR SYSTEM.
Zum nicht funktionierenden CHECKINI unter ArcaOS hatte ich ein Ticket eingestellt.
Durch eine Umgehungslösung ist dieses Problem in meiner Installation gefixt.
Dies ist die Umgehungslösung:
"checkini /h /r"
Seit diese Zeile mitläuft, friert CHECKINI bei mir nicht mehr ein.
Durch eine Umgehungslösung ist dieses Problem in meiner Installation gefixt.
Code: Alles auswählen
/* REXX */
/*Language = value('TCPLANG',,'ENVIRONMENT') */
"mode 80,50"
"fpos"
"checkini /h /r"
/* checkini /C /W /DD:\Arbeitsoberfläche /Y:2 /T */
"checkini /C /W /S /Y:2 /T"
"pause"
"cleanini /Delall /remote:delete /multipass /C /restart"
"pause"
call "rmdesktopfolderpos"
return
"checkini /h /r"
Seit diese Zeile mitläuft, friert CHECKINI bei mir nicht mehr ein.
Ja, das mit checkini /h /r funktioniert. Allerdings war ich seitdem (vielleicht zu) mißtrauisch und habe checkini nicht mehr auf diesen PCs verwendet. Mit INImaint, CleanINI und Xfix geht es ja auch.
Wichtig ist ja wohl, daß die INIs schön glänzend geputzt sind
Wichtig ist ja wohl, daß die INIs schön glänzend geputzt sind
