Ma forse sono file in formato html?

Guardando dentro le varie distribuzioni si trovano file.txt con codici non asci che probabilmente indicano dadi d'input dell'utente; qualcuno sa spiegami come viene usato gedit in tali occasioni?
Grazie giorgio

File.txt? Distribuzioni?

A cosa ti riferisci?

Se entriamo nel discorso client-server, allora la cosa si fà un bel pò più complessa, tenendoconto che gambas non ha tutte le caratteristiche e le funzionalità per poter gestire in modo semplice questa logica.
Tanto per fare un esempio, non gestisce i thread...

Detto questo, se necessario, la logica da implementare diventa un pò diversa dal classico modo di approciare il discorso, avendo a disposizione linguaggi più evoluti.
Anche se non dovrei, possiamo considerare gambas più alla stregua di visual-basic, e non possiamo compararlo con un java (per esempio).
Di solito questi linguaggi (vb e gambas) sono indicati più per applicazioni stand-alone, o in modalità client-server ma solo se il "server" fornisce il database, o la logica business. In questo caso il linguaggio serve mediamente per creare la parte interfaccia utente (es. un web server).

Ora, questa è una parte del discorso, poi ne viene un'altra.

In che ambiente andiamo ad operare? Quando si parla di client-server, il discorso è alquanto generalizzato, ma mettiamo il caso di voler creare un applicazione web. In questo caso possiamo anche prendere in considerazione gambas, per quanto riguarda la parte server (per il client ovviamente abbiamo il solo browser...). Costruire un'application server è relativamente semplice, e lo si può anche vedere negli esempi a corredo.

La gestione della memoria... Per questo discorso prendiamo in considerazione un linguaggio come il PHP. Anche questo linguaggio è interpretato, anzi è completamente interpretato, perchè gambas esegue invece una mezza compilazione, preparando appositamente un para-eseguibile che l'interprete può eseguire un pò più velocemente. Quindi, ritornando al php, il discorso memoria diventa uguale a quello di gambas. mediamente in un programma web, il motore del server non fà altro che elaborare le richieste provenienti dalla rete, e creare più o meno dinamicamente delle pagine html. La dimensione di queste pagine, dato che sono testo puro, possono influire sull'utilizzo della memoria, ma questo dipende esclusivamente da come uno ha sviluppato la funzionalità di creazione. Se non per puro sudio, non possiamo andare ad analizzare cosa fà php e come lo fà riferito alla memoria, a meno che questo non influisca sulle performance. In ogni caso il problema è mediamente un errore di programmazione, in quanto php fornisce funzioni di base, che tra l'altro sono state scritte in C. Sempre per studio possiamo andare ad analizzare cosa fanno queste routine a basso livello, ma siamo sempre sul discorso teorico, in quanto queste routine sono state testate e ottimizzate nel tempo, e quindi poco correggibili (bug a parte).
In gambas siamo allo stesso livello. Gambas è costruito su un substrato scritto in C, e in gran parte si appoggia a librerie esterne che, mediamente, sono già ottimizzate di loro. In questo caso mi pare superfluo andare a capire cosa gambas fà e come lo fà nei confronti della memoria, perchè in gran parte non dipende da questo linguaggio.

Ritornando alla logica web client-server, l'ottimizzazione si fà eseguendo uno studio approfondito di cosa deve fare un'applicativo, e dalle risorse a disposizione. E' ovvio che non possiamo pensare di costruire un applicazione per 1 milione di utenze contemporanee con un pc portatile... Le risorse di solito si implementano in base alle esigenze applicative e, se non è possibile, allora si cerca di gestire l'applicativo in modo da farlo girare con quelle a disposizione.

Per rispondere alla tua ultima domanda, penso che nessuno o pochissimi hanno avuto a che fare con la costruzione di applicazioni client-server, o
perlomeno che abbiano avuto a che fare un applicazioni seriamente client-server, se non per sudio o per piccoli ambienti di lavoro.

Per il discorso se gambas può essere utilizzato per la costruzione di questo tipo di ambienti, direi che ci può stare, ma sarei più dell'opinione di cercare linguaggi più indicati a questo tipo di approccio, in quanto grandemente sviluppati e testati proprio e quasi esclusivamente queste applicazioni.

Ora ritorniamo al semplice discorso sullo spacchettamento di un programma gambas. Come credo di avere accennato in precedenza, la cosa credo sia alquanto inutile, in quanto l'interprete gestisce da solo le operazioni di caricamento e scaricamento oggetti e moduli, similarmente a quanto fà java. Un'applicazione è un'applicazione, che deve fare un determinato compito. Diversamente è invece il discorso alla riutilizzazione del codice, ovvero alla creazione di librerie che possono essere utilizzate anche in altri programmi (come poi sono gli oggetti grafici che vedi nell'ide di gambas, e che ti copy nelle tue form). In questo caso la cosa è altamente auspicabile, in quanto ti rende più semplice lo sviluppo, e ti evita di affrontare sempre le stesse cose trite e ritrite. Le librerie possono essere i sorgenti stessi di funzioni e classi create ad-hoc, oppure proprio librerie create con gambas (puoi leggere molto anche qui nel forum a riguardo). Inoltre, puoi agganciarti anche a librerie esterne, da cui attingere a attue o ad alcune delle loro funzioni (anche qui di studi ed esempi ne trovi a iosa).

Per riassumere, la tua ricerca la vedo inutile o quasi se indirizzata all'operatività vera e propria, ma la potrei vedere interessante a livello di studio. In ogni caso ogni approfondimento deve essere fatto a livello subatomico, nel senso che dovresti andarti a leggere i sorgenti di gambas, per capire il suo funzionamento (cosa che può essere alquanto interessante, e che dà spunti e suggerimenti interessanti).

Una cosa da precisare, ovvero gambas fà parte dei linguaggi ad alto livello "interpretati", per cui l'occupazione di memoria è relativa non al programma in sè, ma all'interprete.
Fai conto come se il programma sia un file di testo, occupa spazio su disco è vero, ma quello che poi occupa la memoria di sistema è l'editor che usi per leggere il contenuto del file.
Seguendo questo stesso esempio, se l'editor è fatto bene e predisposto alla lettura di file di grosse dimensioni, gestirà la memoria in modo da non caricare tutto il file, ma solo la porzione interessata. Se mettiamo il caso che il file di testo sia di 30/40Gbyte, sarebbe impossibile caricarlo tutto in memoria, a meno che tu non abbia un sistema megagalattico... 
Per i programmi binari, il discorso è infatti molto diverso, in quanto sono direttamente tradotti in linguaggio macchina, per cui non hanno la necessità di essere interpretati da programmi esterni. In questo caso una buona gestione della memoria è essenziale.
Anticamente si usava la tecnica degli overlay, ovvero pezzi di programma contenuti in appositivi file separati, caricati solo quando vengono richiamati, e rilasciati quando finisce la loro utilità. In alcuni casi gli overlay erano direttamente dentro lo stesso eseguibile, e il compilatore stesso si occupava, dietro apposite istruzioni, di caricare moduli presi all'interno del file. In questo caso il file veniva caricato in memoria solo in parte...
Dopo si è passati alle librerie esterne, vedi ad esempio le *so* in unix, oppure le dll in windoz.
Alla necessità di avere programmi meno voluminosi in partenza, si è però aggiunto lo scopo di renderli anche riciclabili, e quindi utilizzabili per altre funzioni.
Una chiave può essere utilizzata per prire un lucchetto, una porta, oppure avviare un motore... A questo punto si è reso opportuno creare appositi moduli specializzati, da utilizzare nelle diverse situazioni e soluzioni.

Per finire, quindi, lo scopo di ottimizzare la memoria deve partire, o da un semplice studio allo scopo di capire il funzionamento del linguaggio, oppure credo sia inutile in questa logica. L'unica cosa che credo sia il caso di intraprendere, è lo studio dell'utilizzo delle variabili e delle classi usate nei programmi, nel senso di ottimizzare l'uso che se ne fà, come lo si fà e perchè lo si fà, capire se è possibile velocizzare certe operazioni, segundo logiche e algoritmi diversi, e via dicendo. Insomma, quello che si fà in ambiente di programmazione al giorno d'oggi, in particolare se si tratta di creare applicazioni ad alto livello, con requisiti non eccessivamente stringenti (per stringenti intendo applicazioni ad esempio in real-time).

Ma, gli hai detto che sono a pagamento?  ... 

...sogni, sogni... è solo un'immagine, che compare a tempo... 

Bè, le risposte non vengono da sole, e nessuno nasce "imparato"... 

Scherzi a parte, la gestione di file (immagini, fogli office, o altro) dipende dal tipo di database. Alcuni hanno la possibilità di gestirli, altri no, come per esempio sqlite.
Nel qual caso, la soluzione di memorizzare il solo nome del file nel db, e di depositare il file vero in un'apposita cartella è la soluzione ottimale, ed è utilizzata in parecchi ambienti.