n...@m...invalid <n...@m...invalid> napisał(a):
>> MSOE jest mocno oparte o COM, nie nazwałbym więc tego czystym WinAPI.
> Ok. Wycofuję swoje twierdzenie.
>> Wszystko opiera się o COMowe interfejsy, jak np. IMimeMessage,
>> IStoreNamespace czy IStoreFolder, więc co chwila woła się
>> CoCreateInstance. Korzysta też zewnętrznej biblioteki jaką jest
>> inetcomm.dll. Poza tym źródła OE są dosyć słabo czytelne więc nie
>> polecałbym.
> Dzięki za ciekawe informacje. Ktokolwiek decyduje się rozwijać program
> w WinAPI, musi być gotów na pisanie nieczytelnego kodu.

Tutaj ta nieczytelność wynika z wielu warstw abstrakcji oraz z istnienia
wielu funkcji, z których sobie człowiek nie do końca zdaje sprawę na
podstawie samego używania programu. WinAPI w kodzie OE za dużo nie ma.

> Jaki jest cel istnienia dodatków w rodzaju OE PowerTool (opisywany m.in.
> na Twojej stronie)?

Na tej stronie ten cel jest wyjaśniony :) W każdym razie błędy w obsłudze
standardów zostały już jako tako załatane przez MS. Lepiej teraz używać OE
niż np. Google Groups, które nie umieją tak podstawowych rzeczy jak
iso-8859-2.

> Czy wszystkie patche, którymi ten dodatek poprawia
> bugi, zostały już wprowadzone upstream (post-6.0 SP3)?

Nie rozumiem. OE PowerTool nie poprawia bugów patchami. A jeśli chodzi o
patche MS to od SP2 nic się szczególnego nie pojawiło.

> Zaznaczam, że gdy piszę e.g. "MSOE" to prawie zawsze mam na myśli
> program vanilla, out-of-the-box (a więc, w tym przypadku, bez OE
> PowerTool, i nie Windows [Live] Mail).

W Windows Live Mail jest gorzej, nic tylko spalić i posypać solą.

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 0 days, 15 hours, 51 minutes and 8 seconds