Y compris la fonctionnalité d'être une application native avec un look&feel pleinement natif

Ce n'est pas le look&feel natif, ça?

Pas très natives, les images des boutons dans les fenêtres Code/Source et Breakpoints, en particulier la croix rouge et le sens interdit... C'est exactement la même non-nativité que celle dans le menu déclenché par un clic droit sur Ekiga dans le systray, pointée par squalyl en topics/2-116489-java-swing/3 . Non-nativité partagée par Wireshark (essayé récemment), FreeCiv (essayé il y a plus longtemps) et bien d'autres.

Un des désavantages de la version GDB de TIEmu est la syntaxe du désassembleur. Tu n'es pas d'accord, tu aimes super bien les %, les instructions en octal et tout, on sait, mais nous on préfère la syntaxe de la version sans GDB, qui est aussi la syntaxe de VTI, et tu le sais. On voudrait bien avoir le choix, tu le sais, mais tu n'es pas d'accord.

TIEmu fonctionne effectivement sous 9x/ME. Du moins, il fonctionnait la dernière fois que j'ai essayé, ça doit faire entre quatre et cinq ans. Il est "juste" péniblement lent comparé à VTI sur n'importe quel Windows, et TIEmu sur Win 2000+, à cause de limitations de 9x/ME. Jamais essayé sous Vista, ceci dit.
Et encore, je n'ai jamais essayé la version GDB sur mon Athlon 1 GHz tournant ME... vu que la version GDB est visiblement ("noticeably") plus lente à l'utilisation sous Linux sur mon Core 2 Duo @ 2 GHz que la version sans GDB, je crains le pire sous une machine beaucoup moins puissante, tournant Win ME...
Même si la lenteur de TIEmu, que roms avait pu voir quand il était venu à la maison, a dû être diminuée par le preloading qu'il a implémenté. Entre deux et trois secondes pour ouvrir le debugger (sans GDB, à l'époque) la première fois, environ une seconde la deuxième fois, et des centaines de milisecondes pour redessiner lors d'un single stepping, ce n'était vraiment pas drôle...