Pokaż wiadomości

Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.


Wiadomości - supron

Strony: [1] 2 3 4 5
1
Windows / WINAPI Dostęp do adresów 32 bitowych z 64 bitowej aplikacji
« dnia: Grudzień 01, 2014, 13:40:59 »
Witam.

Piszę program monitorujący działanie drugiej aplikacji poprzez wczepianie się api windowsowe i odczyt argumentów/zwrotów (robię proste hooki w assemblerze). Ten mechanizm działa bardzo dobrze gdy program "monitor" i program monitorowany, są 32 bitowe. Problem pojawia się gdy z poziomu 64 bitowego monitora chcę znaleźć adresy w aplikacji 32 bitowej. Gdy obie aplikacje były 32 bitowe, adresy kernel32.dll pokrywały się więc wystarczył GetProcAddress w monitorze by zawsze pasowało do aplikacji monitorowanej. Metoda "brudna" i kompletnie bezużyteczna w 64 bitach. Dlatego zastanawiam się czy istnieje jakieś API windowsowe do tego typu zadań.

3 dni siedzenia na MSDNie pozwoliły mi wczytać listę modułów 32 bitowych z 32 bitowego procesu, więc wiem gdzie znajdują się systemowe dllki w pamięci. Nie wiem natomiast jak na tej podstawie łatwo odczytać adresy eksportowanych funkcji. Do głowy przyszła mi pewna metoda, by wczytać przez ReadProcessMemory cały nagłówek z pamięci i zdekodować export table, ale czy to dobre podejście i czy da dobre wyniki? Poza tym wolałbym coś prostszego i bardziej wysokopoziomowego.

Pozdrawiam.

2
C++ / Odp: Wspólny typ wskaźnika na metody różnych klas.
« dnia: Sierpień 25, 2012, 17:43:20 »
@hashedone, bezpieczeństwo rzutowania w tym wypadku nie gra roli, bo sama potrzeba jest bardzo niskopoziomowa i chodzi mi tylko o adresowanie metod, nie potrzebuję znać ich typów, ani obiektów które korzystają. Zazwyczaj wszystko idzie bez optymalizacji w tych fragmentach kodu dzięki temu zawsze dla 32 bitów pod visualem obiekt idzie w rejestrze ECX, a sam adres metody też zawsze na końcu przy CALL'u będzie 32 bitowy.

Wskaźników na funkcje składowe nie można castować do void* bo się w nim po prostu w pewnym przypadkach nie zmieszczą. Potrzebne jest dodatkowe miejsce do obsługi offsetów przy wielodziedziczeniu.

Przykład: http://ideone.com/4ncBS

Przy czym wyniki są zależne od kompilatora. GCC daje [4, 8, 8]. Visual daje [4, 4, 12].
Problemem jest to, że z mojego punktu widzenia dziedziczenie nie gra roli. Liczy się sam adres konkretnej metody z konkretnej klasy, niezależnie od typu obiektu, dlatego że ręcznie podaję która metoda z której klasy mnie interesuje. Ostateczny adres metody pobrany przez CClass::Method() powinien być z góry znany bo koniec końców i tak idzie call do adresu 32 bitowego, do konkretnej metody konkretnej klasy, dlatego trochę nie rozumiem czemu kompilator nie dopuszcza takich zabiegów. Byłoby to uzasadnione tylko w przypadku chęci uzyskania adresu poprzez coś w stylu ptr = obj->method;

3
C++ / Odp: Wspólny typ wskaźnika na metody różnych klas.
« dnia: Sierpień 24, 2012, 22:50:30 »
Kod: (c++) [Zaznacz]
class CClass{
public: 
void foo2() {}
};

void (CClass::* p)() = &CClass::foo2;
void* ptr2 = *reinterpret_cast<void**>(&p);
Ale po co Ci to??
Dzięki wielkie, działa :D.

Potrzebne jest mi to, ponieważ bawię się w szyfrowanie funkcji, pisanie prostych VM'ów i ogólnie poszerzam wiedzę z zakresu zabezpieczeń aplikacji i mam kilka funkcji pomocniczych, które potem pomagają mi w debuggowaniu a któe porzebują znać wskaźniki na funkcje i metody.

4
C++ / Odp: Wspólny typ wskaźnika na różne klasy.
« dnia: Sierpień 24, 2012, 22:28:21 »
error C2440: 'reinterpret_cast' : cannot convert from 'void (__thiscall CFoo::* )(void)' to 'LPVOID'
1>          There is no context in which this conversion is possible

5
C++ / Wspólny typ wskaźnika na metody różnych klas.
« dnia: Sierpień 24, 2012, 22:22:30 »
Tworzę aplikację korzystającą z zalet programowania obiektowego, ale potrzebuję też wykonać kilka rzeczy niskopoziomowych. Mam problem z typem dla wskaźnika na metodę klasy. W przypadku zwykłych funkcji wystarczy void*, jednak zastosowanie takiego wskaźnika dla metody powoduje błąd.

void foo1();
class CClass{
    void foo2();
};

LPVOID ptr1 = foo1;               // dziala
LPVOID ptr2 = CClass::foo2; // nie dziala

Na razie poradziłem sobie w jednym przypadku wstawką assemblerową:
MOV EAX, CClass::foo2;
MOV ptr2, EAX;
Ale takie rozwiązanie jest bardzo niewygodne, nieestetyczne i może powodować duże problemy w działaniu (kompilator nie lubi jak się grzebie w rejestrach przy włączonej optymalizacji).

Próbowałem różnego typu rzutowania, ale wszystko skutkuje wyrzucaniem błędów. Czy zna ktoś sposób na użycie jednego typu wskaźnika dla dowolnej klasy bez zbędnego dziedziczenia z jednej klasy bazowej?

6
Projekty zaawansowane / Odp: FUGE - GUI do twojej gry
« dnia: Czerwiec 24, 2011, 12:50:08 »
  • wbudowany renderer OpenGL
Za to wielki browar się należy. Szukałem jakiegoś ciekawego GUI do mojego edytora map i chyba znalazłem (do tej pory korzystałem z własnego, ale za dużo czasu poświęcałem na rozwój samego gui zamiast edytora). Czekałem tylko na render opengl'a.

7
Szkółka / Odp: Ogre 3D - gdzie glowna petla
« dnia: Wrzesień 25, 2010, 16:40:47 »
tak ale zobacz jego kod a moj
http://wklej.org/id/393004/

i gdzie ta petla jest :(
Nie za głęboko dla Ciebie? Może zacznij od czegoś prostszego. Jak ktoś zna dobrze C++ to kod z C# powinien rozumieć przynajmniej w takim stopniu by zrozumieć istotę jego działania.

8
Szkółka / Odp: Ilość FPS w 'czystym' projekcie :)
« dnia: Wrzesień 10, 2010, 09:03:32 »
1600 * 1200 = 1920000
5120 * 3840 = 19660800

192000 / 19660800 = 10,24


zdaje się, że magia polegała na patrzeniu 'nie powierzchniowo' ;-)
Oczywiście. Tak naprawdę nie ma aż takiej wielkiej różnicy pomiędzy aparatem 3 a 6 mpix.
Pewnie że nie. Tak samo jak nie będzie dużej różnicy między rozdzielczością 640x480, a 647x485, a przetworzyć trzeba będzie o 6595 pixeli więcej (to bardziej działa na wyobraźnię). Swoją drogą temat sprowadza się do tego, że najlepiej używać dwóch liczników (fps i dt). Dyskusja co lepsze jest raczej bezsensowna.

9
Matematyka i fizyka / Odp: OpenGL Mathematics (GLM) - co o tym sądzicie?
« dnia: Sierpień 27, 2010, 02:45:03 »
glm jest bardzo spoko i od kiedy go używam przestałem implementować samemu klasy wektorów/macierzy/itd
fajnie się korzysta ze swizzlowania (np. vec3 wektror; wektor = wektor.zyx;)
zgadzam się że dużo headerów, ale ich dołączenie to jednorazowy koszt i można sobie wybrać to, co jest potrzebne.
Gorzej jak zechcesz do tego zajrzeć. Powiedzmy sobie szczerze - nic nie rozwieje wątpliwości lepiej niż zerknięcie w kod/nagłówki. W przypadku GLM, to droga przez mękę.

10
Matematyka i fizyka / Odp: OpenGL Mathematics (GLM) - co o tym sądzicie?
« dnia: Sierpień 26, 2010, 21:23:08 »
U mnie wnioski takie same jak u Dabroza, pełno nagłówków, ciężko się szuka rzeczy których się nie kojarzy z GLSLa. Jak dla mnie cml trochę przyjemniejszy - http://cmldev.net/?page_id=11
Dokładnie. Organizacja cml'a jest nieporównywalnie lepsza. GLM byłem z początku zachwycony z racji bardzo zbliżonej składni do glsl, jednak przy poważniejszym projekcie we znaki daje się fatalna organizacja - masa nagłówków, wszystko porozrzucane, ogólnie przerost formy nad treścią.

11
Szkółka / Odp: DX vs. OGL w dość specyficznych zastosowaniach.
« dnia: Sierpień 24, 2010, 15:35:33 »
ee, ale ogl ma bufory wierzcholkow
Jeżeli chodzi ci o te obiekty buforów (VBO) które zostały wprowadzone w OpenGL 1.5 to niestety (tablice są od 1.1 (chyba) więc jeszcze się zaliczają):
A kto pamięta o tak archaicznym openglu. To tak jakbyś chciał pisać w DX 7/8. 4 lata temu myślę że to 1.5 spokojnie się kwalifikuje. Poza tym jak karta nie obsługuje buforów to ani DX ani GL tego nie obsłuży.

Do takiego projektu to nada się i jedno i drugie api. Zadaj sobie pytanie czy chcesz pisać tylko pod windowsa czy chcesz aby program odpalił się też na innych systemach. Jeśli tylko windows to wybierz api które wydaje Ci się bardziej przyjazne, jeśli pod inne systemy też to zostaje tylko opengl. Jak nie wiesz nadal to zrób wyliczankę.

12
Allegro / Odp: Edytor i siatka
« dnia: Sierpień 17, 2010, 15:21:45 »

XD
Co tam pisze w lewym górnym rogu  ??? ???

13
Szkółka / Odp: [OpenGL] Czy warto uczyć się jeszcze "starego" opengl?
« dnia: Sierpień 06, 2010, 12:40:19 »
Jeżeli ktoś chce dobrze zrozumieć działanie OpenGL to wiedza o tym jak robiło się pewne rzeczy "onegdaj" z pewnością mu nie zaszkodzi. Rozumiejąc rozmaite mechanizmy związane z programowaniem grafiki można uzyskać dobre efekty niezależnie od tego czy mamy pod ręka fixed pipeline czy shadery. Ale inna sprawa że jak komuś zależy na wiedzy w tym czy innym zakresie to po prostu bierze się do roboty, a nie łazi po forach z pytaniem czego się uczyć, skąd się uczyć, po co się uczyć i tak dalej...
Pod warunkiem że nie przejmie złych nawyków.
Cytuj
Świru, ty się znasz Smiley Skąd się uczyć tego "nowego" OpenGL (poza dokumentacją). Podstaw itp. Jakiś tutorial, książka?
Trochę już się tego w googlach pojawiło ostatnimi czasy. Podstawy wystarczą. Byle zainicjować, zaaplikować vbo i shadery - dalej to już i tak tylko dokumentacja, matematyka i czysty kod zostaje niezależnie od tego czy robi na 2.x czy 3.x.

Z resztą to trochę tak jakby odradzać naukę DX10 z powodu wymogów. Te karty już są niemal w każdym komputerze, a idąc tym tropem że należy myśleć o starych komputerach to chyba nikt by nie kupował nowych kart.

14
Sieć i multiplayer / Odp: Aktualizacja plików zewnętrznych gry
« dnia: Sierpień 03, 2010, 20:16:47 »
No u siebie w aktualizacji programu autoryzowanego przez www używałem tego 3 sposobu. Dokładniej działało to tak:

1. Launcher łączy się z serwerem.
(Tu była autoryzacja programu więc to pominę)
2. Wysyła aktualną wersję.

(po stronie serwera)
3. Serwer sprawdza numer najnowszego patcha
4. Wybiera wszystkie pliki od najnowszego patcha aż do wersji o 1 wyżej od łączącego się klienta.
5. Sporządza listę plików do aktualizacji i wysyła (wersja, nazwa pliku, md5 - md5 po to gdyby w razie przerwania aktualizacji dużym patchem nie trzeba było wszystkiego ciągnąć od nowa).
6. Klient sprawdza md5, tworzy własną listę plików które realnie musi uzupełnić (żeby właśnie nie aktualizować 2 razy tego samego pliku przy zerwaniu połączenia). Listę tworzy w taki sposób że serwer wysyła wraz z plikami adres aktualnego serwera ftp (w razie zmian i taka ewentualność została przewidziana :D), a klient tworzy ich adresy mniej więcej tak ftp://host/autoupdate/wersja/plik/.
7. Na samym końcu gdy ściągnie i skopiuje pliki, zmienia wersję tak żeby nigdzie błędów nie było.

Zagmatwane ale działa bardzo szybko (szczególnie sama aktualizacja). Pakiety idące między klientem a serwerem są małe i w sumie idą tylko 2.

15
Sieć i multiplayer / Odp: Aktualizacja plików zewnętrznych gry
« dnia: Sierpień 03, 2010, 14:51:03 »
Sprawdzanie md5 każdego pliku to strata czasu trochę. Zamiast tego lepiej zrobić jakieś oznaczenia wersji aktualnej gry i sprawdzanie czy wyszła nowa. Jeśli tak to się aktualizuje. Problemem pojawia się gdy gracz będzie miał wersję starszą a wyjdą 2 nowe patche jeden po drugim. Rozwiązać to można na 3 sposoby:
1. Ściąganie każdego po kolei - wydaje się dobre, ale jeśli aktualizujemy w kilku kolejnych patchach ten sam plik to niepotrzebnie ściągamy go kilka razy. Nie jest to co prawda duża strata ale jednak.
2. Zawieranie starego patcha w nowym - najgorsze rozwiązanie moim zdaniem. Zaleta jest taka że ściągamy tylko ostatni patch, ale wraz z kolejnym rośnie zdecydowanie jego waga i ściągać musimy też starsze pliki które już posiadamy. To jest dobre rozwiązanie jeśli prawie nie dokłada się nowych plików a jedynie modyfikuje stare.
3. Ściągnięcie tylko najnowszych i brakujących - najlepsze rozwiązanie chyba. Można to rozwiązać zarówno po stronie serwerowej jak i w użytkownika. W tym pierwszym wypadku serwer na podstawie analizuje które pliki należy wysłać. W drugim ściągamy listy plików z każdego patcha, analizujemy je i ściągamy najnowsze oraz brakujące. Pliki można sprawdzać po md5 np.

Pliki zawsze najlepiej trzymać na hostach www. Serwerów dedykowanych jeśli nie mają super łącza lepiej nie przeciążać bo to doprowadzi do lagów w grze.
AKTUALIZUJ NAJLEPIEJ LAUNCHEREM PRZED URUCHOMIENIEM GRY - odpada wiele problemów. Do tego w serwerze umieść system który uniemożliwi wejście na starej wersji.
Cytuj
To co za problem co tydzień wydawać patch.
Zmuś gracza żeby co tydzień ściągał patch do gry. A niech pojawi się błąd w grze który trzeba szybko załatać.

Cytuj
Pomysł nr.1: pobieramy plik "files.dat", w nim jest "tabelka" nazwapliku - md5tegożpliku, sprawdzamy czy pliki istnieją i mają dobre md5, odpowiedni pobieramy je z serwera.
files.dat musiałby zwierać bazę wszystkich poprzednich aktualizacji, a sprawdzanie wszystkich plików przy dużej grze zabije jej uruchomienie (sprawdzaj 5k plików ^^).

Strony: [1] 2 3 4 5