il faut que tu compile ton code en C, ou alors tu englobe ton code qui fait appel a ces 3 fonctions dans un bloque

extern "C"
{
   ...
}

Voici la signature de la methode qui exporte la clef :

public override string ToXmlString(bool includePrivateParameters)

je n'ai pas mon code sous les yeux, mais il me semble bien avoir mis false, pour evidement ne pas exporter la clef privée, ce qui aurait effectivement des conséquences dramatique sur le plan de la sécurité.

effectivement c'est un oubli, mais parfois tester une exception prend un temps bien long, donc je prefere les eviter le plus possible, et dans ce cas c'est faisable en remplacant le code par ceci :

XmlAttribute time_attr = node.Attributes["Time"];
_time = 15;
if (time_attr != null)
{
    if (int.TryParse(time_attr.Value, _minute) == false)
        _time = 15;
}

comme ca, si il n'y a pas de valeur ou si ce n'est pas une valeur numerique, on a une valeur par defaut, et si tout est correct, on a la bonne valeur bien parsée.

Aucune idee pour l'ejection, desoler.
Il semble que tu ne soit pas le seul interesser.

Heu... j'ai deposer ce source il y a bientot 3 ans alors je ne me rappel plus comment se passe l'init, et je n'ai pas vraiment le temps de regarder la.
Pour les commentaires, ouais je sais, desoler.
Pour les noms de variables, je crois avoir toujours utiliser des noms correcte quand il le fallait.

?

tu peux utiliser un seul VertexBuffer dans lequel tu met tous les points, et ensuite tu fait un seul appel a SetStreamSource et DrawPrimitives :

device.SetStreamSource(0, vertices, 0);
device.DrawPrimitives(PrimitiveType.TriangleList, 0, 2);

2  pour dire que tu as 2 triangles dans ton VertexBuffer. Aussi, DirectDraw est deprecated, tout comme GAPI... il a été a plusieurs reprises démontrer qu'il était carrement plus rentable de tracer (meme de la 2D) en utilisant les fonctionnalitées 3D... et donc forcement, par ce biais, la question la plus legitime a se poser est : "dans ce cas pourquoi maintenir 3 lib differentes alors qu'une seul rempli le boulot des 2 autres et de maniere plus performante".

voila

voilà, c'est up to date, mais ca ne veut pas dire que c'est fini, il y a encore des parties de code qui sont factorisable je pense, et de plus je n'ai pas tester les modifs :S je le ferais prochainement

ensuite il faudra que je relise tout les posts de cette page et faire un resumer de ce que je dois prendre en compte pour les autres modifs futures

bon week-end a tous

je rectifie, les 80 warnings c'etait dans le debugger, le préprocesseur n'en avait que 13... ce n'est pas très interessant mais ca corrige l'incohérence précédente.

bon sinon pour le code a factoriser, bah en fait les premieres conclusion sont :

le code qui me semble etre le seul factorisable est le code ou se trouvent les fonctions equivalente aux opcodes (fichier parse_opcodes.c dans le projet libkvm)
le code factorisable est le code de verification de l'etat de la pile et de l'etat du tas (verification des stack overflow et de l'adressage), j'en ai tiré 3 conclusions, les voici :

1ere conclusion : je peux factoriser du code dans des fonctions, ce qui ne me fera ecomiser que 4 lignes de codes par fonction en moyenne (et encore, dans peu de fonctions), c'est pas terrible et je veux pas faire trop d'appel (les empilement/dépilement d'appels de fonction prennent du temps)

2eme conclusion : je peux remplacer des bouts de code plus ou moins similaires par des #define, mais ca implique d'avoir des BEGIN_TRUC et END_TRUC... pas terrible, de plus ca fera des #defines mega degeulasse, et les #define c'est pas terrible pour débugger ni pour comprendre le code

3eme conclusion : j'oublie les 2 premieres conclusion et je laise le code tel quel.

enfin biensure je ne le laisse pas tel quel, le préprocesseur et la machine virtuelle compile en 0 errors 0 warnings, toutes les fonctions deprecated on été remplacées par les nouvelles fonctions secure, j'ai corrigé le bug de la table d'adressage qui etait pas reinitialiser au chargement d'un autre script.

pour le moment c'est a peut pres tout, mais je continue a déwarniser les autres projets et j'espere pouvoir vous fournir un truc correct bientot.

je vais aussi essayer de faire tourner un truc qui dechire sur mon PDA pour faire des tests de perfs... je sais pas encore quoi mais je compte sur vous pour me donner des idées ^^

merci a vous de suivre le projet, et a très bientot pour la mise a jour de KonKyo en Visual Studio 2005

Message pour ceux que ca peut eventuellement interesser, je suis en train de passer le code de KonKyo en Visual Studio 2005, et je vais en profiter pour factoriser un max de code d'execution du bytecode pour augmenter les perfs, et je vais aussi regler au passage le probleme du rechargement d'un script dans une meme machine virtuelle.

Je peux pas garantir de delai car je lutte un peu, a cause des fonction C standard passées en deprecated, j'ai 80 warnings et rien que sur le préprocesseur :S

donc voila, je vous tiendrais au courrant quand tout sera fini, je posterais une mise a jour avec le nouveau code