Zum Thema 'OS/2-Fenster' und warum wir es voraussetzen:
1.) DOS-Fenster ist m. E. eher die Ausnahme
2.) Beim Start von der WPS aus (per Icon) ist prinzipiell vorher festgelegt, was ausgeführt wird (der Typ der Anwendung ist klar).
Zum Them Path: d'accord.
Zum Thema C:UTILS (im OS/2-Fenster):
Ist in c:utils eine ruf.bat, wird vom OS/2-Fenster aus eine DOS-Session aufgemacht und ruf.bat ausgeführt, wenn man RUF eingibt. Ist aber auch noch eine RUF.CMD vorhanden (und kein RUF.COM oder RUF.EXE), dann wird RUF.CMD ausgeführt. Nebenbei: RUF.COM/EXE können natürlich auch DOS-Anwendungen sein, das beeinflußt die Suchreihenfolge aber nicht weiter, da OS/2 das erst beim Laden des Programmes prüft.
Beim Aufruf aus der DOS-Kommandozeile wird die Endung .CMD ignoriert, weil der DOS-Kernel nur COM, EXE und BAT kennt. Hier läuft also auf jeden Fall eine vorhandene RUF.BAT (auch wenn in diesem Verzeichnis noch eine RUF.CMD drin sein sollte).
Und übrigens: bei Windose ist die DLL-Hölle systemimmanent, bei OS/2 meist hausgemacht, aber man bekommt es durchaus hin (s. LIBPATH, der sicher nicht nur bei mir immer länger wird). Habe ich im Zusammenhang mit LAN Distance und Communications Manager/2 erlebt... eine DLL mit gleichem Namen bei LAN Distance und CM/2, LAN Distance im LIBPATH vor CM/2, und die Inkonsistenz war perfekt. Wenigstens kann man bei OS/2 per LIBPATH neu sortieren, bei Windose hilft hier nach meiner Erfahrung nur die Neuinstallation (aber die ist da ohnehin in regelmäßigen Abständen ratsam).
[ Leser: 53 ] |