[Allegro] Indexproblem (erkannt?)

[Klaus Lehmann]

verehrte mitlesende,
verehrter herr eversberg,


langsam wird die situation um die index.exe katastrophal.
ja, sie ist es auch!!!!

ich denke auch, die NICHT jeder, der die moderne index.exe verwendet,
hat das problem. s.a. meine ausführungen dazu.





meine erkenntnisse:
===================

auf dem laptop (wxp-ibm)
sagt mem, im cmd.fenster:
655360 konv. speicher
587648 max größe für programm
~~~~~~~

auf einem stationären pc (wxp)
sieht es so aus:
655360 konv. speicher
623728 max größe für programm
~~~~~~


[nebenbei bemerkt:
=================
es gibt zwei commando-zeilenfenster:
cmd.exe und command.com
also, aufpassen, WO man das mem.exe ausführt. in einem
dos-(command.com)-fenster ist der freie platz etwas kleiner, als in
einem aufgerufenen cmd-fenster....]


1. PC
mit allen alten und neuen index-versionen (auch die vom 4.7.2007)
habe ich auf dem stationären pc keine probleme. der index-vorgang läuft
zweistufig sauber ab.
623kb für die index.exe reichen demnach aus.



2. laptop
auf dem ibm-laptop, welches nur 587kb zur verfügung hat, läuft seit ca
1-2 monat3n keine moderne index.exe mehr ab.
die fehlermeldung sieht in etwas so aus, wie h. fischer sie beschreibt:
"nicht genug konventioneller arb.speicher zur verfügung" usw usw.

wenn der laptop wie beim stationären wxp-pc seine üblichen 623kb zur
verfügung hätte, würde der index.exe auch funktionieren, da bin ich
sicher.

wenn ich alte index.exe und (hat es was mit qrix zu tun?) qrix.exe
verwende, dann habe ich keine probleme (auf dem laptop!): index.exe
204480   05.10.11   11:24 (qrix analog) 




diverse ergo's:
===============

ergo: das problem ist hausgemacht!
mein laptop ist dran schuld, das ein modernes index.exe NICHT läuft.

ergo2: jeder pc, der nicht die vollen 623kb zur verfügung hat, da wird
das moderne index.exe NICHT laufen.

-> h. fischer. schauen sie doch mal bitte, mit einem cmd.-fenster, was
sagt: mem.exe?
   ahne ich, daß die keine 623kb frei haben???? socnern erheblich
weniger?


nun, wer seine installationen inschuss hält, wird die config.nt kennen,
und wissen, was da alles nötig ist, und was nicht. auch wenn er hier
einige stellschrauben dreht, wird er es nicht hinbekommen. ich komme
z.b. NICHT über die (s.o.) 587kb hinüber. keine change. DAS ist (m)ein
hardware-problem. das remmen des ansi-treiber bringt keine entlastung! 

die entlastung, die benötigt wird (IN dem hardware-fall wie bei mir),
wäre eine reduzierung des ram-bedarfs bei index.exe um vermutlich
40kb!!!

info: es spielt KEINE rolle, ob die werte in der cfg, api weiter
runtergeschraubt werden, oder einträge in massen IN der api gelöxcht
werden, die neue index.exe benötigt dieses großes dos-fenster.
die index.exe von 2005 verkraftet umfangreiche api's und oder cfg's.





anderer lösungsansatz:
======================
h. eversberg hat in einer email an h. berger einiges angedeutet:
z.b. am 2.7.07
Der ANSI-Treiber selbst oder sein Fehlen ist nicht ursächlich.
Die Problematik erwies sich als äuà erst hartnäckig, aber wir haben
jetzt abermals ein  index.lzh  aufgelegt, das nun hoffentlich
endgültig für problemloses Funktionieren sorgt.

Normalanwender sind nicht betroffen, sondern nur solche, die mit
äuà erst kleinen Datenbanken experimentieren und dabei aber einen
äuà erst groà en DOS-Arbeitsspeicher haben, 620K oder mehr. Der ANSI-
Treiber sorgt für eine Verkleinerung dieses Arbeitsspeichers...

z.b. am 4.7.2007
Wir verdanken es wieder einmal T. Bergers beharrlichem und findigem
Testen, die Wurzel des Übels in INDEX.EXE nun endlich freilegen
und umgehend extrahieren zu können. Es lag ein besonders tückisches
Exempel der für C typischen Problematik des Jonglierens mit
Adressenbereichen vor, die sich im stickigen Gedränge des
DOS-Speichers nicht ganz umgehen läßt.


daraus erkenne ich, allerdings bin ich kein c-programmierer....
das alloziieren des von dos zu benötigenden (echten!)
dos-speicher-fenster wurde in letzter zeit vergrößert. hat index.exe
sich in fergangenheit (meine annahme:) mit 560kb begnügt, so benötigt
es heute (seit 1-2 moanten) eben mehr, nämlich (angenommen:) 600 oder
610kb.

hierbei spielt KEINE rolle, wie die werte in der cfg und oder in der
api umfangreiche aufgaben anstehen.
liege ich richtig mit dieser annahme?

da wird also mit adressbereichen jongliert. gefensterlt usw. wie sieht
es mit der ausnützung von xms-speicher aus? davon hätte wir doch alle
massig zur verfügung????



abhilfe:
========
darum (leider) meine vorschlag: bitte den dos-speicher-bedarf von
index.exe verrringen.
wenn dieses erfolgreich geschieht, wird keiner der kollegen, die hier
einiges dazu beigetragen haben, ein problem mehr haben. nämlich:
KEINES!

mittelfrsitige abhilfe:
=======================
noch besser wäre natülich: der umstieg auf die 32-bit-index.exe.....










nochmal: mein problem:
======================
nur mit einem alten index.exe von 2005 kann ich auf dem laptop
erfolgreich datenbanken indexieren. ursache ist der (zu) große
dos-arbeitspeicher-verbrauch vom neuen index.exe dieses problem wird
garantiert kein exclusives meiniges problem sein!






viele grüße
ihr klaus lehmann



ps: herr eger schrieb mal (sinngemäß), ausführliche fehlerberichte
-hier in der allegro-liste- kosten viel zeit. stimmt völlig! ;-)











-- 
Klaus Lehmann
eMail: lehmann_klaus at t-online.de
phone/fax: 03528-452 807/809; mobil 0171-953 7843
adress:  01454 Radeberg; Kleinwolmsdorfer Str. 37
Mitglied: Gewerbeverein und IHK Dresden seit 2005

       Die langjährige allegro-Werkstatt:    
               http://allegronet.de              
           NEU http://allegronetCMS.de
   Internetkataloge & WebHosting für AllegroC
Fremddaten: Import/Export; Netware/Windows/Linux

Präsentationen auf den jährlichen bibliothekar.
Fachkongressen (2006 Dresden und 2007 Leipzig)

***    "Our best ideas are born at home"      ***
***(Dave Lester: New Freedom Data Center,1995)***