Révise tes classiques :
- Les WinSock utilisent l'interface BSD, incompatible avec POSIX (fdopen marche pas). Il a fallu que je réécrive les entrées/sorties de certaines libs (jpeg, png qui utilisent stdio) rien que pour ça (1/2 jour de perdu).
- La p...n de conversion des \n et \n\r. Complétement oublié ce bug^W^Wcette feature. 1/2 jour de perdus pour débugger et retrouver un appel non portable, spécifique Windows (retrouvé dans les sources de perl, d'ailleurs).
- Pour avoir des perfs potables, il a fallu que je mettre en place un système de cache multi-threadé, en utilisant l'API win32 (les pthreads, c'est pas trop ça). Bonjour, les emm..des pour vérifier que toutes les libs étaient reentrantes.
Je parie qu'avec Win32, les MFC ou truc net, je n'aurais pas eu tous ces problèmes. Mais bon, on a dit portabilité.
[^] # Re: Même combat ici ...
Posté par pierthi . En réponse au journal Internet Explorer et Javascript. Évalué à 3.
Révise tes classiques :
- Les WinSock utilisent l'interface BSD, incompatible avec POSIX (fdopen marche pas). Il a fallu que je réécrive les entrées/sorties de certaines libs (jpeg, png qui utilisent stdio) rien que pour ça (1/2 jour de perdu).
- La p...n de conversion des \n et \n\r. Complétement oublié ce bug^W^Wcette feature. 1/2 jour de perdus pour débugger et retrouver un appel non portable, spécifique Windows (retrouvé dans les sources de perl, d'ailleurs).
- Pour avoir des perfs potables, il a fallu que je mettre en place un système de cache multi-threadé, en utilisant l'API win32 (les pthreads, c'est pas trop ça). Bonjour, les emm..des pour vérifier que toutes les libs étaient reentrantes.
Je parie qu'avec Win32, les MFC ou truc net, je n'aurais pas eu tous ces problèmes. Mais bon, on a dit portabilité.