1

yop,


Vous avez bien lu, j'ai installé Microsoft Visual C++ 2010 Express pour essayer de coder sous Windows. Je veux également utiliser la SDL.
Pour la SDL, j'ai donc mis :
- *.lib dans C:\SDL\lib
- *.h dans C:\SDL\include
- *.dll dans C:\Windows\system32

En clair, j'ai décompilé cetta archive : http://www.libsdl.org/release/SDL-devel-1.2.14-VC8.zip à cette page : http://www.libsdl.org/download-1.2.php dans C:\, je l'ai juste renommée SDL, et j'ai mis les .dll dans \system32.

J'essaye de compiler un projet qui contient juste un main.cpp, lequel se résume à int main (int argc, const char** argv) { return 0;}
Et ça marche ! \o/

Par contre, dès que je rajoute en tête #include <SDL.h>, ça merde. Je précise tout de suite que mes chemins d'include/lib sont correctement définis dans la feuille de propriété de la solution, vu que c'est comme ça qu'il faut s'y prendre avec cet IDE (on ne définit plus des chemins globaux à tous les projets à la fois).
Donc je n'ai pas d'erreur de header non trouvé.

L'erreur, la voilà :
1>------ Début de la génération : Projet : ZeUltimateGame, Configuration : Debug Win32 ------
1>LINK : fatal error LNK1561: le point d'entrée doit être défini
========== Génération : 0 a réussi, 1 a échoué, 0 mis à jour, 0 a été ignoré ==========

Je pars donc googler avec mon erreur LNK1561, et là je trouve des paquets de solutions. J'essaye donc :
- de rajouter /c aux options du compilateur (http://www.kbalertz.com/228455/Missing.Compiler.Option.Causes.LNK1561.Linker.Error.aspx) : FAIL
- de préciser dans le propriétés -> Editeur de liens -> Système -> Sous-système : Console ou Windows (http://www.siteduzero.com/forum-83-65818-p1-installation-sdl.html) : FAIL
(Erreur : error LNK2019: symbole externe non résolu _main référencé dans la fonction ___tmainCRTStartup dans un cas, erreur : 1>MSVCRTD.lib(crtexew.obj) : error LNK2019: symbole externe non résolu _WinMain@16 référencé dans la fonction ___tmainCRTStartup dans l'autre cas.
- ...

La grande majorité des tutos sur le net font référence à la version 2005 de MSVC++. Peut-être devrais-je recompiler la SDL avec ma version de l'IDE, au moins pour la partie statique ? En tout cas, pour ceux qui développe avec, ça a bien l'air l'enfer ces questions-là, chacun y va de sa solution, mais ça ne marche que pour sa tronche...

Même si je me doute bien que personne ne va me dire "fais ci fais ça, tu verras c'est magique", j'aimerais une direction vers où chercher. Plus je rentre les erreurs de build que j'obtiens dans google, plus je m'enfonce dans un labyrinthe où je ne comprends rien :/


Sans troller, mais sous linux, ya rien à faire pour que tout compile sans problème une fois qu'on a cliqué sur SDL-devel dans son gestionnaire de paquet favori grin

2

pourquoi tu développes pas avec mingw et codeblocks, comme tout le monde? #modfus#
je l'ai fait vendredi dernier, SDL marche très bien comme ça, c::b a même un exemple cheeky

sinon, t'as bien installé Miscrosoft Visual C++ 2010 Express ?

Miscrosoft?

Misc rosoft?

grin

3

Défini bien tes chemins de DLL, LIB et H dans Visual. Surtout l'ordre est important, puisque dès qu'il trouve un fichier il le prend, même si y'a plus récent dans les chemins moins prioritaires.

Kochise
avatar
Si Dieu m'a de nouveau fait homme, cette fois il m'a pas raté : marcher sur l'eau et dupliquer les pains, ça marche p'us :/

4

Voici mes chemins : tromb Fichier joint : 1Rti (prop.PNG)

J'en ai pas trop, je ne sais pas ce que je pourrais avoir de faux sad

Et pourquoi dis-tu qu'il faut définir un chemin pour les DLL ? Mes dll sont dans system32, il y en a besoin pour compiler ??


squalyl -> j'ai essayé il y a un bye avec CB, pareil, je tombais dans une suite d'erreur, chaque correctif trouvé sur le net en amenant une autre :/

5

Nan mais moi j'ai un répertoire de DLL de dev défini dans les chemins systèmes, donc quand un soft va installer dans sys32 un version plus ancienne que mes versions de dev, ça fait sauter pas mal de choses...

Kochise
avatar
Si Dieu m'a de nouveau fait homme, cette fois il m'a pas raté : marcher sur l'eau et dupliquer les pains, ça marche p'us :/

6

Bon, je vois des tas de solutions miracles mais qui ne marchent pas sur le net, et certains parlent même de "build unicode" ou non, ça pourrait influer, qu'est-ce que c'est que ce merdier encore ?!?

7

Ah, ça... Heu, commence pas éteindre ton PC et sort prendre l'air quelques heures :/

Kochise
avatar
Si Dieu m'a de nouveau fait homme, cette fois il m'a pas raté : marcher sur l'eau et dupliquer les pains, ça marche p'us :/

8

Au pif, je dirais, que ça vient de ça (sdl_main.h) :
#ifndef _SDL_main_h #define _SDL_main_h #include "SDL_stdinc.h" /** @file SDL_main.h * Redefine main() on Win32 and MacOS so that it is called by winmain.c */ #if defined(__WIN32__) || \ (defined(__MWERKS__) && !defined(__BEOS__)) || \ defined(__MACOS__) || defined(__MACOSX__) || \ defined(__SYMBIAN32__) || defined(QWS) #ifdef __cplusplus #define C_LINKAGE "C" #else #define C_LINKAGE #endif /* __cplusplus */ /** The application's main() function must be called with C linkage, * and should be declared like this: * @code * #ifdef __cplusplus * extern "C" * #endif * int main(int argc, char *argv[]) * { * } * @endcode */ #define main SDL_main /** The prototype for the application's main() function */ extern C_LINKAGE int SDL_main(int argc, char *argv[]);

J'ai déjà eu des problèmes similaires (point d'entrée non trouvé) de temps à autres, mais dans ton cas ça a l'air plutôt simple : Si ça fonctionne avant que tu inclues le SDL.h, alors c'est le SDL.h qui casse tout… (Suffit de regarder dedans ensuite, ce que j'ai fait ^^)

Donc SDL redéfinit ta fonction main (la renomme SDL_main), pour mettre la sienne à la place (un peu comme ce que fait déjà le runtime C de Visual Studio ou d'autres compilateurs), ce qui signifie qu'une partie au moins est sensé être utilisé comme librairie d'archive au lieu d'une librairie dynamique (*.dll).
En parcourant l'archive que tu as mentionné, je vois effectivement le SDLmain.lib dans le dossier lib, donc c'est certainement ça.

Donc, il faut que tu ajoutes SDLmain.lib (tout comme SDL.lib) dans la liste des fichiers d'entrée du linker… ^^
Le SDLmain.lib contient la fonction WinMain, donc n'oublie pas de redéfinir le type de projet en application Windows (Application GUI, Point d'entrée = WinMain(…))
Normalement, ça devrait suffir.

Après, comme c'est apparemment un build pour VC8, il peut être judicieux de le recompiler en VC10 si tu sais comment faire… smile
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

9

Merci beaucoup pour tes conseils. Effectivement, j'étais allé voir dans le header de la SDL pour voir ce qui s'y passait, mais je n'ai pas su pousser les déductions aussi loin.

J'ai donc suivi ce que tu as dit :
- j'ai rajouté SDLmain.lib et SDL.lib dans les entrées du linker (l'ordre n'a apparemment pas d'importance ?)
- j'ai dit au linker qu'on fabriquait une application Windows (/SUBSYSTEM:WINDOWS)

Et là, deux erreurs :
1>MSVCRTD.lib(cinitexe.obj) : warning LNK4098: conflit entre la bibliothèque par défaut 'msvcrt.lib' et les autres bibliothèques ; utilisez /NODEFAULTLIB:library
1>SDLmain.lib(SDL_win32_main.obj) : error LNK2019: symbole externe non résolu _SDL_main référencé dans la fonction _main

Je prends les erreurs dans l'ordre, d'abord le conflit : comme l'option conseillée est un peu trop bourrine, j'ai ajouté la bibliothèque en cause (msvcrt.lib) aux bibliothèques par défaut spécifiquement ignorées.

Je recompile, le conflit a bien disparu, mais subsiste l'autre erreur :
1>SDLmain.lib(SDL_win32_main.obj) : error LNK2019: symbole externe non résolu _SDL_main référencé dans la fonction _main
Et là, je ne comprends pas le message. Manifestement, _main est interne à SDL, puisque non défini par moi. Il s'y trouve un appel à _SDL_main, encore un truc à eux, et celui-ci ne peut-être résolu ? Je ne sais pas comment lui faire trouver à ce moment-là confus


Quant à la recompilation dont tu parles, j'y ai pensé, mais ça voudrait dire quoi ? Au final, j'aurai la même DLL, les même headers, ça voudrait dire que le format des bibliothèques statiques (LIB) change d'une version de MSVC à une autre ??


Merci en tout cas pour ton aide, même si depuis ce matin, j'ai l'impression d'avancer... en rond triso

10

Autre piste : si tu as choisi "application console" au moment de la création du projet, recrée un nouveau projet en choisissant "application Win32" (les noms ne sont probablement pas exacts, mais en gros c'est le choix entre avoir un main(argc, argv) classique et une console texte, et avoir une application sans console avec le point d'entrée Windows standard (WinMain))
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

11

J'ai également essayé ça. J'ai utilisé le wizard pour créer un projet Console. Ca compilait évidemment. J'ai ajouté mon #include <SDL.h>. Ca compilait toujours ! \o/
Mais c'était bizard, l'IED m'avait créé une 10aine de fichiers auxquels je ne comprenais rien, il n'y avait pas de fonction main, mais une sorte de _tmain(). Mais ça compilait.
Donc je suis reparti sur un projet vide, j'ai réglé les options comme ce que m'a demandé GC.

Etape suivante dans quelques instants : recréer le projet console qui marchait, et faire un diff de la configuration pour voir ce qui ne va pas dans mon projet. J'y arriverai grin

Et merci !

12

En fait, le format des librairies ne varie pas vraiment d'une version à l'autre, mais le runtime de Visual C++ (MSVCRT) est mis à jour à chaque nouvelle version (MSVCRT6, MSVCRT7, MSVCRT8, MSVCRT9, MSVCRT10, …)
Le problème de conflit (comme je pensais qu'il risquait de se présenter), c'est que tu lies de manière statique deux versions différentes du runtime (la version 8 et la version 10), ce qui crée donc un conflit. La partie liée de manière dynamique ne pose pas de problème (si ce n'est que tu vas charger en mémoire deux versions différentes de MSVCRT simultanément), mais la partie statique est plus problématique. Mais passons sur ce problème pour l'instant puisque tu l'as résolu au moins temporairement.

Normalement, d'après l'extrait que j'ai copié plus haut, sdl_main.h va renommer ton main(int argc, const char *argv[]) en SDL_main(int argc, const char *argv[]).

Comme ton projet est un projet C++, les noms de fonctions sont décorés par le compilateur (l'algorithme dépend du compilateur, et même parfois de la version de celui-ci), contrairement à ce qui se passe en langage C brut. La décoration en soi est un détail interne, mais, ça permet de supporter entre autres la surcharge de méthodes, ce que e langage C ne permet pas. (La décoration tient compte de la convention d'appel, du type des paramètres, du type de la valeur de retour, …)
Mais ta fonction main doit être définie comme une fonction C. La déclaration dans le fichier sdl_main.h devrait normalement remplir ce rôle, mais comme tu n'as pas spécifié le même prototype (char **argv au lieu de char *argv[]), je me demande si ça ne pourrait pas être le problème. (Il se peut que ton SDL_main et que le SDL_main défini par sdl_main.h soient vus comme deux fonctions distinctes par le compilateur, et que ta fonction main soit exportée comme une fonction C++)

Essaye de corriger le prototype de ton main pour qu'il corresponde à ce qui est indiqué dans sdl_main.h. Si cela fonctionne, ta fonction devrait être reconnue comme une fonction C, appelée avec la convention d'appel cdecl, et donc exportée en « _SDL_main » (la décoration par défaut pour cdecl est de préfixer le nom de la fonction par un _, stdcall procède de manière similaire, mais ajoute à la fin de la fonction un @N où N indique la taille en octets des paramètres de la fonction… (D'où _WinMain@16 en 32 bits))
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

13

Merci encore. Tiens, un exemple de ce que me pond le wizard de projet :
code
// DoAnySpr.cpp : définit le point d'entrée pour l'application.
//

#include "stdafx.h"
#include "DoAnySpr.h"

#define MAX_LOADSTRING 100

// Variables globales :
HINSTANCE hInst;								// instance actuelle
TCHAR szTitle[MAX_LOADSTRING];					// Le texte de la barre de titre
TCHAR szWindowClass[MAX_LOADSTRING];			// le nom de la classe de fenêtre principale

// Pré-déclarations des fonctions incluses dans ce module de code :
ATOM				MyRegisterClass(HINSTANCE hInstance);
BOOL				InitInstance(HINSTANCE, int);
LRESULT CALLBACK	WndProc(HWND, UINT, WPARAM, LPARAM);
INT_PTR CALLBACK	About(HWND, UINT, WPARAM, LPARAM);

int APIENTRY _tWinMain(HINSTANCE hInstance,
                     HINSTANCE hPrevInstance,
                     LPTSTR    lpCmdLine,
                     int       nCmdShow)
{
	UNREFERENCED_PARAMETER(hPrevInstance);
	UNREFERENCED_PARAMETER(lpCmdLine);

 	// TODO: placez ici le code.
	MSG msg;
	HACCEL hAccelTable;

	// Initialise les chaînes globales
	LoadString(hInstance, IDS_APP_TITLE, szTitle, MAX_LOADSTRING);
	LoadString(hInstance, IDC_DOANYSPR, szWindowClass, MAX_LOADSTRING);
	MyRegisterClass(hInstance);

	// Effectue l'initialisation de l'application :
	if (!InitInstance (hInstance, nCmdShow))
	{
		return FALSE;
	}

	hAccelTable = LoadAccelerators(hInstance, MAKEINTRESOURCE(IDC_DOANYSPR));

	// Boucle de messages principale :
	while (GetMessage(&msg, NULL, 0, 0))
	{
		if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
		{
			TranslateMessage(&msg);
			DispatchMessage(&msg);
		}
	}

	return (int) msg.wParam;
}



//
//  FONCTION : MyRegisterClass()
//
//  BUT : inscrit la classe de fenêtre.
//
//  COMMENTAIRES :
//
//    Cette fonction et son utilisation sont nécessaires uniquement si vous souhaitez que ce code
//    soit compatible avec les systèmes Win32 avant la fonction 'RegisterClassEx'
//    qui a été ajoutée à Windows 95. Il est important d'appeler cette fonction
//    afin que l'application dispose des petites icônes correctes qui lui sont
//    associées.
//
ATOM MyRegisterClass(HINSTANCE hInstance)
{
	WNDCLASSEX wcex;

	wcex.cbSize = sizeof(WNDCLASSEX);

	wcex.style			= CS_HREDRAW | CS_VREDRAW;
	wcex.lpfnWndProc	= WndProc;
	wcex.cbClsExtra		= 0;
	wcex.cbWndExtra		= 0;
	wcex.hInstance		= hInstance;
	wcex.hIcon			= LoadIcon(hInstance, MAKEINTRESOURCE(IDI_DOANYSPR));
	wcex.hCursor		= LoadCursor(NULL, IDC_ARROW);
	wcex.hbrBackground	= (HBRUSH)(COLOR_WINDOW+1);
	wcex.lpszMenuName	= MAKEINTRESOURCE(IDC_DOANYSPR);
	wcex.lpszClassName	= szWindowClass;
	wcex.hIconSm		= LoadIcon(wcex.hInstance, MAKEINTRESOURCE(IDI_SMALL));

	return RegisterClassEx(&wcex);
}

//
//   FONCTION : InitInstance(HINSTANCE, int)
//
//   BUT : enregistre le handle de l'instance et crée une fenêtre principale
//
//   COMMENTAIRES :
//
//        Dans cette fonction, nous enregistrons le handle de l'instance dans une variable globale, puis
//        créons et affichons la fenêtre principale du programme.
//
BOOL InitInstance(HINSTANCE hInstance, int nCmdShow)
{
   HWND hWnd;

   hInst = hInstance; // Stocke le handle d'instance dans la variable globale

   hWnd = CreateWindow(szWindowClass, szTitle, WS_OVERLAPPEDWINDOW,
      CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);

   if (!hWnd)
   {
      return FALSE;
   }

   ShowWindow(hWnd, nCmdShow);
   UpdateWindow(hWnd);

   return TRUE;
}

//
//  FONCTION : WndProc(HWND, UINT, WPARAM, LPARAM)
//
//  BUT :  traite les messages pour la fenêtre principale.
//
//  WM_COMMAND	- traite le menu de l'application
//  WM_PAINT	- dessine la fenêtre principale
//  WM_DESTROY	- génère un message d'arrêt et retourne
//
//
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
	int wmId, wmEvent;
	PAINTSTRUCT ps;
	HDC hdc;

	switch (message)
	{
	case WM_COMMAND:
		wmId    = LOWORD(wParam);
		wmEvent = HIWORD(wParam);
		// Analyse les sélections de menu :
		switch (wmId)
		{
		case IDM_ABOUT:
			DialogBox(hInst, MAKEINTRESOURCE(IDD_ABOUTBOX), hWnd, About);
			break;
		case IDM_EXIT:
			DestroyWindow(hWnd);
			break;
		default:
			return DefWindowProc(hWnd, message, wParam, lParam);
		}
		break;
	case WM_PAINT:
		hdc = BeginPaint(hWnd, &ps);
		// TODO: ajoutez ici le code de dessin...
		EndPaint(hWnd, &ps);
		break;
	case WM_DESTROY:
		PostQuitMessage(0);
		break;
	default:
		return DefWindowProc(hWnd, message, wParam, lParam);
	}
	return 0;
}

// Gestionnaire de messages pour la boîte de dialogue À propos de.
INT_PTR CALLBACK About(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
	UNREFERENCED_PARAMETER(lParam);
	switch (message)
	{
	case WM_INITDIALOG:
		return (INT_PTR)TRUE;

	case WM_COMMAND:
		if (LOWORD(wParam) == IDOK || LOWORD(wParam) == IDCANCEL)
		{
			EndDialog(hDlg, LOWORD(wParam));
			return (INT_PTR)TRUE;
		}
		break;
	}
	return (INT_PTR)FALSE;
}

Et c'est qu'un fichier, il y en a un autre, et 4 headers.
Je n'y comprends rien, et c'est pas parce que "ça marche" que je vais commencer à coder avec ça.


Tiens au fait, sous nux ou MinGW, fallait passer -lSDL_main au linker, il n'y a pas un équivalent avec MSVC ?

14

Le seul avantage des modèles de projet de Visual C++, c'est qu'ils te configurent bien les en-têtes précompilées (c'est un peu galère à faire à la main, mais rien d'insurmontable) qui accélèrent grandement la compilation des projets un peu complexes quand tu les utilises correctement… ^^
Sinon, il vaut mieux cocher la case « empty project ». oui

En fait ce que ça te pond là, c'est un modèle d'une application Windows qui affiche une fenêtre. Dans ton cas, tu veux une application SDL, donc tu n'en as pas besoin, et en outre cela, le modèle de code est inutilisable en l'état. (Il fonctionne, mais tu ne voudrais certainement pas coder une application sérieuse en te basant sur ce modèle. C'est plus un exemple pour te montrer comment ça marche (et te montrer que *ça marche*) qu'un vrai modèle.)

Sinon, tu as réussi à faire marcher SDL finalement ou pas ?
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

15

GoldenCrystal (./14) :
Sinon, tu as réussi à faire marcher SDL finalement ou pas ?

Oui !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

(vas-y Zerosquare, tabasse-moi trilove)
GoldenCrystal (./12) :
Essaye de corriger le prototype de ton main pour qu'il corresponde à ce qui est indiqué dans sdl_main.h

C'était bien ça ! Dans les souvenirs de mon bouquin de C++, ça s'appelle la signature de la fonction, non ? Du moins, ça ne prend pas en compte la valeur de retour, mais juste le nombre et le type des arguments.


Donc j'ai bien un exécutable pratiquement vide, qui crash pas (sans blague ^^).
Par contre, petit problème pas grave : il me dit que SDL.dll n'est pas trouvable, alors qu'il est dans system32. Ca marche si je le mets dans le répertoire courant par contre. Mais bon, "ça compile" love



Merci beaucoup !!! calin


(bon, maintenant que ça marche, j'ai vu partout sur le net qu'il était conseillé aux malheureux qui galéraient avec la SDL d'utiliser SFML, on va voir ça, je suis déjà dans la doc trivil. J'avais repéré cette lib il y a quelques mois, pourquoi pas grin)

16

À tout hasard, tu as un Windows 7 64 bits ?

Sinon, effectivement, pour la résolution des fonctions quand il y a plusieurs surcharges, ce ne sont que les paramètres qui comptent. Car tu ne peux pas faire de différente entre toto(0) qui retourne un char* et toto(0) qui retourne un int quand tu vois un appel dans une fonction en C(++). (C'est pareil en java, C#, et à peu près tous les langages avec un mécanisme similaire ^^)
En revanche, le type de la valeur de retour est bien pris en compte pour la décoration des fonctions oui
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

17

GoldenCrystal (./16) :
À tout hasard, tu as un Windows 7 64 bits ?

Yes. T'es extra lucide ? oO

Et merci pour le petit cours de déco. smile

18

Folco (./15) :
(vas-y Zerosquare, tabasse-moi trilove.gif )
Euh, pourquoi ? grin
Et puis je ne fais de mal à personne moi embarrassed
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

19

En fait, ton SDL est compilé en 32 bits, et à priori ton projet aussi (sinon ça ne démarrerait pas triso).
Or, une application 32 bits s'exécute dans l'environnement 32 bits. Sous Windows 64 bits, le répertoire System32 est celui qui contient les dll systèmes comme sur n'importe quel autre Windows depuis 95, sauf que c'est un système 64 bits donc il contient des dll 64 bits. (Oui je sais, c'est un peu triso, mais l'erreur à la base c'est de l'avoir appelé « System32 »)
Lorsque ton application s'exécute en 32 bits, l'environnement d'exécution est une mini-sandbox (un peu comme quand tu exécute une application en mode utilisateur avec UAC activé), et tu vas chercher les DLL dans le répertoire System32 qui est en réalité « SysWOW64 » (WOW = Windows (32 bits) On Windows 64 (bits)).
Donc en réalité, la meilleure solution (la plus portable) est d'installer ta dll dans le répertoire de l'application comme tu l'as fait (car tu n'as pas besoin d'avoir la moindre information sur le système hôte dans ce cas, et en plus tu évites des problèmes de version potentiels), mais si tu avais voulu la mettre « au bon endroit », tu aurais du la mettre dans le répertoire « SysWOW64 ».
(Le mieux après c'est de coder proprement ton application et de proposer une version 64 bits en parallèle à la version 32 bits… Mais pour ça il faut recompiler SDL en x64 aussi smile)
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

20

Désolé, c'est moi qui ai induit Folco en erreur... Il m'a demandé s'il pouvait mettre SDL.DLL dans System32, et j'ai répondu oui parce qu'historiquement ça fait partie des chemins dans lesquels Windows recherche les DLL. Je ne savais pas et ne pensais pas qu'ils avaient changé ça dans Seven 64 bits (d'ailleurs ça doit casser pas mal d'installeurs, non ?)
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

21

Non en fait ça n'a pas changé ^^
Il y a juste le System32 32 bits et le System32 64 bits. (Et Program Files 32/64 bits aussi)
En gros à l'intérieur de la sandbox, l'application 32 bits voit le système comme si c'était un système 32 bits. Ça affecte principalement sa vision dus système de fichier et de la base de registres, mais il y a certainement quelques autres trucs annexes.
Donc en fait non, ça ne casse absolument rien (en tout cas rien de bien codé), et je pense que c'est pour ça que ça a été fait. (Car pas mal d'application ont du coder en dur System32 quelque part dans leur code source)
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

22

Ah OK, ils ont sandboxé comme ça... Ça doit être la joie pour assurer la migration 32->64, et expliquer aux utilisateurs que s'ils voient un message d'erreur avec un chemin d'accès, ça correspond pas à la réalité trioui
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

23

et je suis sûr qu'on peut encore exécuter la calculette de windows 1 sur seven x86_64 trioui

24

Avec dosbox, certainement… trioui (Ça peut faire tourner sans souci Windows 3.1, alors… smile)
Mais Windows x64 ne supporte pas l'exécution de programmes Win16 (et Win32 a été introduit avec Windows 3.1/4.0)
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

25

Non, les exécutables 16 bits ne marchent plus sous les versions 64 bits de Windows (mais c'est à cause des procos 64 bits, qui ne sont pas prévus pour switcher à la volée entre mode 16 bits et mode 64 bits).

edit: cross
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

26

27

Non, c'est mieux, fait chier le mode segmenté :/

Kochise
avatar
Si Dieu m'a de nouveau fait homme, cette fois il m'a pas raté : marcher sur l'eau et dupliquer les pains, ça marche p'us :/

28

Tiens
Folco (./13) :
Tiens au fait, sous nux ou MinGW, fallait passer -lSDL_main au linker, il n'y a pas un équivalent avec MSVC ?
J'avais zappé cette partie mais… C'est pas ce que tu as fait (utiliser l'équivalent sous VC++) quand je t'a dit d'ajouter SDLmain.lib et SDL.lib aux entrées du linker ? trifus
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

29

J'ai compris après que c'était la même chose #triclasse#

ps -> J'ai pu recompiler la SFML pour VC 2010 \o/

Tiens, c'est pareil avc SFML, si on veut éviter de se ballader avec un terminal, et si on veut éviter de redéfinir un WinMain() kivabien pour Windows, on peut linker avec SFML-main.lib et utiliser un main() simple et portable. Pas mal. smile

30

Tiens, je viens de percuter un truc.

Si j'ai raté initialement le passage des fichiers *.lib au linker, c'est que j'avais spécifié, dans les "Chemins VC++ 2010", le répertoire des .lib que mon projet devait utiliser, et donc pour moi ça suffisait.
Hors il se trouve que c'est aussi dans cet onglet qu'on spécifie les chemins d'include supplémentaires. Et les *.hpp sont utilisés par le compilateur, pas par le linker.

D'où ma question : est-ce que le compilateur utilise les fichiers .lib ? Et si oui, pourquoi ? D'après ce que j'ai pu comprendre en bossant sur mon assembleur, un fichier de bibliothèque statique peut n'être qu'une archive de fichiers objets, avec éventuellement quelques méta-données. Alors pourquoi spécifier le chemin d'accès de mes .lib au niveau du compilateur ?