Autor Wątek: Jaki komunikat (zdarzenie) podczas killowania aplikacji?  (Przeczytany 7877 razy)

Offline Xender

  • Użytkownik

# Grudzień 12, 2011, 19:24:15
@up niezła zlewa z twojego posta xD

1. Przechwycenie ALT-CTRL-DEL wymaga zmodyfikowania kodu kernela, czyli wprowadzenia własnego sterownika.
2. "Przerwanie zamykania systemu" - LOL
3. "Wstawienie przerwania" o_O
4. Zabawy w modyfikowanie przerwań to pod DOSem lub innym 16-bitowym systemem. W 32-bit Protected Mode - znowu wymaga modułu kernela (sterownika).
5. Non-stop rejestrowanie nowych okien - Ach, przypomniało mi się sortowanie przez ListBox...
6. To samo z wysyłaniem danych do serwera co sekundę. Podejście na około i niemożliwe do wykonania (ewentualnie skrajnie nieefektywne).

Nie wiem czego uczyli/uczą cię na studiach, ale chyba spałeś na ogromnej większości wykładów.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline micran

  • Użytkownik
    • Micran - Warsztat

# Grudzień 12, 2011, 19:56:24
olo16 Nie pomagasz autorowi, spam narobiłeś. A ty widzę sam masz ogromne braki, widzę nie miałeś takiego przedmiotu jak systemy operacyjne, ale wybaczam ci twoja głupotę. Nieefektywne wysyłanie co jakiś czas jednego bita informacji? Kpisz ? bo inaczej tego nie da się zinterpretować, po za tym skoro autor ma komunikacje z serwerem to i tak sie z nim czesciej kontaktuje.
Ciekaw jestem gdzie Ci wprowadzili takie ograniczenia myślowe? Pomyśl trochę, jest tyle wirusów które potrafią wychwycić każdy klawisz a tu nagle nie można ?! :D
Punkt nr 2 : Skąd ty masz przerwania zamykania systemu ? Nigdzie takiego szyku nie użyłem, następnym razem lepiej musisz trolować :D
Wstawienie przerwania = podstawienie pod adres przerwania swojej procedury, poczytaj "DOS 5.0", windows ma to do siebie, że powstał na dosie i działają te same przerwania.
Chyba niezbyt ogarniałeś na studiach skoro wszedzie widzisz kernel, czyzby zapalony Linuxowiec który kompiluje sobie jądra?
5. To tylko przykład ze da się każdy problem z różnych stron rozwiazać.

Na wykładach to się można nauczyć tyle co nic, nawet na politechnice na której jestem, bo wykłady to nie praktyka!

P.S. Miałem lepszą zlewę z twojego trollowania.

Offline izaw

  • Użytkownik

# Grudzień 12, 2011, 20:13:28
@micran

A nie wiesz, że przez sieć nie przesyłasz bitów, tylko pakiety? Zresztą w komputerze też nigdzie nie możesz przesłać pojedynczego bita.

DOS i Windows to dwa różne systemy. No chyba, że zatrzymałeś się na 98, a i tam dostęp do przerwań był zabroniony.

Lepiej już zamilknij, bo się ośmieszasz.

Offline Rolek

  • Użytkownik

# Grudzień 12, 2011, 20:26:39
Nieefektywne wysyłanie co jakiś czas jednego bita informacji?
Tak. Oprócz samych danych pakiety sieciowe składają się z nagłówków. Timeouty powinny być dłuższe niż 1 sekunda, a komunikaty typu keep-alive powinny być wysyłane tylko wtedy gdy nie masz do wysłania żadnego innego.

Pomyśl trochę, jest tyle wirusów które potrafią wychwycić każdy klawisz a tu nagle nie można ?! :D
Wszystko można, ale tego typu metody mają to do siebie, że działają zwykle tylko i wyłącznie z jedną wersją systemu. A użytkownik raczej nie będzie zadowolony gdy mu niechcący zdestabilizujesz system :P

Wstawienie przerwania = podstawienie pod adres przerwania swojej procedury, poczytaj "DOS 5.0", windows ma to do siebie, że powstał na dosie i działają te same przerwania.
Windows NT (2000, XP, Vista, 7) ma to do siebie, że nie opiera się na DOSie i poza NTVDM przerwania DOSowe nie działają.

Chyba niezbyt ogarniałeś na studiach skoro wszedzie widzisz kernel, czyzby zapalony Linuxowiec który kompiluje sobie jądra?
Zmartwię cię, ale Windows (i każdy system operacyjny) też posiada kernel. Coś nie uważałeś na systemach operacyjnych.
« Ostatnia zmiana: Grudzień 12, 2011, 20:36:39 wysłana przez Rolek »

Offline Xender

  • Użytkownik

# Grudzień 12, 2011, 20:28:26
@micran - widzę, że bardzo poruszyło cię to, że wyśmiałem twój post. Nie miałem zamiaru cię obrazić, a jedynie zdementować błędne informacje.
Nieefektywne wysyłanie co jakiś czas jednego bita informacji? Kpisz ? bo inaczej tego nie da się zinterpretować, po za tym skoro autor ma komunikacje z serwerem to i tak sie z nim czesciej kontaktuje.
Timer nic nie pomoże, bo w momencie zamykania aplikacji muszę dać znać do serwera, że jej działanie się kończy i ustawić w nim pewne flagi. Czyli mogę to zrobić wyłącznie w momencie, kiedy rozpoznam, że aplikacja jest zamykana.
Czyli nawet nie nieefektywne, a niemożliwe.
Pomyśl trochę, jest tyle wirusów które potrafią wychwycić każdy klawisz a tu nagle nie można ?! :D
Ależ można. Tylko że większość z tych wirusów korzysta z hooków na klawiaturę, które nie mają możliwości przechwycenia kombinacji takich jak ALT-CTRL-DEL. Kombinacja ALT-CTRL-DEL pod windowsem jest obsługiwana prze system operacyjny i nie dochodzi do żadnej aplikacji. Nie jest także możliwe jej przechwycenie bez modyfikowania kodu jądra. A aby to zrobić, trzeba mieć sterownik lub rootkita. Niezbyt dobry pomysł żeby używać tego drugiego w aplikacji użytkowej, a sterownik to overkill i też sporo problemów.
Punkt nr 2 : Skąd ty masz przerwania zamykania systemu ? Nigdzie takiego szyku nie użyłem, następnym razem lepiej musisz trolować :D
Jest też inny sposób przechwycisz w asemblerze przerwanie odpowiedzialne za zamykanie programu
Masz rację, programu nie systemu. Co nie zmienia faktu, że takie przerwanie nie istnieje. Zamykanie aplikacji jest procesem całkowicie programowym, zabicie procesu też. Nie występują w nim żadne przerwania.
Wstawienie przerwania = podstawienie pod adres przerwania swojej procedury, poczytaj "DOS 5.0", windows ma to do siebie, że powstał na dosie i działają te same przerwania.
I tu się mylisz, DoS jest systemem 16-bitowym, natomiast windows działa w 32 (lub 64) bitach w trybie chronionym. Tryb chroniony oznacza, że istnieje podział na kernel-mode i user-mode. Kod wykonywany w kernelmode moze wszystko, kod wykonywany w usermode nie może komunikować się z urządzeniami ani zarządzać pamięcią fizyczną (a jedynie przydzieloną mu pamięcią wirtualną). W trybie 16-bitowym adresy procedur obsługi przerwać są umieszczone w IVT, natomiast w trybie 32-bitowym i IDT. Są to zupełnie różne struktury danych, a każdy sensowny system operacyjny umieszcza IDT w obszarze dostępnym tylko kernelowi.
5. To tylko przykład ze da się każdy problem z różnych stron rozwiazać.
Tworzenie nowych okien cały czas to przykład bardzo złego rozwiązania. Po pierwsze, jego praca byłaby bardzo niestabilna, bo w momencie gdy odkryjesz że system nie utworzył ci okna nawet nie wiesz ile zostało ci czasu. A po drugie to ciągłe obciążanie systemu. Wreszcie, to idealny przykład znajdowania drogi dookoła problemu.

Pozwoliłem odpowiedzieć sobie tylko na kwestie techniczne. Wycieczki osobiste i inne niezwiązane kwestie pozostawiam bez komentarza. Jeśli masz jakąś kwestię techniczną pisz tutaj, jeśli inną to zapraszam na PW.

Offline hashedone

  • Użytkownik

# Grudzień 12, 2011, 21:10:11
Nie występują w nim żadne przerwania.I tu się mylisz, DoS jest systemem 16-bitowym, natomiast windows działa w 32 (lub 64) bitach w trybie chronionym.
Oj, teraz to ty kłamiesz w żywe oczy. DoS (ang. Denial of Service) jest prostym (co nie znaczy że nieskutecznym) atakiem na węzeł sieciowy polegający na wysłaniu większej ilości pakietów niż ten jest w stanie ich przetworzyć (a więc zwykłe przeciążenie łącza). Chociaż jeśli by założyć że niedotrzymałeś Shifta na 'o' to można potraktować to jaki literówkę;)

Apropo tematu - micran, po co się wypowiadasz jak nie słuchałeś na wykładach tylko pisałeś proste programiki w pascalu pod DOSa? Windows != DOS. Nawet Windows 9x != DOS, choćby dla tego, że Windows 9x pracuje w trybie chronionym. Windows NT to już zupełnie inna bajka. Jeśli chodzi o związek DOSa z Windowsem to skończyła się ona na serii Windows 3.x, która faktycznie była graficzną nakładką na DOS. I tak żebyś był świadomy - nie, to co się pokazuje po wpisaniu "cmd" w pole "Uruchom" nie jest okienkiem DOSa.

Offline Furry

  • Użytkownik
    • DevBlog

# Grudzień 12, 2011, 21:14:11
Wkleiłem dokładnie kod z wcześniej zacytowanej strony MSDN Microsoftu, ale żadne okno z pytaniem o zamknięcie programu nie pojawiło się. Już prawdę mówiąc nie wiem, co tam może być nie tak...
Hmm to może zrób tak: zrób standardową aplikację ze zwykłym okienkiem itp i sprawdź czy wtedy ci reaguje. Jak będzie reagować to powoli przechodź do stanu okna twojej aplikacji. Wtedy się zorientujesz co w kodzie masz źle.

Offline Rolek

  • Użytkownik

# Grudzień 12, 2011, 22:03:43
<ot>
Oj, teraz to ty kłamiesz w żywe oczy. DoS (ang. Denial of Service) jest prostym (co nie znaczy że nieskutecznym) atakiem na węzeł sieciowy polegający na wysłaniu większej ilości pakietów niż ten jest w stanie ich przetworzyć (a więc zwykłe przeciążenie łącza).
Oj, teraz to ty kłamiesz w żywe oczy. DoS (ang. Denial of Service, czyli Odmowa Usługi) polega na doprowadzeniu do sytuacji gdy usługa nie będzie mogła obsługiwać nowych klientów. Przeciążenie serwera lub zawalenie łącza ogromną iloscią danych lub żądań jest tylko jedną z metod, równie dobrze można wysłać tylko jeden odpowiednio spreparowany pakiet, który spowoduje crash serwera :P
</ot>

Offline Yazilim

  • Użytkownik

# Grudzień 13, 2011, 17:22:22
P.S. A po co ci flagi w serwerze, jesli aplikacja sie komunikuje z nim, to nie lepiej wysyłać co 1 sekunde jakaś daną do serwera, a gdy serwer nie otrzyma tej danej przez 2-3 sekundy, automatycznie się przestawi ?
Dzięki za wskazówki - też myślałem o oknie, które będzie miało "dziwne" współrzędne poza ekranem. Może w tym przypadku da się wychwycić komunikat kończenia sesji. Co do komunikacji z serwerem, to niestety nie jest to takie proste - nie mogę co sekundę się z nim komunikować, bo odpowiedź serwera może czasem być długa i mogłoby to przywiesić aplikację. Ale można by robić to rzadziej, choć tak czy siak komplikuje to kod, bo serwer musi śledzić każdego nowo pojawiającego się klienta.

Offline Yazilim

  • Użytkownik

# Grudzień 13, 2011, 17:25:45
Hmm to może zrób tak: zrób standardową aplikację ze zwykłym okienkiem itp i sprawdź czy wtedy ci reaguje.
Dzięki - tak właśnie zrobię. Potem ewentualnie zmienię współrzędne na jakieś leżące daleko poza ekranem, jak sugerował micran.

Offline micran

  • Użytkownik
    • Micran - Warsztat

# Grudzień 13, 2011, 18:03:44
Do osób piszących do mnie : Spoko, tylko to jest forum - miejsce pomocy a nie miejsce na przepychanki i mówienie komuś że się myli bez wprowadzania poprawnych informacji. Loozik :D
--------------------------------------------------------------------------
Hmm.. a w czym to piszesz, WinAPI czy jakieś inne opcje ?
Możesz być też chamski dla użytkownika i na czas trwania aplikacji ustawić mu w rejestrze aby nie mógł wyłączyć systemu windows.
Pewnie nie ratuje cię sytuacja, ze połączenia sieciowe są jako jedne z pierwszych zamykane, można by wtedy jedynie cos na szybko zapamietać w pliku, a później wysłać.
Opisz zasadę działania twego programu, może ktoś ci pokaże, że jednak da się to obejść jeszcze inaczej. Można podpiąć się pod proces (w sensie śledzić czy jest on uruchomiony np. explorer.exe) użytkownika i jeśli on zginie szybko reagować, ale pewny nie jestem czy takie cos by podziałało.
Co do danych wysyłanych na serwer, to niekoniecznie potrzebujesz odpowiedzi serwera.
Moje pomysły się skończyły, chyba że opiszesz zasadę wtedy się pomyśli.

Offline MaxGarden

  • Użytkownik
    • Profil na warsztacie

# Grudzień 13, 2011, 18:11:18
Ja bym zrobił to inaczej, serwer co parę sec/min wysyła do klienta pusty pakiet, jeżeli klient jest on-line to odsyła te flagi co chciałeś (ale serwer ich nie używa, tylko gdzieś zapisuje). W momencie, gdy serwer wykryje, że klient jest off-line ustawia flagi, które odebrał wcześniej. Jeżeli wszystko dobrze obmyślisz, to powinno zadziałać ;].

Offline Yazilim

  • Użytkownik

# Grudzień 13, 2011, 19:00:36
Sytuacja opanowana. Zrobiłem najprostszy projekt Win32 wyświetlający tylko okno i nic więcej. W kodzie procedury okna zawarłem case z WM_QUERYENDSESSION. Okazało się, że mogę ten komunikat przechwytywać. No więc w moim oryginalnym projekcie zakomentowałem wiersz, który wydawał mi się powodem powstania problemów: ::SetParent(hWnd, HWND_MESSAGE). Okazuje się, że trafiłem w 10-tkę. Bez tego wiersza moja aplikacja zaczęła również przechwytywać WM_QUERYENDSESSION. Zmieniłem więc drugi wiersz SW_SHOW na SW_HIDE w wywołaniu ShowWindow i teraz mam obsługę komunikatu, a okna nie widzę - co jest oczekiwanym rezultatem :)

Wniosek: stworzenie "message-only window" (za pomocą odpowiedniego wywołania SetParent) jest fajne, ale okazuje się, że tracimy w tym przypadku możliwość przechwytywania komunikatów WM_QUERYENDSESSION (a może i innych też).

Żeby ostatecznie wyjaśnić sprawę, w dokumentacji Microsoftu znalazłem coś takiego: "A message-only window enables you to send and receive messages. It is not visible, has no z-order, cannot be enumerated, and does not receive broadcast messages. The window simply dispatches messages.". Wygląda na to, że WM_QUERYENDSESSION jest "broadcast message", bo jest wysyłane do wszystkich okien w danej sesji. Wszystko się zgadza :)

Offline Rolek

  • Użytkownik

# Grudzień 13, 2011, 20:07:26
Trochę na około to okienko robiłeś. Mogłeś od razu dać rodzica na HWND_MESSAGE zamiast potem ustawiać. Po co dawałeś ShowWindow na SW_SHOW skoro chciałeś by było niewidzialne? Okienka standardowo są niewidzialne, chyba że dasz WS_VISIBLE.

micran, nadajesz się na programistę biznesowego, gdzie programy mogą mieć różne dziwne wymagania wobec środowiska, w którym pracują, zwykli użytkownicy raczej nie są zadowoleni gdy programy robią dziwne rzeczy z ich komputerami.

Offline Yazilim

  • Użytkownik

# Grudzień 13, 2011, 21:15:39
Gdzieś po prostu znalazłem przepis na tworzenie programu wyłącznie z ikonką w tray'u - wykorzystywano tam właśnie "message-only window" tworzone przez  SetParent z parametrem HWND_MESSAGE. Potem było też SW_SHOW. Aplikacja działała OK, ale w przypadku przechwycenia WM_QUERYENDSESSION akurat się nie sprawdziła..