[Dekompilacja C++] Skąd tyle rzutowań?

Witam wszystkich!
Ostatnio pobrałem dekompilator o nazwie Snowman (https://derevenets.com/ - link dla zainteresowanych) - być może istnieją lepsze i bardziej zaawansowane, ale już mi się nie chciało szukać.
Moje pytanie odnosi się do jednej rzeczy - czemu w zdekompilowanym kodzie programu tak często występuje ?

Zrzut ekranu - https://drive.google.com/file​/d/0BwLxpuSgHpzsd21xbUJaYnhXbUU​/view

Jakby coś to nie należę do tych, którym trzeba tłumaczyć, że nie odzyskam poprzez dekompilator kodu źródłowego.

W asmie nie ma niejawnych rzutowań, ani typowanych wskaźników.

A czy licencja zezwala na dekompilację tej aplikacji?

@DejaVu W pewnym sensie zezwala... ponieważ to jest mój program :P
@pefkos Że tak to ujmę - raczej się w tych kwestiach nie znam.

Disclaimer: ten post nie stanowi porady prawnej.

A czy licencja zezwala na dekompilację tej aplikacji?

To nie ma żadnego znaczenia, zgodnie z ustawą z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych, jakiekolwiek zapisy w licencji zabraniające dekompilacji są nieważne (art. 76). Warunek jest jedynie taki, by aplikacja była nabyta legalnie, a dekompilacja była dokonywana w celu współdziałania z innymi aplikacjami (art. 75) – pod co można podciągnąć naprawdę wiele rzeczy.

Skąd tyle rzutowań?

To jest cecha specyficzna tego dekompilatora. Widzę nazwy rejestrów, a to oznacza, że sama dekompilacja poszła "tak sobie". Jeśli chcesz to nieco uprościć, to:
1. Sprawdź, czy w wyniku kompilacji tego wszystkiego otrzymujesz coś choć trochę podobnego pod względem binarnym. Jeśli nie, to dekompilator jest za słabo dopasowany do kompilatora.
2. Wyeliminuj powtórzenia. Na screenie widać ich sporo, więc pewnie da się to jakoś uprościć. Nadaj typy zmiennym na podstawie pierwszego użycia i rzutuj tylko, jeśli rzeczywiście typ ulega zmianie.
3. Zapisz wywołania funkcji normalnie, czyli zamiast  będzie coś w stylu , ewentualnie

nie odzyskam poprzez dekompilator kodu źródłowego

Dlaczego nie? Sama dekompilacja jest jak najbardziej możliwa, jednak jakość otrzymanego kodu zależy od tego, na ile nauczysz dekompilator tworzyć taki kod, jaki sam piszesz, na ile dopasujesz go do swojego kompilatora i jego specyficznych cech oraz do jakiego efektu końcowego dążysz. Przy bardziej złożonych programach może to zająć więcej czasu, niż napisanie zamiennika od zera, niemniej jednak to za mało, aby uznać ten proces za niemożliwy (choćby dlatego, że oryginalny kod należy do zbioru rozwiązań, a jeśli dekompilator będzie wystarczająco dobry, to weźmie pod uwagę Twój styl programowania, użyte flagi kompilatora, dostanie słownik z sensownymi nazwami zmiennych i po uwzględnieniu wszystkiego, co tylko się da, wygeneruje odpowiedni kod).

_Dopisano:
Widzę, że po lewej stronie na screenie masz instrukcje w asmie. Możesz również sprawdzić, czy na tym etapie wszystko jest w porządku i przepuścić to przez jakiś kompilator asma (a następnie porównać pliki binarne). A jeśli tutaj są problemy, to dość ciekawą techniką jest "dezasemblacja poprzez emulację", czyli uruchamiasz program na jakimś emulatorze jednocześnie zrzucając instrukcje do jakiegoś pliku (uważaj na pętle - najlepiej od razu upraszczać wszelkie powtórzenia, aby nie mieć gigabajtowych plików - ewentualnie stosować jakąś "kompresję w locie" lub użyć formatu dbającego o odpowiedni poziom entropii; przy okazji możesz się dowiedzieć o różnych dziwactwach, chociażby wykorzystywaniu tych samych kodów operacji kilka razy - to też trzeba jakoś uwzględnić podczas dekompilacji).

@jankowalski25 dzięki za konkretną odpowiedź. Pytanie, które zadałem było raczej typu "A ciekawi mnie dlaczego..." - ani nie tworzę dekompilatora, ani nie mam problemu z zagubionym kodem źródłowym, a na rozgryzanie procesu dekompilacji też trochę dla mnie za wcześnie.