On 25-01-2012 21:09, Sebastian Biały wrote:
> było by lepsze. COKOLWIEK co nie leży na poziomie WinAPI będzie lepsze.
>
Pomijasz jeden fakt. Programy (lub raczej programiki) pure win32 api sa
mega krotkie (bynajmniej nie mam na mysli zrodel ;-). Przyklad z
praktyki - Ile zajmie program monitorujacy dostepnosc jakiegos serwisu
www (chodzi o binarna ikonke w tray) w C++ z uzyciem frameworkow (pytam
a cala instalke wraz z bibilotekami) z ile czyste win32 api ? Wiem wiem
lacza sa szybkie, dyski sa tanie....

> Niestety musisz uważać, poradniki w sieci piszą te same tysiące
Dlatego papierowa ksiazka jest lepsza.

Pozdrawiam

Marek

do góry

W dniu 2012-01-26 10:31, a...@p...fm pisze:
> Venioo- jaki MS - Visual ??? Duzo lepsze jest QT Nokia i do tego
> free. SUPER !
>
> polecam http://qt.nokia.com/
>
>

Polemizowalbym. Basic jest banalnie prosty, do tego ma fantastyczny MSDN
i cala mase tutoriali. No i oczywiscie w wersji Express (ktora mi do
wszystkiego wystarczala) jest zupelnie darmowy.
W Qt tez probowalem cos pisac, jednak pewnych przyzwyczajen nie jestem w
stanie przezwyciezyc i szlo mi strasznie ciezko.


--
venioo -> GG:198909
Sprzedam AUDI 100 C4 '91 AAR 2.3 LPG
http://tablica.pl/oferta/audi-100-c4-czarna-gaz-lpg-
mafia-look-IDvheh.html

do góry

Marek Borowski <m...@b...com.nospam> napisał(a):
> Wiem wiem lacza sa szybkie, dyski sa tanie....

A frameworki bywają już wbudowane w system...

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 1 day, 18 hours, 41 minutes and 15 seconds

do góry

On 2012-01-26 21:42, Marek Borowski wrote:
> Pomijasz jeden fakt. Programy (lub raczej programiki) pure win32 api sa
> mega krotkie (bynajmniej nie mam na mysli zrodel ;-). Przyklad z
> praktyki - Ile zajmie program monitorujacy dostepnosc jakiegos serwisu
> www (chodzi o binarna ikonke w tray) w C++ z uzyciem frameworkow (pytam
> a cala instalke wraz z bibilotekami) z ile czyste win32 api ?

Podaj choć jeden powód dla którego miało by to być:

a) argumentem w tej dyskusji

b) argumentem w dowolnej dyskusji po roku 2000.

do góry

On 26-01-2012 22:10, Sebastian Biały wrote:
> On 2012-01-26 21:42, Marek Borowski wrote:
>> Pomijasz jeden fakt. Programy (lub raczej programiki) pure win32 api sa
>> mega krotkie (bynajmniej nie mam na mysli zrodel ;-). Przyklad z
>> praktyki - Ile zajmie program monitorujacy dostepnosc jakiegos serwisu
>> www (chodzi o binarna ikonke w tray) w C++ z uzyciem frameworkow (pytam
>> a cala instalke wraz z bibilotekami) z ile czyste win32 api ?
>
> Podaj choć jeden powód dla którego miało by to być:
>
> a) argumentem w tej dyskusji
>
> b) argumentem w dowolnej dyskusji po roku 2000.
>
Zdawalo mi sie iz temat jest o sensnownosci uzywania winapi.
Wiec pisze iz jako UZYTKOWNIK: zdecydowanie WOLE programy w winapi w
opisanych juz przeze mnie przyczyn. Dodam jeszcze szczatkowe utilzacje
pamieci. Jako programista - wiem doskonale o i ile latwiej i szybciej
sie pisze z uzyciem bardziej wysokopoziomowych bibliotek.


Pozdrawiam

Marek

do góry

On 2012-01-26 22:34, Marek Borowski wrote:
> Zdawalo mi sie iz temat jest o sensnownosci uzywania winapi.

... do pisania małych duperelek korzystajacych z portu COM.

> Dodam jeszcze szczatkowe utilzacje
> pamieci.

Jesli masz na myśli GC to postęp się poczynił na tyle duży że warto
przemysleć stare argumenty. Ponadto Qt nie używa GC. W ogóle dobra
abstrakcja nie musi mieć GC. Tu o abstrakcję nad API tylko chodzi.

> Jako programista - wiem doskonale o i ile latwiej i szybciej
> sie pisze z uzyciem bardziej wysokopoziomowych bibliotek.

O co zapewne chodzi autorowi wątku zamiast rozwiązywać zagadki z
czeluści MSDNa.

do góry

On 26-01-2012 22:44, Sebastian Biały wrote:
> On 2012-01-26 22:34, Marek Borowski wrote:
>> Zdawalo mi sie iz temat jest o sensnownosci uzywania winapi.
>
> ... do pisania małych duperelek korzystajacych z portu COM.
>
Z punktu widzenia programisty faktycznie nie ma sensu. Zrobienie
sensownej oblugi COMow w C# to chwila moment. Zas w czystym winapi sama
ich enumeracja zajmuje kilkaset lini. (Sam oba warianty przerabialem).


>> Dodam jeszcze szczatkowe utilzacje
>> pamieci.
>
> Jesli masz na myśli GC to postęp się poczynił na tyle duży że warto
> przemysleć stare argumenty. Ponadto Qt nie używa GC. W ogóle dobra
> abstrakcja nie musi mieć GC. Tu o abstrakcję nad API tylko chodzi.
>
Piszac o pamieci mialem na mysli wiecej zaladowanych biliotek, wiecej
danych. Popatrz sobie na programy Marka Russinovicha to jest dla mnie
wzorzec pisania pod windows. Nawet najbardziej rozbudowane programy sa
linkowane do kilkunastu dll gdzie hello world pod frameworka moze miec
ich ponad setke.


>> Jako programista - wiem doskonale o i ile latwiej i szybciej
>> sie pisze z uzyciem bardziej wysokopoziomowych bibliotek.
>
> O co zapewne chodzi autorowi wątku zamiast rozwiązywać zagadki z
> czeluści MSDNa.
Moze i masz racje.


Pozdrawiam

Marek

do góry

W dniu 26-01-2012 20:27, Sebastian Biały pisze:
> On 2012-01-26 19:45, Robert Zemła wrote:
>> Wybacz ale nie bardzo rozumiem Twojej niechęci do WinAPI.
>
> Znasz cos poza nim? Qt? .NET? JRE? Bo ja znam.
>
>> Jego idea i
>> sens żyje tak długo jak istnieją Windowsy - od czasów kiedy ówczesne
>> maszyny potrafiły niewiele więcej "uciągnąć" niż Windows i trochę GUI.
>
> Naprawdę chcesz z tego wyciągnąć tezę że to co było dobre w czasach 386
> dzisiaj jest również doskonałe?

Nie, ale idąc tym tropem wychodzi że to cały Windows jest zły. W sumie
jest w tym też trochę racji ... :-)

>
>> Owszem masz 100% racji że dzisiaj istnieją o wiele wygodniejsze sposoby
>> ale to wszystko to tylko kolejna warstwa, natomiast wiedza z zakresu
>> "jak to faktycznie działa" naprawdę potrafi się mocno przydać.
>
> Nie. Naprawdę, nie interesuje Cie ile bajtów ma DWORD, dlaczego istnieje
> różnica między unicodem a char i dlaczego notacja węgierska jest do
> bani.

Prawdę mówiąc nie chciał bym pracować z człowiekiem który by nie
wiedział ile bajtów ma DWORD. Przy okazji dochodzimy do innego problemu.
Po co programista ma w ogóle wiedzieć jak działa komputer? System?
Wystarczy że wie w jakiej kolejności trzeba wystukać komendy na
klawiaturze (albo gdzie i jak kliknąć myszką) żeby pojawiło się okienko
i guzik. Co zrobi taki programista któremu "coś" nie zadziała? Pewnie
poszuka innych komponentów/bibliotek, tylko gorzej jak nie znajdzie.
Zresztą ten problem nie tylko tyczy się informatyki.

Zacznij uzywać środowisk *obiektowych* a zobaczysz gdzie jest
> miejsce WinAPI. Programowanie *dzisiaj* w tym cudzie z lat 80 wymaga
> *naprawdę* solidnej wymówki. Przedstaw ją w kontekście tego wątku.

Ah te obiektowe środowiska... ile rzeczy można zrobić myszką... :-)
swoją drogą używam i też lubię. Natomiast do pisania pod WinAPI nie
potrzebuję wymówki.

pozdrawiam,

do góry

On 2012-01-26 23:56, Robert Zemła wrote:
>> Naprawdę chcesz z tego wyciągnąć tezę że to co było dobre w czasach 386
>> dzisiaj jest również doskonałe?
> Nie, ale idąc tym tropem wychodzi że to cały Windows jest zły.

Nie idź dalej tym tropem. WinAPI jest złe. Jest ciężkie, niespójne,
zagmatwane, czerpie całymi garściami z lat 80, ma się nijak do nowych
języków i technik programistycznych. To niskopoziomowe API systemu, nie
istnieje żaden argument aby z niego korzystać wprost poza jakimiś
promilami aplikacji wymagającymi ekstremalnych szybkości w brzegowych
zastosowaniach.

> Prawdę mówiąc nie chciał bym pracować z człowiekiem który by nie
> wiedział ile bajtów ma DWORD.

Prawdę mówiąc nie chciałbym pracować z człowiekiem dla którego napisanie
prostego programu do komunikacji po COM wymaga znajomości szczegołów
definicji DWORD. *Abstrakcja* jest ważniejsza od znajomości szczegołów
implementacji choćby z powodu przenośności, ba, nawet w samym Windowsie.

> Po co programista ma w ogóle wiedzieć jak działa komputer?

Przesadzasz. Rzecz w tym po co programista ma wiedzieć jak działa
allokator pamięci i co zrobic żeby strcpy się nie wysypało. Otóż nie
powinien zaprzatać sobie głowy duperelami bo jego celem jest napisanie
kodu który działa. Wydajność, zajętość pamięci są trzeciorzędne,
szczególnie dla początkujących. Wazniejsze jest posiadanie zestawu
działających kontenerow, obiektowej biblioteki GUI, łatwych do użycia
komponentów, bibliotek zapewniających wsparcie w konkretnych zadaniach.

> Wystarczy że wie w jakiej kolejności trzeba wystukać komendy na
> klawiaturze (albo gdzie i jak kliknąć myszką) żeby pojawiło się okienko
> i guzik.

Tak działa Delphi. Początkujący, pozostawiony na pastwę tego środowiska
zaczyna pisać ciało funkcji w onclikach i tak juz mu zostaje. Dlatego
nie wolno pokazywac go początkującym uczącym się samodzielnie bo uczy
mimowolnie złych praktyk.

> Co zrobi taki programista któremu "coś" nie zadziała?

Wiele rzeczy może, ale w WinAPI znacznie częściej nie będzie mu działać
i znacznie gorzej będzie debugować dlaczego.

> Ah te obiektowe środowiska... ile rzeczy można zrobić myszką... :-)

Pomyliłeś programowanie obiektowe z RAD.

> Natomiast do pisania pod WinAPI nie
> potrzebuję wymówki.

Albowiem?

do góry

W dniu 27-01-2012 17:27, Sebastian Biały pisze:
> On 2012-01-26 23:56, Robert Zemła wrote:
>>> Naprawdę chcesz z tego wyciągnąć tezę że to co było dobre w czasach 386
>>> dzisiaj jest również doskonałe?
>> Nie, ale idąc tym tropem wychodzi że to cały Windows jest zły.
>
> Nie idź dalej tym tropem. WinAPI jest złe. Jest ciężkie, niespójne,
> zagmatwane, czerpie całymi garściami z lat 80, ma się nijak do nowych
> języków i technik programistycznych. To niskopoziomowe API systemu, nie
> istnieje żaden argument aby z niego korzystać wprost poza jakimiś
> promilami aplikacji wymagającymi ekstremalnych szybkości w brzegowych
> zastosowaniach.

Przesadzasz :-) WinAPI nie jest złe a już na pewno nie jest niespójne.
Bywa czasem upierdliwe, wymaga użycia innych technik programowania i
sporej wiedzy o systemie. To są chyba główne powody dlaczego wielu go
nie lubi.

>
>> Prawdę mówiąc nie chciał bym pracować z człowiekiem który by nie
>> wiedział ile bajtów ma DWORD.
>
> Prawdę mówiąc nie chciałbym pracować z człowiekiem dla którego napisanie
> prostego programu do komunikacji po COM wymaga znajomości szczegołów
> definicji DWORD. *Abstrakcja* jest ważniejsza od znajomości szczegołów
> implementacji choćby z powodu przenośności, ba, nawet w samym Windowsie.

O ile dane będą przesyłane otwartym tekstem, to może takiemu
programiście udało by się coś napisać.

>
>> Po co programista ma w ogóle wiedzieć jak działa komputer?
>
> Przesadzasz. Rzecz w tym po co programista ma wiedzieć jak działa
> allokator pamięci i co zrobic żeby strcpy się nie wysypało. Otóż nie
> powinien zaprzatać sobie głowy duperelami bo jego celem jest napisanie
> kodu który działa. Wydajność, zajętość pamięci są trzeciorzędne,
> szczególnie dla początkujących. Wazniejsze jest posiadanie zestawu
> działających kontenerow, obiektowej biblioteki GUI, łatwych do użycia
> komponentów, bibliotek zapewniających wsparcie w konkretnych zadaniach.
>
No tak. Nie ważne jak, ważne że działa. Potem niech się ewentualnie
martwi ten co po nim ten kod przejmie. Nie przekonasz mnie że
programista nie musi mieć choćby minimum wiedzy komputerze. No chyba że
mówimy o programiście HTML'a czy PHP'a.

>> Wystarczy że wie w jakiej kolejności trzeba wystukać komendy na
>> klawiaturze (albo gdzie i jak kliknąć myszką) żeby pojawiło się okienko
>> i guzik.
>
> Tak działa Delphi. Początkujący, pozostawiony na pastwę tego środowiska
> zaczyna pisać ciało funkcji w onclikach i tak juz mu zostaje. Dlatego
> nie wolno pokazywac go początkującym uczącym się samodzielnie bo uczy
> mimowolnie złych praktyk.

Nie tylko Delphi, aczkolwiek pisząc to przypomniała mi się pewna
sytuacja której byłem świadkiem. W wielkim skrócie człowiek nie był
wstanie wdrożyć pewnej funkcji do programu bo komponent z którego
korzystał nie oferował takiej funkcjonalności.

>
>> Co zrobi taki programista któremu "coś" nie zadziała?
>
> Wiele rzeczy może, ale w WinAPI znacznie częściej nie będzie mu działać
> i znacznie gorzej będzie debugować dlaczego.

Zawsze można zrobić błąd. Jeżeli człowiek umie napisać kod
wykorzystujący bezpośrednio WinAPI to z debugowaniem tym bardziej nie
będzie mieć problemu.

>
>> Ah te obiektowe środowiska... ile rzeczy można zrobić myszką... :-)
>
> Pomyliłeś programowanie obiektowe z RAD.
>

Napisałeś "obiektowe środowiska". Natomiast nie widzę związku z brakiem
możliwości połączenia programowania obiektowego i WinAPI

>> Natomiast do pisania pod WinAPI nie
>> potrzebuję wymówki.
>
> Albowiem?

Programuję w tym od lat, napisałem sporo różnych aplikacji, uzbierałem
sobie pokaźną bibliotekę przeróżnych klas (do tego typu programów używam
C++, dawniej MASM32), w związku z tym do pisania prostych (i brzydkich)
programów nie potrzeba mi nic więcej.

Podsumowując nie jestem wrogiem nowocześniejszych technik programowania,
nie zgadzam się tylko że WinAPI jest złe i że programista nie musi znać
się na tym co robi.

pozdrawiam,

do góry