[Allegro] problem mit index.exe(11.okt.2005) in arbeitsumgebungen mit restriktionen

[Klaus Lehmann]

On Tue, 13 Dec 2005 09:12:59 +0100, Anando Eger wrote:

guten tag herr berger und herr eger,

(das ist ein sehr interessanter UND ergiebiger thread. 
danke vielmals!)


kl>2. Das Entstehen von VDM*.tmp-Dateien verhindern

es waren in dieser liste schön öfters kollegen am verzeifeln, die von
unmengen von vdm-datein geschrieben haben, die sich pro sekunde in
tauserderzahl produziert haben.....
ich weiss nicht mehr, wer ob dieser dateien so verzeifelt war.....




kl>3. DOS-Menüsysteme, die das Environment des aufrufenden Prozesses
kl>   ändern, sollen funktionieren
kl>4. Nutzung von residenten Hilfsprogrammen

a-w wäre interessant.
obwohl bei solchen alt-dossigen tool ist es manchmal etwas gefährlich,
sie zu nutzen....


herrn bergers bemerkung zu dhougmenu: wenn man eine betreuung einer
solchen von dougmenü geplagten übernimmt, und die bibliothek nur mit
doug arbeiten kann, dann ist es doch gut, wenn man doug ins wxp
integrieren kann. ich persönlich empfinde doug auch als sehr großes
übel, weil zu komplex. lieder arbeite ichm it einem eigens
entwickelten, basierend auf tools aus BS, dieses ist flexibler (ja,
doug ist auch flexibel, ohne frage!), aber meines ist durchsichtiger!
;-)
bislang hatte ich keine probleme mit dem menü..... (mal diesen thread
nicht berücksichtigt)
keine ahnung, was passiert, wenn CAIRO oder NILDELTA kommen..... zur
nächsten wxp-version ist es noch lang, dann werden die karten sowieso
neu gemischt! ;-)



kl>5. Laufzeiteffekte beim Dateizugriff, wenn bat-Dateien von cmd.exe
abgearbeitet  
kl>   werden und in der Folge mehrmals nacheinander die NTVDM gestartet
und wieder
kl>   beendet wird (hier hilft manchmal die Systemeinstellung
"Optimierung für 
kl>   Hintergrundprozesse") - bat-Dateien unter der Steuerung von
command.com 
kl>   bei aktivem DOSONLY verursachen keine Laufzeiteffekte, die durch
die
kl>   Umschaltung zu CMD.EXE verursacht werden.
kl> 
kl>> ich weiss. Stoert mich aber nicht, weil ich mit CMD.EXE durchaus
kl>> zufrieden bin (unter COMMAND.COM gibt es ja bei WinXP keine
kl>> History mit den Pfeiltasten und noch nicht einmal das F3 des
kl>> "echten" DOS). D.h. sollten einander aufrufende Stapeldateien
kl>> aus irgendwelchen Gruenden in COMMAND.COM abrutschen,
funktionieren
kl>> sie prima, 
kl>
kl>solange Sie eben den Umgebungsbereich nicht ändern und keine zu
kl>großen Dateien schreiben

zu anfangszeiten, als w2k und wxp auf den plan traten, und die kollegen
mit ihrem allegro auf diese maschinen wechselten, lief keine dossiges
allegro mehr auf diesen maschinen. ich habe die erkenntnis damals
gewonnen, dass eben config.nt anzupassen war. ohne diese manipulationen
ging es nicht.

schön, wenn h. berger config.nt NICHT anzupassen braucht. 
man müsste es mal wieder wagen..... mit einer nackigen config.nt....
;-)




kl>> und ich an der Oberflaeche habe stets CMD und merke
kl>> nichts davon (zumal ich den Aufruf von ansi.com nie eintippe,
kl>> und wenn man ihn aus cmd.exe von einer Stapeldatei aus aufruft,
kl>> ist der Treiber aktiviert, cmd.exe aber immer noch am Ruder.
kl>> Vermutlich laesst sich ansi.com dann nicht entladen, aber unter
kl>> XP bin ich auf diese Funktionalitaet ja nicht wirklich angewiesen.
kl>> Auch aw.exe laesst sich laden, verzichten muss man nur darauf,
kl>> dass auch an der Kommandozeile Alt+W das Fenster bringt)
kl>
kl>Ausgangspunkt dieser Diskussion war ja die Suche nach
Inkompatibilitäten
kl>bei der Ausführung von DOS-Hilfsprogrammen. Und DOS- und Win16-
kl>Programme verhalten sich nun mal unterschiedlich, jenachdem, ob
kl>sie unter einer "reinen" DOS-Umgebung (command.com + DOSONLY
gesetzt) 
kl>gestartet werden oder nicht. Also lohnt es sich auch, in diesem
Bereich 
kl>zu suchen.
kl>
kl>Der Ausweg aus diesem Dilemma im Allegro-Umfeld kann nur der
Übergang
kl>zu 32-bit-Programmen auch für die Indexerstellung und den Import
kl>sein.


BS wird aus gutem(?) grund die kompilation ins 32bittige nicht
wagen.....

wir werden vermutlich noch lange mit einer 16-bit-index.exe leben
müssen...

es funktioniert ja auch ....! 
naja, wenn man sich mit 8.3 zufriedengibt, keine parallelen abläufe und
alles schön hintereinander.... esisthaltso!




kl>Herr Lehmanns Problem könnte mit den Restriktionen für den
kl>Aufruf des Kommandozeileninterpreters zusammenhängen, in diesem Fall
sind
kl>die Seiteneffekte noch umfangreicher. Ein Versuch, die aufrufende
kl>Umgebung zu ändern bzw. experimentell zu variieren, könnte also
Erfolg 
kl>bringen.

JA! nur hier kann ich ansetzen.
allerdings bezweifele ich, das DOSONLY der heilsbringer sein wird. 
die restriktionen sind von übergeordneter(rer) natur ;-(
mal schauen...



viele grüße
ihr klaus lehmann