Hellcore Mailer

Benchmarków mailerów nie będzie

Fri, 06 Nov 2009 12:24:48 +0100

Nie chce mi się ich robić.

Niektóre programy nie zmieniają się, inne zmieniają za szybko, do tego dochodzą różnice w konfiguracji sprzętu i oprogramowania (w praktyce ten sam program na tym samym komputerze pod różnymi systemami działa inaczej - HCM na Pentium 200 uruchamia się trochę wolniej na Windows 2000 niż na Windows 95, ale z kolei na Windows 95 ma niższą maksymalną przepustowość podczas wysyłania i pobierania wiadomości niż na Windows 2000 - widać, że jednak usprawnili stos TCP/IP w Win2k). Żeby benchmarki były w 100% wiarygodne, musiałbym praktycznie co miesiąc-dwa je aktualizować, a bez tego mam za dużo na głowie.

Inna sprawa, że zaraz na karku miałbym bandę wyznawców innych klientów, którzy doczepiliby się do metodologii lub (w ich mniemaniu) fałszowania wyników. To z kolei na bank skończyłoby się niekończącym się flejmem. Bez sensu.

Wraz z HCMem 0.6 pojawią się benchmarki na Atomie 330 i Core 2 Duo E4400, jeśli ktoś chce, będzie mógł sobie sam porównać ze swoim obecnie używanym programem ;-) Ale ja myślę, że HCM w tym miejscu nie wymaga specjalnej reklamy, wszystkie programy dążą do przebloatowania, co prowadzi do budzenia się z ręką w nocniku, a co za tym idzie - strzelaniem sobie w stopy. Genialnym przykładem takiego podejścia jest The Bat, który z maleńkiego mailerka rozrósł się do kobyły niewiele mniejszej od Opery. Zamiast zoptymalizować kod, to twórcy tego programu upiekli dwie pieczenie na jednym ogniu - problemem dla RIT Labs byli crackerzy którzy okresowo wypuszczali pokrakowane wersje albo kraki i/lub keygeny. Co zrobili? Zabezpieczyli przed pokrakowaniem za pomocą Themidy. Jedną z opcji Themidy jest kompresowanie wykonywalnego pliku - a to, jak wiadomo, źle odbija się na użyciu pamięci, ponieważ skompresowane programy muszą być wczytane do pamięci w całości (normalnie system Windows wczytuje tylko potrzebne fragmenty plików wykonywalnych i potrafi je współdzielić między uruchomionymi instancjami; przy skompresowanych programach żadna z tych optymalizacji nie może być zastosowana). Efekt był bardzo śmieszny, ludzie niemalże skakali z radości, że "z dnia na dzień" wielkość pliku wykonywalnego The Bata spadła z ~14 do ~6MB (niektórzy The Batowi ewangeliści przypisywali to niezwykłemu zoptymalizowaniu kodu), ale jakoś mało kto zwrócił uwagę, że przez tę kompresję The Bat zaczął zjadać więcej pamięci (ok. 40MB - więcej nawet niż "goły" Thunderbird). W ostatniej wersji wycofali się z tego kompresowania wobec czego minimalne użycie pamięci spadło do akceptowalnego poziomu, ale wielkość pliku wykonywalnego znowu przekracza 10MB (nieskompresowany plik wykonywalny HCMa, dla porównania, zajmuje 2,14MB).

Pomoc Hellcore Mailera on-line

Fri, 16 Oct 2009 04:58:51 +0200

Jest i można oglądać szkic tego, co będzie (a co już jest w CHMie udostępnionym w Hellcore Mailerowej pobieralni). Adres jest bardzo prosty: http://pomoc.hellcore-mailer.pl.

Jeśli ktoś ma jakieś uwagi, spostrzeżenia, etc., to ja chętnie posłucham.

Jak napisałem, jest to szkic. Trochę się pozmienia, kilka rzeczy uzupełnię lub poprawię, to tylko kwestia czasu i odpowiedniego (czytać: jakiegokolwiek) feedbacku. ;-)

Ale już mi nikt nie wciśnie, że HCM nie ma dostępnego podręcznika! ;-> Poza tym, zaczęły wyskakiwać w guglu (w statystykach bloga i strony HCMa) osoby z zapytaniami w rodzaju "konfiguracja hellcore mailer", więc zapotrzebowanie jest (i tak, tym razem jednak odpuszczę sobie chamskie docinki...).

ActiveX'owe boje

Thu, 15 Oct 2009 03:34:08 +0200

Pisanie własnej przeglądarki (czy chociaż renderera HTML) to samobójstwo - HTML to temat-rzeka i jeśli żaden z producentów którejkolwiek przeglądarki nie dał sobie z tym rady (ciągłę luki bezpieczeństwa, rozbieżności w obsłudze standardów, własne narowy, wydajność, etc), to jak np. ja miałbym sobie dać radę? W dodatku sam? Zatem odpada, zdecydowanie. No ale ludzie domagają się HTMLa, nie przeżyją bez tego (zresztą ostatnio korci mnie, by dodać obsługę RSSów - czytnik w Operze zaczyna mnie dobijać, nowego softu nie chcę, Google Reader zdecydowanie odpada), a sporo softu obsługuje HTML i tak. Jakim cudem? Używają kontrolki Internet Explorera - TWebBrowser.

No to fajnie, zaimportowałem sobie kontrolkę IE via odpowiednia funkcja Delphi i początek zapowiada się nieźle. Co prawda trzeba dodać blokowanie zewnętrznych linków i skryptów, ale odpowiedni kod już jest, więc bułka z masłem. Działa, obrazki wyświetlają się, za statusbar IE robi statusbar HCMa (łiii, nie trzeba pozbywać się przeglądarkowych przyzwyczajeń jeśli chodzi o linki!), na razie pięknie. Czyżby? I wtedy mnie coś przypadkowo uderzyło. Ale to tak mocno, że do dzisiaj mi dzwoni w głowie.

Wyciek pamięci.

I to spory, bo około 10MB. Wycieki są tym większe, im większe są wczytywane dokumenty. I co, wydawałoby się że banał - wywołać metodę "Free" kontrolki i wszystko samo się sprzątnie? O nie, nie nie nie... ;-)) RAM is cheap, motherfucker, so put it to good use! Problem udało mi się trochę załagodzić, rzutując TWebBrowser.Document na IPersistStreamInit i używając metody InitNew tego interfejsu, ale dalej jest po pierwsze ~10MB jednorazowego wycieku, a potem kolejnych kilkadziesiąt-kilkaset kB wycieku (zależnie od tego, ile ważyły obrazki). Myślałem że może coś robię nie tak, więc kombinowałem z różnymi metodami i ostatecznie stanęło na tym, że KontrolkaIE.Free tak naprawdę mało co zwalnia, a co bym nie robił, to zawsze będzie jakiś memory leak. W gruncie rzeczy, to nawet nie wiem za co się złapać, OLE i ActiveX to kolejny temat-rzeka, do tego najeżony WTFami, domysłami i ogólną czarną magią - a mnie się skończyły koty więc nawet nie mam co poświęcać (to tzw. mhrhrhrhotchny humor Brancha).

Właściwie jedyne co mi teraz przychodzi na myśl, to trik z sandboxowaniem (wsadzanie kontrolki do osobnego procesu) - tworzy się nowy proces, jako jego okno nadrzędne ustawia się okno kontrolki-kontenera gdzie miał być przechowywany IE albo Acrobat, i resztę deleguje do delikwenta. Nie jest to zbyt efektywne rozwiązanie ale będzie działać, to raz, zapewni kontrolę nad użyciem pamięci to dwa, a trzy, jeśli się wysypie (bo np. ktoś odpalił HCMa pod stareńkim Win98 i próbował wyświetlić plik html o treści "<input type>"), to tylko proces przeglądarki a nie HCM. W sumie to można już przyglądać się jak to zrobili w Chrome. ;-) Chyba, że komuś udało się to obejść/rozwiązać bardziej po bożemu - bardzo chętnie poczytam i douczę się. Z góry gwiazdor zapłać, bo ja nie mam. Dościślę tylko, że mój TWebBrowser jest tworzony dynamicznie.

A w ogóle to fajną mamy zimę tej jesieni.

HCMowy Bugtracker

Sat, 29 Aug 2009 22:45:21 +0200

Jest i można się bawić. Na razie działa testowo, ale powinien się sprawdzić w działaniu. Oparty o Mantis, dla niektórych powinien być już znany i lubiany (albo i nie). Oczywiście nie jest to "free for all", trzeba się zarejestrować (no już, już, nie stękać, mnie też się to nie podoba, ale niczego lepszego nie wymyślili) i pewnie będzie się trochę ślimaczyć, no ale. Przynajmniej nikt mi nie będzie już zarzucał sklerozy czy ignorancji :>

A sam bugtracker leży sobie tu: http://bt.program-pocztowy.pl i na razie wygląda jak wygląda, z czasem się rozwinie.

Taka uwaga do zakładających konto na bugtrackerze: dla własnego bezpieczeństwa proszę nie używać tych samych haseł co do Allegro, banku, Naszej-Klasy czy innych serwisów, których pohakowanie via włamanie na bugtracker mogłoby się skończyć nieprzyjemnie. Nie ma dostępu do haseł (są zahashowane, nie sprawdzałem tylko czym), ale mimo wszystko - nie warto ryzykować.

Win32/Induc a HCM i inne moje aplikacje

Thu, 20 Aug 2009 12:21:03 +0200

Marcin Dzierzkowski aka Largo3 właśnie podrzucił mi informację, że w sieci szaleje robak Win32/Induc. Jest to o tyle niezwykłe stworzonko, że infekuje ... środowisko Borland Delphi. Jako że Hellcore Mailer (choć nie tylko) jest napisany w Delphi, pozostaje mi zająć oficjalne stanowisko w tej kwestii.

Hellcore Mailer jest napisany w środowisku Borland Delphi 3 (trzy) które - wg wszystkich znanych mi źródeł - nie ulega robakowi.

Dodatkowo, środowisko stagingowe (maszyna do produkowania finalnych/dziennych buildów) jest chronione m. in. przez system HIPS wbudowany w firewallu Comodo Personal Firewall, który bez problemu wykryłby zagrożenie.

Zatem - nie ma powodu do obaw. Powyższa uwaga dotyczy wszystkich upublicznionych przeze mnie aplikacji.

Nowe adresy WWW Hellcore Mailera

Thu, 23 Jul 2009 16:33:11 +0200

Projekt doczekał się wreszcie nowych, ładnych adresów WWW. Koniec z zabazgranymi reklamami aliasami prv.pl! :P Poprawcie swoje bookmarki, linki, i co tam jeszcze macie ;-)

Nowe adresy to: http://www.program-pocztowy.pl oraz http://www.hellcore-mailer.pl.

Nowe podręczniki

Sun, 19 Jul 2009 19:13:49 +0200

Załadowałem przed chwilą nowe podręczniki do Hellcore Mailera - polski i angielski. Tak, wreszcie przetłumaczyłem help na angielski...

A co się narobiłem, to moje.

Przez moment zastanawiałem się czy już nie puszczać kolejnego (0.6) wydania, ale zdecydowałem się jednak wstrzymać (niecierpliwi mogą zawsze jechać na aktualnych buildach). Muszę też przemyśleć co jest bardziej opłacalne w kwestii kompresji plików. Kompresowanie helpa w trakcie kompilacji daje tyle, że zajmuje ~450kB na dysku po instalacji (miast ~2MB), ale słabo się kompresuje (większe o ~150kB archiwa/instaki). Kompresowanie binariów gwarantuje najmniejszą instalkę, archiwum i najmniej zużytej przestrzeni dysku, ale z drugiej strony, to zawsze o ~2MB większe użycie pamięci RAM. Bądź tu mądry. Idealnie (z punktu widzenia wielkości archiwów/instalek oraz ilości użytej pamięci RAM) to chyba byłoby nie kompresować niczego - no ale wtedy pełna instalacja HCMa będzie zżerać ze 4MB. Nieźle się rozrósł.

Niemniej, cały czas coś idzie do przodu. Na witrynie Hellcore Mailera pojawiło się FAQ - polskie oraz angielskie. Wkrótce dojdą też wyniki benchmarków mailerów.

Nowy kanał RSS - DailyHCM

Thu, 04 Jun 2009 19:44:05 +0200

Ponieważ są tu osoby śledzące HCMa z dokładnością do najnowszego buildu (a nie tylko wydania), zdecydowałem się ułatwić tym ludziom życie, tworząc nowy kanał RSS - DailyHCM - będący po prostu changelogiem przekonwertowanym na XML-RSS.

A wkrótce (nie, nie wiem kiedy - tak, wiem że minęło pół roku od ostatniego wydania...) - HCM 0.6, dalej beta, ale stabilniejsza i szybsza niż HCM 0.5.9.235. :-)

Damned ClearType

Tue, 07 Apr 2009 20:52:59 +0200

Się poddałem. Nie mam bladego pojęcia, dlaczego niektóre wiersze tekstu w edytorze wiadomości (zarówno edytorze treści jak i nagłówka) potrafią nie pojawić się, gdy jest włączone ClearType. Poszedłem więc na łatwiznę i wyłączam ClearType dla czcionki edytora - choć nie ma to wpływu na system, to i tak mi się nie podoba. Ale to jest znacznie lepsze wyjście niż marnowanie X godzin na szukanie przyczyny problemu.

Przy okazji zlikwidowałem mały wyciek pamięci i jedną rzecz zoptymalizowałem. Ale różnica nie jest duża.

HCM 0.6 EN - testowy build i angielskojęzyczna witryna

Sat, 04 Apr 2009 00:39:49 +0200

Pełnego release'u na razie nie ma, ponieważ chcę zlikwidować bug z migającym tekstem w edytorze, gdy jest włączone ClearType (irytujące zwłaszcza pod Vistą) i przywrócić import i eksport książki adresowej z/do plików CSV/TSV, jednak w związku z tym, że jest naprawdę sporo do zrobienia tak czy siak, robię wszystkiego po trochu (w zgodzie z zasadą małych kroczków), i dzisiaj dla odmiany wgrałem na serwer angielskojęzyczną witrynę i przy okazji aktualizowania skryptu budującego HCMa - także angielskojęzyczną betę. Nie wszystko jest przetłumaczone, interfejs jest przetłumaczony tak w 3/4, zaś help w ok. 10% (pomijam że pewnie jest sporo krzaków językowych). Gdy już mi się wydawało, że dobiegam do końca tego wszystkiego, nagle powychodziło sto innych rzeczy. No i tak w kółko. Także można to nazwać bardziej testem dla samego testu niż jakąś publiczną betą. Anyway, here it is: Hellcore Mailer po angielsku.

Uważny, polski user nie zauważy różnicy z prostej przyczyny - HCM dopasowuje język interfejsu i helpa do używanego przez system, wobec czego na polskim systemie po prostu nie przetłumaczy się. Ale spoko, to da się obejść bardzo prosto: wystarczy wszystkim plikom z "9" w nazwie (tj. 9.lng, 9.wml, 9.cnt i 9.hlp) zmienić tę dziewiątkę na "1045" (np. 9.lng => 1045.lng) - wtedy pójdzie. Alternatywnie można wykorzystać submenu "Język" z menu "Narzędzia". :-) (Uwaga: tu jest mały haczyk. Jeśli używany jest np. angielski system Windows i wszystkie ustawienia regionalne są ustawione na typowe dla Polski, to HCM również użyje polskiego interfejsu i helpa; podobnie jest z innymi językami - innymi słowy, HCM sprawdza ustawienia regionalne a nie wersję językową systemu).

Tłumaczenia jest jeszcze - jak pisałem - sporo (i równie sporo jest do zweryfikowania/korekty), w związku z czym, jak zwykle, wszelka pomoc mile widziana. W zasadzie to potrzeba tylko wstępnego (takiego, żeby non-pl user wiedział co i jak) tłumaczenia, dalej sprawę może pociągnie ktoś, dla kogo angielski jest językiem ojczystym...