Author Topic: Programmation W32 <-> ORBITER SDK , possible ou pas ? (Read 13547 times)

MrSpock · Reply #50 - 28 July 2010, 15:55:16

Quote

et je copie la dll dans le répertoire modules/plugins.

Quelle Dll s'il te plait ?
Et normalement , tu déposes ta DLL une fois pour toutes ... comprends pas .

Quote

Le hic dans notre cas c'est qu'on aimerai bien se passer de l'interface de lancement d'orbiter. donc pour éviter ca je patche le fichier de config d'orbiter. je reviendrai là dessus par la suite en ajoutant mon module à la liste. et ce à chaque démarrage de mission( je vérifie qu'il est bien dans la liste)

Par contre cette info m'est trés utile .

Quote

ensuite je démarre le scenario en lancant orbiter avec l'option '\s' qui permet justement de lancer sans l'interface initiale (merci amrtin pour cette option non documentée mais qui existe depuis le début)

YEAH !:hot:
Celle là encore + !
Merci ,
Spock.

Message modifié ( 28-07-2010 15:57 )

tofitouf · Reply #51 - 28 July 2010, 16:34:49

la dll est OCModule.dll, c'est elle qui gère les objectifs

MrSpock · Reply #52 - 28 July 2010, 16:47:21

Tu la copies à chaque fois ? Pourquoi ?

Quote

pour info dans mon MFDLib j'ai une classe qui intercepte tous les appels que fait orbiter et les redirige dans une classe virtuelle.
Cela me permet de ne rien oublier et d'avoir un bon fonctionnement bien c++ (j'aime le language objet on ne se refait pas)

Je vais y réfléchir ...

Spock.

Message modifié ( 28-07-2010 16:53 )

tofitouf · Reply #53 - 28 July 2010, 16:58:09

je la copie à chaque fois pour éviter qu'un ptit malin l'ai modifé pour tenter de tricher

MrSpock · Reply #54 - 28 July 2010, 17:03:10

Ah ... un ptit malin comme moi ?
Non , c'est pas mon trip de tuer le jeu , j'suis FAIRPLAY !:diable:
Sinon , si les bugs étaient des fruits , OrbiterChallenge serait un Arbre fruitier !:diable:

Non , je te taquine encore .
Mais moi j'essaye plus rien tant que je n'ai pas une doc en bonne et due forme !
NA !
MrSpock !

MrSpock · Reply #55 - 29 July 2010, 15:41:10

En attendant le retour de Tofitouf pour le débuggage d'OrbiterChallenge , je me suis remis aux PIPES et ...
BONNE NOUVELLE !!

Je viens de réussir une connection Internet entre un Serveur ( pc de mon Labo) et un client ( pc de mon Salon).
Je n'ai pas de réseau Local actuellement ( en fait si ... mes pc sont connectés sur le serveur de free ,routeur activé et
réseau sans fil ).
Je ne sais pas ce que cela donnerait en dehors de ce réseau .
Le moment venu ,j'aurais besoin de testeurs ...

Le type de connection est Asyncrone et non-bloquante .
Je n'ai pas encore éssayé de faire passer des données , peut-être avant ce soir .
Principe : Je donne l'adresse du serveur ( ip attribuée par DNS de free ...) comme Adresse de serveur au Client auquel j'ajoute le nom de la connection PIPE .

L'intérêt , c'est que c'est possible d'ouvrir plusieurs instances de Pipes par serveur .

Exemple :
Pipe 1:
Serveur\\pipe\\OrbiterData
Pipe2
Serveur\\pipe\\OrbiterChat
Pipe3
Serveur\\pipe\\OrbiterVoice

Ceci simplifierait beaucoup la gestion des messages , puisque chaque demande utilise un canal ( Thread+pipe)séparé.
Je continue sur ma lancée , et au fait , même si je suis Actuellement sous Borland , j'écris une classe qui pourra être
utilisée dans visual studio !
A++
MrSpock !
REEDIT : Par contre , niveau sécurité :
Le pare-Feu n'a pas réagit du tout ! DOnc il n'y a pas d'ouverture de ports classiques ...
La seule sécurité réside dans le nom unique de serveur+nom du pipe .
Donc, quelqu'un de mal intentionné voulant détruire un serveur qui connaitrait son adresse ET le nom du Pipe
pourrait faire des dégats .

Message modifié ( 29-07-2010 15:49 )

pilote334 · Reply #56 - 29 July 2010, 19:10:59

Ouais,

Quote

REEDIT : Par contre , niveau sécurité :
Le pare-Feu n'a pas réagit du tout ! DOnc il n'y a pas d'ouverture de ports classiques ...
La seule sécurité réside dans le nom unique de serveur+nom du pipe .
Donc, quelqu'un de mal intentionné voulant détruire un serveur qui connaitrait son adresse ET le nom du Pipe
pourrait faire des dégats .

c'est pour ça que j'ai une préférence pour les sockets (association adresse+port)....

Yves

MrSpock · Reply #57 - 29 July 2010, 20:39:03

Quote

c'est pour ça que j'ai une préférence pour les sockets (association adresse+port)....

C'est vrai que dans ma vision , je n'avais pas du tout ( mais pas du tout Hein !) envisagé la protection ...
Bah , cela va me faire bouillir le chaudron jusqu'à ce qu'une bonne odeur s'échappe ...
Mais si je dois coder un gestionnaire de messages + 1 gestionnaire de sécurité + je ne sais quoi encore , la solution
" toute prête " des sockets sera l'option choisie .

EN attendant , tout ceci m'apprend beaucoup sur le fonctionnement du PC et ... m'amuse bien aussi .
A suivre donc .
MrSpock .

REEDIT : Hé ! Mais en fait, même avec socket et parefeu , tu autorises les ports ( associés à une application ) .
Ben voilà ! Au moins j'ai le niveau de base d'un Firewall bas de gamme en récupérant le nom du processus qui veut
ecrire ( lire c'est pas un problème , quoi que ..) et en lui accordant des droits . Je vais y bosser , tiens !

Message modifié ( 29-07-2010 21:13 )

MrSpock · Reply #58 - 30 July 2010, 19:11:29

A propos de la sécurité ...
Vous avez du remarquer que je ne suis pas expert en la matière , et pour cause :
C'EST STUPIDE D'EXPLIQUER LA METHODE UTILISEE , SUR UN FORUM PUBLIC !!!
(j'm'en suis rendu compte aprés coup ... donc plus d'explication à ce sujet ...)

MrSpock .

pilote334 · Reply #59 - 30 July 2010, 23:22:21

La vraie sécurité, c'est la méthode que tu peux exposer au grand jour. C'est le cas des sockets : la sécurité réside dans le fait que tu n'autorises le port pour qu'une application déterminée. Si celle-ci ne tourne pas, l'association disparait de fait et avoir ce port ouvert ne trahit pas la sécurité puisqu'il n'y a rien en face. Et lorsque l'application tourne, c'est à l'application de ne pas permettre un appel de procédure externe. Le problème est alors étouffé dans l'oeuf !

Yves

MrSpock · Reply #60 - 30 July 2010, 23:34:52

Certes , Yves , mais j'ai la capacité de nommer un programme "Orbiter" , qui n'aura d'Orbiter que le nom !!
Tu me suis ?

MrSpock .

pilote334 · Reply #61 - 31 July 2010, 18:02:04

Oui, bien sûr mais le danger n'est pas du côté de l'émetteur qui peut faire ce qu'il veut (y compris créer un prg orbiter bidon) mais côté récepteur (client) qui doit savoir ce qu'il installe ! c'est la moindre des choses ! et les ports qu'il ouvre.

D'autre part, dans mon système, le port client n'est actif (n'interprète des données) que si le modules multijoueur est actif en mode client ou serveur. Dans tous les autres cas, les données arrivent....dans le vide !

Donc la sécurité réside dans le postulat suivant : une application communicante = un port (ou une plage de ports).

Non, le vrai danger, ce sont les scanneurs de ports, car ils peuvent voir sur une adresse ip particulière les protocoles actifs (les ports ouverts autrement dit).

Après, c'est l'écriture des applis qui doit être propre et ne communiquer en aucun cas avec le système d'exploitation et ses services sensibles. L'appli est responsable de cette sécurité.

Bizarrement Microsoft a très bien compris et respecté ce principe en produisant l'active directory. Aujourd'hui, paramétré correctement, Windows est devenu un environnement sûr dans ce contexte là. Hélas, il ne met pas à l'abri de téléchargement d'applis malveillante, et la complexité de ce système ouvre forcément des failles...

Faut savoir ce qu'on veut, c'est le prix de la polyvalence...

MrSpock · Reply #62 - 31 July 2010, 18:16:28

Quote

Non, le vrai danger, ce sont les scanneurs de ports, car ils peuvent voir sur une adresse ip particulière les protocoles actifs (les ports ouverts autrement dit).

Après, c'est l'écriture des applis qui doit être propre et ne communiquer en aucun cas avec le système d'exploitation et ses services sensibles. L'appli est responsable de cette sécurité.

Je retiens çà ! Merci !
Spock.

MrSpock · Reply #63 - 01 August 2010, 03:37:53

Salut !
En parcourant le SDK , j'ai trouvé une des infos qui me manquaient :

Quote

// ExtMFD.cpp
//
// Open multifunctional displays (MFD) in external windows
// ==============================================================

En gros , pour faire du Multi-écrans à base de carte vidéo double sortie , ce n'est pas la peine d'utiliser les SOCKETS ou LES PIPES puisque Orbiter le fait "les doigts dans le nez !" .
Le plus drôle , c'est que

Spoiler :

Heureusement , qui cherche trouve .
Donc bientôt j'aurais mes MFD sur un 19 pouces , et la scène sur VideoProjecteur .
Que demande le peuple ?
8)
MrSPock .

Message modifié ( 01-08-2010 03:45 )

MrSpock · Reply #64 - 03 August 2010, 20:14:05

Salut !
Je viens juste d'ouvrir le fichier d'aide HTML compilé de Orbiter 2010 et constaté qu'elle était bien fournie .
J'étais resté à l'autre version jusque là .
Du coup , je me demande ce que je dois faire : Suivre l'évolution et passer en 2010 , en risquant des incompatibilités
avec les versions antérieures , ou anticiper la migration des utilisateurs ?
Bah , en fait , faut vivre avec son temps ...
C'est parti , 2010 !

MrSpock · Reply #65 - 07 August 2010, 05:01:48

Salut !
Avez-vous besoin d'afficher une boite de dialogue de type MessageBox(HWND,char*,char*,MB_OK) ?
Moi oui !
Et jusqu'à présent , je donnais HWND=NULL car je ne savais pas comment l'obtenir !
Résultat , je ne pouvais pas débugger en mode FULLSCREEN et je devais alterner les fenêtres en mode fenétré ...
Pourtant , le SDK Win32 fournit cette fonction :

Quote

The GetActiveWindow function retrieves the window handle to the active window associated with the thread that calls the function.

HWND GetActiveWindow(VOID)

J'ai donc déclaré en début de fichier .cpp :

Code: [Select]

// ==============================================================
// Global variables
HWND wnd=NULL ;

Puis , j'ai utilisé la fonction comme ceci :

Code: [Select]

DLLCLBK void opcDLLInit (HINSTANCE hDLL)
{
wnd=GetActiveWindow();
...

Lancement d'Orbiter , au moment voulu , la fenêtre s'ouvre , mais toujours cachée par Orbiter !
1 mn plus tard , je réalise que cette fonction fournit un HWND par rapport au thread appelant ET QUE MON MODULE
EST CHARGé via le LaunchPANEL ...
Voulant débugger mon MFD , j'ai déplacé la fonction ici :

Code: [Select]

//Initialisation du MFD   
MFDMeshPoser::MFDMeshPoser (DWORD w, DWORD h, VESSEL *vessel)
: MFD (w, h, vessel)
{
	// Add MFD initialisation here
	wnd=GetActiveWindow();
	....
	
}

Et là , c'est ok !
Ma boîte de dialogue s'ouvre en mode fenêtre et Fullscreen !
En espérant que ce petit truc vous servira un jour ....

Message modifié ( 07-08-2010 05:11 )