Kopiuj-i-wklej kod

Gdy znajdziemy w sieci kawałek kodu, który chcemy przeanalizować, to nie zawsze jest on ładnie sformatowany czy pokolorowany. Wtedy możemy sobie pomóc, wklejając rzeczony kod do naszego środowiska programistycznego; w większości znajdzie się opcja pozwalająca np. wyrównać wcięcia (w Visual Studio jest to Edit | Advanced | Format Selection), że o kolorowaniu nie wspomnę ;]

O powyższym wiedzą pewnie wszyscy. Jednak czasami kopiujemy też kod w drugą stronę, z IDE. Jeśli korzystamy z Visual Studio, to możemy wykorzystać przy okazji fakt, że jest on kopiowany jako… tekst formatowany typu RTF.
Na pierwszy rzut oka może to wydawać się co najmniej dziwne. Przecież kod z założenia jest zwykłym tekstem, więc po co dodatkowe informacje o czcionkach czy wyglądzie znaków?… Otóż odpowiedź jest bardzo prosta: w ten sposób zachowana jest bowiem informacja o kolorowaniu składni. Jeśli teraz wkleimy nasz kod do dowolnego edytora tekstu formatowanego (czyli od WordPada wzwyż), to zobaczymy z słowami kluczowymi i innymi elementami zakolorowanych dokładnie w ten sam sposób, jak w środowisku programistycznym.

Do szczęścia brakowało by pewnie jest możliwości szybkiej konwersji takiego kodu do formatu HTML… ale cóż, nie można mieć wszystkiego ;-)

Find & Replace i wyrażenia regularne

Przy wyszukiwaniu czegoś w kodzie czasami przydają się wyrażenia regularne. Pozwalają one na znajdowanie nie tyle dokładnie określonych ciągów znaków, ale ciągów pasujących do określonego wzorca. Przy odrobinie wprawy można na przykład wyszukać wszystkie deklaracje zmiennych danego typu, wszystkie wywołania funkcji przeciążonej wyłącznie w wersji z trzema parametrami, i tak dalej.

Zwykle takich rzeczy szukamy jednak nie dla samego znajdowania, lecz po to, aby je potem zmodyfikować. Czasem można to zrobić ręcznie, ale jeśli oznacza to konieczność wykonania tych samych poprawek kilkanaście czy kilkadziesiąt razy, to szybko może nam to się znudzić. Pamiętajmy zresztą, że każdy programista dysponuje tylko skończonym czasem przeznaczonym na kodowanie :)
Wtedy może przydać się zastosowanie wyrażeń regularnych nie tylko do wyszukiwania (find), ale też do zastępowania (replace). Każde porządne IDE powinno bowiem oferować możliwość dopasowywania podwyrażeń (subexpressions lub tagged expressions) w znajdowanym ciągu. Nie inaczej jest w Visual Studio.

Załóżmy przykładowo, że piszemy w C++ i mamy klasę działającą jak abstrakcyjny interfejs (wszystkie metody czysto wirtualne) i chcemy go zaimplementować. Kopiujemy więc całą definicję klasy i chcielibyśmy teraz zmienić deklaracje jej metod: ze wszystkich usunąć słówko 'virtual' i frazę '= 0'.
Jak to zrobić? Dość łatwo skonstruować wyrażenie regularne, które wyszuka nam wszystkie deklaracje:

Co jednak z polem Replace with? Tam chcielibyśmy wstawić wszystkie te znaki, które dopasują się do wyrażenia .*. W tym celu powinniśmy wpierw zmienić tę frazę na tagged expression, otaczając ją nawiasami klamrowymi:

Teraz stało się ono podwyrażeniem i możemy odwołać się do dopasowanych do niego znaków poprzez sekwencję \1. Zatem jako wyrażenie docelowe wstawimy po prostu:

Jak nietrudno się domyślić, podwyrażeń może być więcej; możemy wtedy odwoływać się do nich za pomocą kolejnych numerków: \2, \3, itd. (są one numerowane oczywiście od lewej). Dodatkowo symbol \0 odpowiada za cały znaleziony ciąg.
Widać więc, że przy użyciu tego mechanizmu można automatycznie dokonywać zmian, które bez niego zajęłyby nam dużo czasu i były dość żmudne.

Rootkity i inne nieszczęścia

Jedną z rzeczy, którą musiałem wykonać w trakcie (tymczasowej) przesiadki na komputer stacjonarny, było dogłębne sprawdzenie go programem antywirusowym - co "z pewnych względów" nie było czynione przez dobrych kilka miesięcy :) Skan nie wykrył aczkolwiek w zasadzie nic bardziej niebezpiecznego niż typowe 'śledzące ciasteczka' (tracking cookie). Dopiero później zaczęło się robić ciekawie.
Zło (i to przez duże Z) zostało bowiem wkrótce wykryte przez skaner działający w tle, który zidentyfikował je heurystycznie jako rootkit i oprócz tej informacji nie powiedział zresztą nic więcej. Przyznam, że było to moje pierwsze zetknięcie z tego typu szkodnikami, więc tym bardziej energicznie zabrałem się do rozwiązywania problemu - zwłaszcza że ze wszystkich typów złośliwego oprogramowania to właśnie rootkity sa zdecydowanie najgroźniejsze.
Na szczęście ten okazał się dość znanym i nawet nieszczególnie niebezpiecznym drobnoustrojem, przenoszącym się - o dziwo - nie przez sieć, lecz przez dyski wymienne. Zapewne dlatego też moje kilkugodzinne starcie z przeciwnikiem zakończyło się (prawdopodobnie) sukcesem, zaś wnioski z tego są następujące:

• Antywirusy nie radzą sobie z rootkitami i zwykle potrafią jedynie zasygnalizować, że w systemie "coś siedzi". Do wykrywania rootkitów istnieją dedykowane programy, których najlepiej jest używać grupowo, a i tak pozytywnym wynikom nie należy do końca ufać.
• Google pomaga :) Jedną z dobrych metod identyfikacji niechcianych programów jest bowiem przejrzenie listy procesów (stworzonej przez narzędzie w rodzaju IceSword) i kolejne sprawdzenie wszystkich potencjalnie podejrzanych pozycji poprzez wyszukanie informacji na ich temat w Internecie.
• Najbardziej znanym narzędziem do usuwania rootkitów jest ComboFix, który pomógł zresztą w moim przypadku. W ogólności jednak naprawa może być niemożliwa. Tak naprawdę zaleca się zresztą, by po wykryciu rootkita poważnie zastanowić nad sformatowaniem dysku i odbudową systemu od podstaw. Brr :)

Krótko mówiąc, wykrywanie i walka z tym rodzajem szkodliwego oprogramowania to coś znacznie poważniejszego niż wciśnięcie przycisku Scan i czekanie na wyniki :] Rezultaty też nigdy nie są pewne.

O reinstalacji systemu na komputerze stacjonarnym trzeba więc będzie pomyśleć jak najszybciej, a od wczoraj stało się to prostsze, gdyż mój laptop wrócił z naprawy. Okazało się, że konieczna była wymiana płyty głównej (!) - oryginalna prawdopodobnie miała fabryczną usterkę... No cóż, dobrą stroną jest to, że za tę skomplikowaną operację nie musiałem zapłacić ani grosza; niech żyją gwarancje :)

Moc breakpointów w VS

Śledzenie wykonywania programu to świetna metoda na znajdowanie przyczyn wielu błędów. Ale żeby coś sensownie śledzić, to najpierw zwykle trzeba dojść do interesującego fragmentu kodu - to zaś umożliwiają punkty przerwania, czyli po polsku breakpointy ;)
W najbardziej podstawowej wersji działają one niezwykle prosto i zwyczajnie zatrzymują debuger na wskazanej instrukcji. W Visual Studio możemy jednak wykorzystać w sposób znacznie bardziej zaawansowany; wystarczy bowiem - po postawieniu breakpointa kliknąć weń prawym przyciskiem myszy i już ukazuje się nam wielce interesujące menu podręczne. Mamy tam kilka przydatnych opcji, do których należą między innymi:

• Location - umożliwia precyzyjne określenie, na jakiej instrukcji stawiamy breakpoint. Jest to użyteczne, gdy mamy np. krótką jednolinijkową instrukcję if, a punkt przerwania chcemy ustawić nie na sprawdzaniu jej warunku, lecz w środku jej bloku.
• Hit Count - wyświetla nam okienko, w którym widać, ile razy breakpoint został "trafiony" od początku sesji debuggera. Możemy też określić tam, aby zatrzymanie następowało tylko przy jakimś określonym przejściu przez breakpoint. Może to być przydatne, jeśli np. debugujemy pętle, o której wiemy, że zaczyna się psuć w okolicach 4867 iteracji - właśnie tyle wciśnięć F5 możemy w ten sposób oszczędzić :)
• When Hit - ta opcja pozwala z kolei na wykonanie dodatkowych akcji w momencie trafienia breakpointa, co obejmuje nawet możliwość uruchomienia makra sterującego zachowaniem IDE (!). Prawdopodobnie bardziej przydatne jest jednak wypisywanie komunikatu w oknie Output debugera; opcja ta jest na tyle zaawansowana, że może właściwie eliminować użycie funkcji typu OutputDebugString czy nawet dedykowanych logerów.
• Condition to z kolei bodaj najprzydatniejsza opcja ze wszystkich. Pozwala mianowicie na określenie dodatkowego warunku, który musi być spełniony, aby punkt przerwania zadziałał. Jest to nieocenione do znajdowania błędów w skomplikowanych pętlach warunkowych, że o funkcjach rekurencyjnych nie wspomnę.
• Filter to z kolei zaawansowana opcja, umożliwiająca ograniczenie działania breakpointa tylko do wybranych procesów lub wątków (rozpoznawanych przez identyfikator lub nazwę). Jak nietrudno się domyślić, przydaje się w programach równoległych.
• W końcu Disable Breakpoint pozwala czasowo wyłączyć breakpoint bez usuwania go, czyli utraty tych wszystkich ustawień, które pieczołowicie wpisywaliśmy przy pomocy powyższych opcji :)

I tyle właśnie potrafią breakpointy w VS. Całkiem sporo, jak na jedną niepozorną, czerwoną kropkę :]

Więcej Schowka

Wiele różnych rozbudowanych programów - jak np. IDE lub pakiety biurowe - zawiera mechanizmy rozszerzające funkcjonalność windowsowego Schowka. Oznacza to najczęściej możliwość zachowania więcej niż jednego wycinka naraz i przełączanie się między nimi, gdy chcemy wkleić gdzieś któryś z nich.
Dotąd nie byłem zbyt entuzjastycznie nastawiony do takiej funkcjonalności - może dlatego, że posiadanie więcej niż jednego Schowka było poza zasięgiem moich możliwości pojmowania ;) Zdarzyło się jednak, że kilka razy potrzebowałem wrócić do tekstu, który już "nieopatrznie" nadpisałem kilkoma kolejnymi skopiowaniami do Schowka. Wtedy też zacząłem rozglądać się za aplikacją, która w jakiś sensowny sposób rozszerza możliwości systemowego Schowka, dodając do niego więcej 'slotów'.

Poszukiwania nie były niestety specjalnie owocne. Najlepsze, co udało mi się znaleźć, to program o wielce oryginalnej nazwie MultiClipBoard. Narzędzie to chowa się do systemowego zasobnika i pozwala posiadać nieograniczoną liczbę niezależnych Schowków na wycinaną treść. Potrafi też tworzyć nowy przy każdym kopiowaniu, dzięki czemu niczego nie zgubimy. Niestety, nie oferuje zbyt wielu przydatnych skrótów klawiszowych, umożliwiających chociażby cofnięcie się do poprzednio wyciętego elementu.
Ale oczywiście lepsze to niż nic - przynajmniej na razie. Bo kto wie, może w Windows 7 zamiast kolejnych wodotrysków zobaczymy coś użytecznego, jak właśnie nieco bardziej inteligentną obsługę Schowka. Chociaż to pewnie tylko pobożne życzenia :)

Mniejszy edytor

Do programowania używamy głównie pełnowymiarowych IDE. W repertuarze narzędzi koderskich dobrze jest jednak mieć także edytor plików tekstowych bez całej tej projektowo-kompilacyjnej otoczki. Przydaje się on w wielu różnych sytuacjach, począwszy chociażby od typowego przypadku, gdy chcemy podejrzeć zawartość jakiegoś pliku z kodem bez odpalania całego "ciężkiego" środowiska. Poza tym wcale nie tak rzadko zdarza się, że musimy skrobnąć coś w języku, którego niekoniecznie używamy intensywnie na co dzień (jak choćby którymś z języków skryptowych).

Minimum, jakie taki programistyczny edytor powinien spełniać, to oczywiście podświetlanie składni. Wypadałoby też, by zawierał on większość funkcjonalności, jaką w zakresie manipulowania kodem oferuje IDE, np. wyszukiwanie w oparciu o wyrażenia regularne czy wyświetlanie numerowania linii i białych znaków. Dobrze by też było, gdyby umożliwiał o edycję kilku plików naraz. Prawdopodobnie najważniejsze jest jednak to, aby takie edytor był lekki: uruchamiał się jak najszybciej i tak też działał, nie zajmując przy tym wielu zasobów systemowych.
Pewnie każdy ma swój ulubiony program tego rodzaju, ale mimo to nie omieszkam polecić aplikacji, którą sam używam w charakterze "mniejszego edytora": Programmer's Notepad. Umie ona wszystko to, o czym wspomniałem wyżej, i jeszcze wiele więcej. Wśród poważniejszych braków, jakie mogę jej zarzucić, przypominam sobie jedynie brak wbudowanych narzędzi do konwersji między różnymi 8-bitowymi standardami kodowania znaków (z przeróżnymi UTF-ami itp. nie ma bowiem problemu). Ponieważ jednak możliwe jest dodawanie też własnych narzędzi uruchamianych z wiersza poleceń, w razie potrzeby można sobie odpowiednią funkcjonalność dodać samodzielnie :)

Wszystko działa w tle

W bardzo dawnych czasach systemy operacyjne słabo radziły sobie z wielozadaniowością (niektóre zgoła wcale). Ostatnio jednak zmieniło się całkowicie; teraz niemal cała funkcjonalność systemu w rodzaju Windows czy Linux opiera się na działających w tle procesach (zwanych usługami lub demonami).
O ile w tych przypadkach ma to najczęściej sens, o tyle ciężko jest mi zrozumieć, dlaczego coraz więcej zupełnie zwyczajnych aplikacji "upiera się", aby także działać w sposób ciągły. Owszem, w niektórych przypadkach jest to jak najbardziej uzasadnione - weźmy chociażby internetowe komunikatory. Wydaje mi się jednak, że widoczny tu trend idzie zdecydowanie zbyt daleko.

Mam mianowicie wrażenie, że obecność ikonki prawie każdej aplikacji w systemowym zasobniku (tray) stała się niemal obowiązkowa. Nie ma przy tym znaczenia, czy dany program (albo raczej jego główna część) jest uruchomiony czy nie. Dobrym pretekstem do takiej obecności bywa nawet czynność tak absurdalna, jak pilnowanie skojarzeń określonych typów plików z macierzystą aplikacją (domyślnie robi tak np. odtwarzacz Winamp. Najważniejsze jest bowiem to, aby po jedno- lub dwukrotnym kliknięciu w taką ikonkę uruchomił się właściwy program. Zupełnie jakby posiadanie skrótów na Pulpicie czy w menu Start nie było całkowicie wystarczające.
Co więcej, raz wystartowana aplikacja zwykle też nie daje się tak łatwo zamknąć. Bardzo popularna jest, przykładowo, zmiana zachowania przycisku Zamknij (lewy górny róg okna), który wcale aplikacji nie zamyka, a jedynie minimalizuje ją do ikonki we wspomnianym już zasobniku. Dopiero jawne wybranie opcji z menu pozwala faktycznie program zakończyć; w innym przypadku jest to po prostu zamknięcie udawane.

Jakie są tego skutki? Ano takie, że nawet czterordzeniowy procesor z gigabajtami pamięci operacyjnej może mieć ciężkie chwile w obsłudze kilkudziesięciu procesów i kilkuset wątków naraz, z których większość stanowią "niedomknięte" aplikacje. Prawdziwe kłopoty zaczynają się zaś wtedy, gdy chcemy uruchomić naprawdę wymagający program, jak choćby pełnoekranową grę.
A wszystko to dlatego, że aplikacje chcą być mądrzejsze od swoich użytkowników...