 |
||
| ||
| |||||
| Dernière réponse | |
|---|---|
| Sujet : Prog C sous 16bits --> Help me... (quelle merde !) | |
| gilou | 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+, |
| Aperçu |
|---|
| Vue Rapide de la discussion |
|---|
| gilou | 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+, |
| gilou |
[edtdd]--Message édité par gilou--[/edtdd] |
| seblamb | 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 | 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 !:D y en a même une nouvelle version !) |
| mareek |
|
| seblamb | 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 |
|
| El_gringo |
|
| HelloWorld | et nivo données, t'as de gros tableaux ? |
| mareek | 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. |
| HelloWorld | ben c'est raiment louche ...
24 Ko de code qui debordent de 64 Ko ... ca vient d'ailleurs a mon avis |
| BENB |
|
| El_gringo | 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 ! |
| HelloWorld | 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 ? |
| El_gringo |
|
| El_gringo | 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 ! |
| BENB |
|
| Carbon_14 | 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 :( ) |
| El_gringo | 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 ! |
| HelloWorld | 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 ? |
| El_gringo | ...ç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 ! :o ) |
| youdontcare | 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 ... |
| El_gringo | 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 ! :gun: :cry: |
| Carbon_14 | 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) ? |
| El_gringo |
|
| Carbon_14 | 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 ? |
| El_gringo | hé, me laissez pas tomber, g besoins de vos conseils... |
| El_gringo | ...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... |
| youdontcare | 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. |
| El_gringo | 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 :D), et dans le bouquin qui explique tout (ou qui est censé tout expliquer), je trouve pas comment faire ça... G encore besoins d'aide... :sweat: |
| youdontcare | ç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 ? |
| El_gringo | 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) |
