G besoin de traficoter une appli 16bits écrite en C.
Si vous connaissez la prog 16bits (donc, s'il y a une chance que vous puissiez m'aider...) vous savez qu'un programme est en mémoire sous forme de segments.
Mon appli en est au point ou quand j'y ajoute du code, quel qu'il soit, ça me fait un débordement mémoire à l'execution. J'imagine que c parce que je dépasse les 64Ko du segment de code (peut être que je me plante !?).
 
Je suis pas du tout expert en prog 16bits ...qqn à surement déja connu ce problème,...please, help me ! ( = aidez moi, pour les non-anglophones, et anplophobes)

ça dépend, t'as plusieurs trucs pour le 16 bits, comme code+data = 64k, code=64k et data=64k, soit les modèles tiny, medium, etc ... que tu choisis à la compilation. je me souviens plus trop, c'est loin tt ça !
 
si t'es à cours de mem tu peux essayer d'allouer de l'ems (argh!) ou de l'xms (urgh!). vraiment pas moyen de le faire en 32b ton truc ?

IM-PO-SSIBLE de l'écrire en 32bits, l'appli est déja écrite, elle doit juste être modifiée...ça serai trop beau, ha, le 32bits, j'en rêve encore des fois !
 
sinon, ton histoire de tiny, medium, à mon avis, c ma solution !
Mais le pb c que l'utilise VC1.5 pour la prog 16bits (g pris une machine à remonter le temps pour aller dans les années 80 ), et dans le bouquin qui explique tout (ou qui est censé tout expliquer), je trouve pas comment faire ça...
 
G encore besoins d'aide...

je ne peux que te conseiller de chercher de la doc sous google là-dessus. et si ce n'est pas une histoire de modèle, de mater l'ems et l'xms (et l'umb ... houlala). enfin, la mémoire dispo sous dos en général.

...j'pense pas (ou plutot, j'éspère pas) que ça soit ems, ou je sais pas quel system de gestion de mémoire qu'il faille modifier.
 
 
Si qqn sais comment changer le mode de mémoire (tiny, medium,...) sous VC++ 1.5, je suis toujours preneur...

hé, me laissez pas tomber, g besoins de vos conseils...

J'écris toujours en 16 bits (sous Win ppalement), mais suis pas pro..
Quand il n'y a pas le nouveau code, ça marche ou y a déja le problème ?
Sous Borland, on définit le modèle mémoire lors de la création du projet. On peut en changer ensuite (dans les options du compilateur). Sous DOS, j'utilisais souvent le modèle LARGE...
 
Quand on crée un tableau, on peut aussi le faire de façon dynamique avec malloc() puis (free()) au lieu de faire float Machin[10000].
 
Suffira-ce ?

 
heuuu... pas vraiement en fait !
Parce que sous VC1.5, je trouve pas ou choisir le modèle de segmentation (style, LARGE, ou TINY,...)
et l'histoire des tableaux ne peux pas résoudre mon problème (ça fait déja une journée que je me prend la tête la dessus, g appris des truc). Je t'explique: en fait, les progs 16bits on un segment (ou des, ms malheureusement, un seul dans mon cas !) appelé CODE; dans ce segment son rangées les instructions compilées. et il y a des segments différents (DATA) pour les données. L'allocation dynamique affectera seulement les segements DATA, or mon pb vient du segment CODE...
 
Merci qd même...et si tu vois qqch, hésites pas (les autre non plus, hésitez pas; je vous trouve un peu trop hésitants )

J'avais acheté VC1.0 mais je m'en suis pas beaucoup servi (il y a longtemps). Je suis BC3.1/16bits et BC5.02/32 bits.
Faudra que je regarde.
 
Dans BC5, c'est QUAND on crée le projet qu'on choisit le modèle mémoire. Après, c'est trop tard. Si on change d'avis, faut recréer un nouveau projet adapté.
 
Je vais regarder ce soir mais suis de retour que lundi...
 
Dans l'aide/la doc, il y a rien ?
 
Mes programmes DOS étaient assez compacts pour ne pas avoir ce genre de problème. Créer des Overlays (je connais que le nom) ?

oula la, c effrayant tout ça !
J'crois qu'en fait, vu que g pas trop de choses à ajouter a mon prog, je vais essayer d'optimiser le code déja écrit et celui que je rajoute pour économiser qqs octets...au 3e millénaire, si c pas malheureux !  

et question à la con, pourquoi ne le recompile tu pas avec un compilo 32 bits ? genre la version de visual d'aujourd'hui , ou gcc ...

...ça aurai pu être une solution, mais l'appli que je modifie doit tourner sous Windows 3.1 , hé ouais, des clients complètement à la rue. Mais bon, le client est roi ! (enfoiré de client ! )

ton probleme me parrait bien curieux quand meme ...
comment ca se traduit ton debordement memoire ?
parce que : imaginons que ton exe fasse dans le 65 Ko (il fait quelle taille ?),  bien.
t'es dans la fonction, peinard, aus alentours du 64°Ko ... bien ...
ton code il jump vers le 65°Ko ... ben il jump vers le 1° alors, et donc bim bam boum il fait n'importe quoi "invalide opcode" ou un truc du genre.
et puis quand meme, ca serait bien bizarre si le compilo il savait pas gérer ca.
 
ca deborde quand ? des le debut ? ca se traduit comment ?
 
sinon y'a pas un truc genre FAR ou NEAR ?
tu penses pas que ca pourrait venir d'un espace de pile insuffisant ou un truc du genre ?

Bon, t'as l'aire calé niveau 16bits (moi, pas du tout !)
alors je vais te décrire les faits, sans aucun jugement de ma part, allez, hop, j'met mon esprit critique de côté.
 
Alors en fait, dans mon entreprise, je doit modifier une appli qui est écrite en 16bits, j'y rajoute donc qqs lignes de code en compilant et testant l'executable régulièrement. Et lors d'un de mes multiple test, paf, débordement mémoire ! g donc cherché de quelle instruction merdique ça venait, et g remarqué que ça vient pas d'une instruction...si j'enlève uneligne de code pas trop importante, ça fonctionne à nouveau...c donc mon segment de code qui déborde, non !?
 
Et ce débordement se fait dès le début en plus...vu que ¨le CODE est en PRELOAD, c le moment ou tout le code est foutu en mémoire...raison de plus pr penser ce que je pense, non ?
 
je pense donc pas que ça puisse venir de la pile !

Si c'est sous WINDOWS, y a pas à s'occuper du modèle mémoire que je sache (sauf erreur..). Faut avoir si c'est un EXE Windows ou une DLL.
Sous DOS, c'est difficile si trop gros (pour moi, pauvre amateur pas très averti).
 
Quand on a un "gros" programme (le mien arrive à 400k sous Win 3.1, 250k sous Win32), on fractionne le code en différents modules. Il faut alors gérer les variables globales, les fonctions contenues et déclarées dans un module, extern dans les autres.
Chaque module une fois compilé occupe un segment (code + data). Mon projet regroupe 10 modules, un module principal (la feuille de l'application), un pour le décodage des fichiers, un pour le graphisme, un pour la gestion des boutons de la barre d'outils, etc... Si on découpe, on peut arriver à regrouper des choses qui vont ensemble et pour lesquelles les variables n'ont pas besoin d'être partagées avec les voisins (comme pour les classes ????? je ne me suis pas encore mis au C++).
 
Dans le projet, on met PPAL.C, GRAPH.C, MOD1.C, MOD2.C, etc.., fichier .RC avec les ressources. Il faut déclarer les variables globales dans un .H, et les déclarer en extern dansles modules qui en ont besoin.  
Ou pour "simplifier", dans le même fichier .H déclarer les variables globales, et faire des sections #ifdef TRUC ... #endif et n'oubliant pas de déclarer #define TRUC dans le module C afin de savoir si les variables sont externes ou non (suis pas très clair j'ai l'impression   )

En fait a la lumiere de ton autre topic je pense que ca viens plutot des donnes, il faut absolument que tu trouves dans quel modele memoire tu est, ca doit se trouver dans les settings, ou dans les options de compil, au pire fais un cl /? pour avoir les options ....
tu nous a dit  
1 - que tu avais plusieurs segments de donnes
2 - ta fonction fopen attend un pointeur near
ca va pas ensemble...
 
Chez Borland Il y avait un modele huge avec lequel il n'y avait jamais de Problemes... si tu peux trouver un Borland...

oula la, c une bonne idée de découper en fichier...ms c trop compliqué ! à la base j'ais juste un petite modif à faire !
Je crois que j'vais me contenter d'optimiser le code  
Merci par tout ça...et...VIVE LE 32BITS !  
J'aime Window 98 !

 
Non non...en fait je dis qu'il y a plusieurs segments de donnée mais j'en sais rien du tout ! g rien fait pour en avoir plusieurs en tout cas...
Et fopen attend toujours un near, la fonction est faite comme ça, le pb est résolu, voila comment si ça interresse des gens.
en fait, g mon Far qui est la variable globale que je veux utiliser pour le fopen:
LPSTR szMonFar;
 
et g mon near qui est une variable locale:
char szMonNear[100]
 
bah je fait tout betement un fstrcpy (szMonNear, szMonFar)
c facile qd on connait la fonction qu'y  faut hein !?  
 
Et ça peut pas être un débordement du le segment de donnée, je persiste, et même que je signe !
pourquoi !? parce que je peut remplacer mes char UnTableau[50] par des char UnTableau[9999] sans que ça pose aucun pb !!!

je suis pas une bete en 16 bits c'est juste que je trouve ton cas bizarre
on sait pas ou est le probleme
ce ke je voudrais savoir, c'est si tu fout un getch() des le tout debut de ton main, est-ce ke ca plante ?
il fait quelle taille ton exe ?

mon exe est pas très gros, il fait 24Ko...
sinon, OUI, ça plante (enfin, g testé avec une messagebox...parce que, les getch()...sous window je sais pas trop !

El_gringo a écrit a écrit :     Non non...en fait je dis qu'il y a plusieurs segments de donnée mais j'en sais rien du tout ! g rien fait pour en avoir plusieurs en tout cas... Et fopen attend toujours un near, la fonction est faite comme ça, le pb est résolu, voila comment si ça interresse des gens. en fait, g mon Far qui est la variable globale que je veux utiliser pour le fopen: LPSTR szMonFar;   et g mon near qui est une variable locale: char szMonNear[100]   bah je fait tout betement un fstrcpy (szMonNear, szMonFar) c facile qd on connait la fonction qu'y  faut hein !?     Et ça peut pas être un débordement du le segment de donnée, je persiste, et même que je signe ! pourquoi !? parce que je peut remplacer mes char UnTableau[50] par des char UnTableau[9999] sans que ça pose aucun pb !!!

Pourquoi pas... mais ca confirmerait le segment de donnes...
perso la cause devait etre une convertion de far en near
mais pas un depassement d'indice dans un tableau...

ben c'est raiment louche ...
24 Ko de code qui debordent de 64 Ko ...
ca vient d'ailleurs a mon avis

J'ai une suggestion (peut-être idiote mais bon) :
 
Pourquoi t'installerais pas Win32s chez ton client ?
 
tu compile ton appli en 32 bits et basta, tout marche comme sur des roulettes.

et nivo données, t'as de gros tableaux ?

 
:-) bah voyons, je vais me pointer à la MSA et j'vais leur dire: " salut, c moi, je suis venu avec Windows98, ça vous dirait de l'installer dans vos 20 caisses pour faire marcher la nouvelle version de nôtre appli !? allez, soyez cool !"
non, sérieusement, faut pas rêver !

 
Mais d'ou !?...ça ...

Win32s c'est un module ( comme directx ) qui se rajoute à win3.1 . C'est apparu 1 an avant win95.  
Quelques logiciels utilisant beaucoup de mémoire l'utilisait. Ca s'intalle en même temps que l'application ( sauf s'il est déja sur la machine...)

El_gringo a écrit a écrit :     :-) bah voyons, je vais me pointer à la MSA et j'vais leur dire: " salut, c moi, je suis venu avec Windows98, ça vous dirait de l'installer dans vos 20 caisses pour faire marcher la nouvelle version de nôtre appli !? allez, soyez cool !" non, sérieusement, faut pas rêver !

 
J'ai parlé de win32s, pas de win98. Win32s est un utilitaire qui permet de faire tourner des applications 32bit sous win 3.1 . C'est pas énorme (quelques Mo) mais je sais pas si ça peu se trouver encore. Si tu peux, cherche sur le cd d'un magazine paru entre fin 95 et fin 96 on le trouvait souvent avec les progs qui ne fonctionnaient que sous 95 et pas sous dos.

ha, désolé, c pas si bête comme idée... mais convertir une appli 16bits en une 32bits ça risque de faire plein d'erreurs...surtout si il y a qqs far, ou near pointers...
bref, ça va allez !
Merci...(et Win32s c très facile à trouver, tu tapes ça en recherche dans google et y t'en trouve 39 000 occurences !
y en a même une nouvelle version !)

near ou far sont equivalents en 32 bits, par contre il peut y avoir des problèmes de compilation, certaines fonctions windows demandent des entiers 16 bits ou 32 bits suivant la compilation 16 ou 32 bits.

El_gringo a écrit a écrit :     Non non...en fait je dis qu'il y a plusieurs segments de donnée mais j'en sais rien du tout ! g rien fait pour en avoir plusieurs en tout cas... Et fopen attend toujours un near, la fonction est faite comme ça, le pb est résolu, voila comment si ça interresse des gens. en fait, g mon Far qui est la variable globale que je veux utiliser pour le fopen: LPSTR szMonFar;   et g mon near qui est une variable locale: char szMonNear[100]   bah je fait tout betement un fstrcpy (szMonNear, szMonFar) c facile qd on connait la fonction qu'y  faut hein !?     Et ça peut pas être un débordement du le segment de donnée, je persiste, et même que je signe ! pourquoi !? parce que je peut remplacer mes char UnTableau[50] par des char UnTableau[9999] sans que ça pose aucun pb !!!

Si mes souvenirs sont bons, il faut locker les objets en memoire avant d'utiliser lstrcpy (lstrcpy et pas autre chose).
 
Typiquement pour un objet local, on faisait:
 
Handle hMem;
PSTR pstr;
hMem=LocalAlloc(LMEM_MOVABLE, 15);
pstr=LocalLock(hMem);
lstrcpy(pstr, "Hello World" );
LocalUnlock(hMem);
 
et pour un objet far:
 
Handle hMem;
LPSTR lpstr;
hMem=GlobalAlloc(GMEM_MOVABLE, 15L);
lpstr=GlobalLock(hMem);
lstrcpy(lpstr, "Hello World" );
GlobalUnlock(hMem);
 
En hopant que ca helpe.
A+,

[edtdd]--Message édité par gilou--[/edtdd]

Tiens, avec le crash du forum, on a paume ta reponse (je l'avais lue). Un fstrcpy devrait etre ok.
Au fait, sous quel modele de memoire compiles tu? A priori, compact ou large devraient etre OK (pointeurs far standard) si ce que tu fais n'est pas une DLL. Tu peux voir ca avec la commande de link: si tu linkes (link4 ?) avec llibw.lib==> large, clibw.lib==>compact (et slibw.lib=>small, mlibw.lib==>medium).
Si il y a un .def associe a ton programmes, as tu une taille suffisante dans le parametre STACKSIZE pour que ta table soit allouee sans probleme?
A+,