Newsgroup: it.comp.lang.vo-clipper
Titolo: PROTECTED MODE

Sto usando da sempre Clipper 5.2e con Blinker 5.1  in modalità real, adesso
per problemi di performance e di memory low con un programma volevo usare il
linker in modalità protetta, ho però alcuni dubbi:
- in modalità protetta vengono eliminati gli overlay ?
- il programma viene caricato tutto in memoria ( ?? estesa ?? espansa )  e
si evitano i problemi di memory low della RAM convenzionale ?
- per linkare in modalità protetta è sufficiente usare
BLINKER EXECUTABLE EXTENDED
oltre alle librerie protette di Blinker e CTP.LIB ( clipper tools )
- con Windows 9X ci pensa lui a fornire il tipo di  memoria necessaria ?
grazie a tutti

 - con Windows 9X ci pensa lui a fornire il tipo di  memoria necessaria ?
Credo, dico credo, che ci pensi l'accoppiata HIMEM.SYS/EMM386.EXE.
EMG
PS. Io per i programmi DOS non ho mai utilizzato la modalità protetta e
mi hanno girato sempre anche in condizioni di memoria convenzionale
critica (tipo, ultimamente, un PC con soli 512 Kb di memoria
installata).

 - con Windows 9X ci pensa lui a fornire il tipo di  memoria necessaria ?
La modalita' protetta e' tutta un altra cosa. Non servono overlay, la gestione
delle mamoria e' automatica, ti interfacci con Windows in automatico .. etc
Devi pero' usare librerie che prevedono la modalita' protetta, pertanto CTP e
non CT .. etc
Per il link basta un
BLI EXE EXT
SEA blxclp52
e a seguire tutto il resto. Il programma risultante e' sicuramente piu' veloce
di quello attuale con i vecchi e lenti overlay

 di quello attuale con i vecchi e lenti overlay
Non ho ancora capito se parlando di overlay intendete quelli virtuali o
quelli fisici. Mah, forse tutto sommato non c'è molta differenza.
Comunque il discorso è che sui computer attuali (e anche meno attuali)
la differenza tra modalità reale e protetta non credo risulti
importante, anche perché il collo di bottiglia dei programmi gestionali
sono i database e quindi il disco.
EMG

 sono i database e quindi il disco.
Vero .. ma non totalmente.
Un programma in modalita' reale, ha SEMPRE problemi di memoria, soprattutto
con i computer attuali, Windows based, dato che nel 99% dei casi la ram di
un task dos e' minore di quella di una normale macchina dos. Infatti il
default di windows non e' fatto per sfruttare il task dos, ma le
applicazioni windows.
Un programma in modalita' reale soffre MOLTO della poca memoria di un task
dos e se supra una certa soglia: 1MB circa, risulta estremamente lento.
Passando in modalita' reale la cosa scompare. Arrivi anche a oltre 5 MB
senza problemi

 senza problemi
Sarà anche vero ma a me non è mai capitato. Che ti devo dire?
EMG

> Sarà anche vero ma a me non è mai capitato. Che ti devo dire?
La cosa e' certa, ma il programma deve superare una certa soglia per notare la
differenza. EX 1 MB(con memoria XMS) , ma anche 1.3 MB(con memoria EMS) di exe e'
una buona soglia.
Su programmi piccoli .. quelli in modalita' reale sono piu' veloci.
Se superi i 2 MB e' impossibile usare la modalita' reale e per avere exe veloci
DEVI usare la modalita' protetta


Scusa se insisto ma secondo me c'è un errore di fondo (o qualcosa che
non ho capito io): la dimensione dell'eseguibile non ha niente a che
vedere con la sua occupazione di memoria che è invece quella che scrive
(ad esempio) il Blinker alla fine del suo lavoro. Questo linker, in
particolare, è in grado di scendere (se non vado errato) a livello di
singola funzione, per quanto riguarda la gestione degli overlay virtuali
e quindi non può aver alcun problema di memoria. L'unica cosa che
potrebbe far si che l'eseguibile non venga caricato è una grossa (molto
grossa) funzione o un grosso modulo statico nel root-module. E
normalmente questo non succede. Quindi basta mettere BEGINAREA e ENDAREA
nel file LNK e i problemi non dovrebbero proprio esistere.
Sbaglio?
EMG

 Sbaglio?
Si, BEGINAREA e ENDAREA non servono a niente quando fai un link in modalita'
protetta (EXTENDED), servono solo quando generi un .EXE in modalita' reale
(REAL).
--
Ciao
Dio Brando

 (REAL).
Forse ancora non mi sono spiegato: intendevo dire che in modalità reale
non ci sono problemi di memoria se uno mette BEGINAREA e ENDAREA e se la
dimensione del root-module non è eccessiva.
EMG

 Sbaglio?
Non e' corretto.
Quando blinker esegue un modulo deve caricarlo da disco o da XMS/EMS,
memoria che usa come cache, nella memoria reale. Che in real mode e' limitata
ai primi 640k + UMB.
Inoltre c'e' la parde DATA delle funzioni C che finisce nel 640 + le routine di
cui non si puo' fare l'overlay + la memoria usata dalle funzioni C per allocare
il record corrente dei file aperti + la memoria usata dalle variabile static (14 byte
l'una)
piu' la memoria delle variabili, dello stack etc etc etc
insomma ci sono delle informazioni che COMUNQUE debbono stare nei 640, anche se
crei degli overlay.
Per tale ragione, all'umentare della dimensione dell'exe, involontariamente, diminuisci
la memoria che alla fine la tua aplicazione ha disponibile. Fai pure delle prove, e
vedrai che,
all'aumentare dell'exe, diminuisce il memory (0), anche con l'overlay piu' grosso che
riesci a
fare, e conseguentemente diminuiscono le performance.

Sono beral , l'iniziatore di questo thread molto interessante visto il
dibattito che ne è nato, nonostante tutto mi sono rimasti alcuni dubbi:
Ho compilato il mio programma ( un gestionale in fase di sviluppo ) con
Clipper 5.2e con Blinker 5.1 in modalità protetta + le librerie x accedere
al server ADS ( x chi vuol avere notizie 
http://www.advantagedatabase.com
 )
+ le CA-TOOLS in modalità protetta ,
tutto funziona correttamente, e molto più velocemente che in modalità reale
con gli overlay .
Funziona anche sotto Win95 con 485k di RAM - task DOS o su vecchi 486 con
4Mram, mentre  prima si bloccava quasi subito con il solito errore di Memory
Low.
Alla fine di tutto non ho capito che cosa devo garantire come minimo per
farlo eseguire il programma dal cliente cioè :
Premessa) Parliamo solo del programma compilato e distribuito al cliente.
1) devo solo assicurarmi che sia caricato HIMEM.SYS nel CONFIG.SYS e poi si
arrangia il programma a prendersi la XMS o EMS che gli serve ?
2) Chi decide il tipo di memoria che gli serve ? ed eventualmente cosa fare
?
3) se non avesse abbastanza memoria si blocca subito , si può bloccare
durante l'esecuzione o comincia a swappare su disco ?
4) riveste ancora importanza il parametro della variabile CLIPPER =
file://E:0 ? oppure non va usato addirittura perchè controproducente ?
5) ogni altra indicazione è bene accetta ( link documenti ecc )
6) ho trovato questo articolo 
http://www.dclip.com/memory.htm
un saluto a tutti i partecipanti della mail

 riesci a fare, e conseguentemente diminuiscono le performance.
Hai ragione. Ho provato ad accumulare PRG finché non ho ottenuto il
messaggio di conventional memory exhausted e a quel punto in modalità
reale non c'è stato niente da fare. Evidentemente non avevo mai scritto
programmi così grossi (anche se forse una prova fittizia come questa
tende ad esasperare i risultati a causa dell'enorme quantità di funzioni
piccolissime che ho creato per realizzarla). Dopotutto sono diversi anni
che non scrivo più programmi per MS-DOS e quindi forse avevo dimenticato
un po' i termini del problema.
EMG