WEEK END BIEN REMPLI, MERCI VS 2005

Ah ce VS 2005, un plaisir je vous dis...

Récupérer une valeur __int64 saisie en chaine ou mettre cette valeur en chaine:

void __stdcall Test(HWND hdlg)
{
  char buf[32];
  __int64 r;
   strcpy(buf, "-987654321987654321");
  r = _atoi64(buf);
  _i64toa(r, buf);
  MessageBox(hdlg, buf, szappname, 0);
}

Jusque là tout va bon, mais cette simple MessageBox vous fera un exe de 37 Ko minimum, une paille.
Alors on se dit: "Je vais me passer du CRT".
C'est somme toute fort inutile si on prog en API, aucun besoin du support multithread CRT puisque j'appelle toujours CreateThread en direct et je n'emploie jamais strtok ou autre fonction pour débile profond de ce genre.
On commencera donc le prog ici (simple exemple):

#pragma comment(linker, "/entry:myWinMain")
__declspec(naked) int __stdcall myWinMain()
{
  __asm {
    push    0
    call    dword ptr GetModuleHandle
    push    eax
    push    offset AppDlgProc
    push    0
    push    IDD_APP
    push    eax
    call    dword ptr DialogBoxParam
    push    0
    call    dword ptr ExitProcess
  }
}

Normalement, on obtient le même prog mais de 37 Ko il passe à 3 Ko.
Ben non, trop simple tout cela, ça passait sur les anciens VS mais plus sur le 2005, là oui on se rend compte d'avoir un nouveau compilo sinon...
A partir de dorénavant et dans le cadre de l'emmerdement maximal, plus d'accès aux fonctions standards de la libc si on saute le CRT, adieu itoa() atoi() etc..., consorts 64 bits idem.
Ma simple fonction Test() deviendra par force:

void __stdcall Test(HWND hdlg)
{
  char buf[32];
  __int64 r;
  strcpy(buf, "-987654321987654321");
  r = bnatoi64(buf);
  bni64toa(r, buf);
  MessageBox(hdlg, buf, szappname, 0);
}

Finalement pas de quoi raler puisqu'il suffisait de réécrire une libc perso, dont un extrait:

__declspec(naked) char* __fastcall bnultoa(unsigned int dwnum, char* szdst);
__declspec(naked) char* __fastcall bnitoa(int inum, char* szdst);
__declspec(naked) DWORD __fastcall bnatoui(char *szsrc);
__declspec(naked) int __fastcall bnatoi(char *szsrc);

__declspec(naked) char* __fastcall bnui64toa(unsigned __int64 inum, char* szdst);
__declspec(naked) char* __fastcall bni64toa(__int64 inum, char* szdst);
__declspec(naked) unsigned __int64 __fastcall bnatoui64(char *szsrc);
__declspec(naked) unsigned __int64 __fastcall bnatoi64(char *szsrc);

Comme je disais, un week end bien rempli à écrire en ASM une libc déjà existante et à la tester, QDB pour plaggier Redo.
On a parfois l'impression d'être pris pour un canard sauvage...

A paraitre bientôt sur cppfrance et WinSysDev
ciao...

Publié dimanche 20 novembre 2005 19:15 par brunews
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires

# re: WEEK END BIEN REMPLI, MERCI VS 2005 @ dimanche 20 novembre 2005 23:13

>> Alors on se dit: "Je vais me passer du CRT".

T'es entrain de passer du côté obscur sans t'en rendre compte...Bientôt tu vas troquer ton papillon contre un pinguin, et ta nouvelle femme s'apellera "slash"-truc.

Resaisis-toi, tout ceci ne sert à rien ! 3Ko au lieu de 37 ? Quelle importance ?? A cause de 35Ko t'as passé un weekend de *** !

Stef++

Poppyto

# re: WEEK END BIEN REMPLI, MERCI VS 2005 @ dimanche 20 novembre 2005 23:36

Oui j'ai souvent entendu cela, je serais même arrivé au vb si j'avais écouté. Pourquoi donc se burner en C quand les 3/4 de ce qu'on fait est faisable en interprété, certes plus lent mais faisable.
A cela s'ajoutera que je dois produire ce qui est commandé et que ça correspond bizzarement à "petit et rapide", heureux hasard, non ?

brunews

# re: WEEK END BIEN REMPLI, MERCI VS 2005 @ lundi 21 novembre 2005 00:52

>> Oui j'ai souvent entendu cela, je serais
>> même arrivé au vb si j'avais écouté.

Faut pas pousser quand même, VB c'est une sacré daube niveau performances.

>> Pourquoi donc se burner en C quand les 3/4
>> de ce qu'on fait est faisable en
>> interprété, certes plus lent mais faisable.

Généralement on se sert du C/C++ car les appels aux API sont directs, que ça carbure, et que le code est lisible par le commun des mortels.

>A cela s'ajoutera que je dois produire ce qui
>est commandé et que ça correspond bizzarement
>à "petit et rapide", heureux hasard, non ?

Peut-être qu'il faut savoir lire entre les lignes, je pense que tes clients verront pas la différence si tu leur envoies 3Ko ou 37Ko ? écrit en C ou en ASM ?

Personellement j'ai plus confiance en un codeur C qu'ASM...

Poppyto

# re: WEEK END BIEN REMPLI, MERCI VS 2005 @ lundi 21 novembre 2005 11:23

Je vends le produit et non le code, il n'a donc pas à être lisible par qui que ce soit.
Un client (secteur médical) qui paie (et pas trop mal) pour la performance se rend compte illico si c'est bon ou non, quand un autre viendra avec meilleur il prendra mes contrats et c'est ainsi que je les ai eus. Pour l'heure j'entends les conserver.
La confiance du client est la seule qui m'importe, les considérations sur le "joli code" n'ont jamais assuré mes fins de mois.

BruNews

# re: WEEK END BIEN REMPLI, MERCI VS 2005 @ lundi 21 novembre 2005 17:18

100% d'accord avec toi BruNews, mais se trimballer avec la lib statique et l'include en plus de l'executable je trouve ça emm**dant.

Autant mettre de l'asm inline, non?

Urgo

# re: WEEK END BIEN REMPLI, MERCI VS 2005 @ lundi 21 novembre 2005 18:03

Il est bien clair que l'exe reste autonome, un simple #include "FncAsm.h" suffit pour compiler.

BruNews

# re: WEEK END BIEN REMPLI, MERCI VS 2005 @ lundi 21 novembre 2005 22:46

> Je vends le produit et non le code, il n'a
> donc pas à être lisible par qui que ce soit.

Totalement faux, il doit être lisible par toi. Retourner dans ses sources asm 6 mois plus tard, c'est pas triste ! Même avec des commentaires.

>Un client (secteur médical) qui paie (et pas
>trop mal) pour la performance se rend compte
>illico si c'est bon ou non

Est-ce que c'est vraiment grâce à l'ASM que tu obtient ces performences ? Un bon algo en C, une bonne analyse du problème et hop !

>quand un autre
>viendra avec meilleur il prendra mes contrats
>et c'est ainsi que je les ai eus.
>Pour l'heure j'entends les conserver.
>La confiance du client est la seule qui
>m'importe, les considérations sur le "joli
>code" n'ont jamais assuré mes fins de mois.

Je coinçois que le joli code n'intéresse pas les clients. Mais un code maintenable facilement et rapidement, ça devrait les intéresser ?

En fait je ne vais pas étendre le débat ASM vs C, mais je veux simplement te demander si ce que tu as déjà réalisé en ASM était faisable en C ? si oui, est-ce que tu aurais pu approcher les performances de tes logiciels actuels ? Si t'as fais des comparatifs ça m'intéresse :)

Je m'intéresse au sujet car j'ai le bouquin de John Abrash (cf Quake I) "programamtion graphique en c/c++ et asm" et je t'encourage à le lire ! Tu verras que les performances ne sont pas souvent là où on les attend.

Poppyto

# re: WEEK END BIEN REMPLI, MERCI VS 2005 @ lundi 21 novembre 2005 23:46

C'est Michael Abrash et John Carmack.
Il y a bien longtemps que j'ai lu tout cela, remonte loin dans mes posts sur cppfrance ou asmfr et tu verras que j'en préconisais la lecture.
Chacun continuera comme il l'entend et sera très bien ainsi.

BruNews

# re: WEEK END BIEN REMPLI, MERCI VS 2005 @ mardi 22 novembre 2005 09:54

Erratum c'est bien Michael Abrash ^^.
Ok pas de problème.

Poppyto

# re: WEEK END BIEN REMPLI, MERCI VS 2005 @ mercredi 23 novembre 2005 00:07

Ahh j'aime bien quand ça parle philosophie ! lol. Alors comme ça on ce plainds de vs 2005, j'y crois pas ! Manquerait plus que la mscoree vienne s'infiltrer dans tes exe, c'te sale bete ça vous fait des petits sans qu'on s'en aperçoive ;)

J'aime bien quand tu te met dans cet etat ! On retrouve notre BruNews des grands moment.

Poppyto> Je crois que tu es a 100 000 lieux de connaitres les performances de notre Bruno national, il retrouverais un itoa dans 1Giga de code compilé ! Et comme disais Deep Blue sur son lit de mort : "On apprend pas a BruNews, c'est BruNews qui t'apprends"

:)

EBArtSoft


Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01