ale nudzicie koledzy... mam zagadnienie: na ile ksiażka Petzolda
Programowanie Windows jest aktualna? w środowisku Windows Vista/7?

do góry

>na ile ksiażka Petzolda
>Programowanie Windows jest aktualna? w środowisku Windows Vista/7?

Z tego co mam chyba ostatnie polskie wydanie II
(tłumaczenie Programing Windows 5th ed. /1999)
to chyba ostatnia książka opisująca "niskopoziomowy"
dostęp do Windows.
Zasady się nie zmieniły, tylko trochę więcej parametrów przy wywołaniu
bibliotek ;)

do góry

identifikator: 20040501 <N...@g...pl> napisał(a):

> ale nudzicie koledzy... mam zagadnienie: na ile ksiażka Petzolda
> Programowanie Windows jest aktualna? w środowisku Windows Vista/7?

Wszedzie gdzie proponowalem pisanie aplikacji w winapi to patrzyli sie
na mnie jak na idiote - bo sami nie potrafili :) Tak czy siak, wiedzy z
zakresu win api nie spozytkowalem z korzysciami dla siebie lubi innych,
wiec od kilku lat sukcesywnie zapominam. Wiec pytanie czy w ogole
warto, moze, zwlaszcza dzis, od razu lepiej QT?

Czy jest aktualna? Stare aplikacje dzialaja, wiec w jakims sensie na
pewno jest. Ale od tamtego czasu doszlo wiele rozszerzen. Na pewno
mozna od niej zaczac a potem dokumentacja, chociaz zdaje sie ze
petzold gdziesz na poczatku ksiazki pisze "mam nadzieje ze
przeczytales dokumentacje", a moze to pisal Toth... :D

Pozdrawiam



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On Mon, 30 Jan 2012 19:48:58 +0100, "identifikator: 20040501"
<N...@g...pl> wrote:

>ale nudzicie koledzy... mam zagadnienie: na ile ksiażka Petzolda
>Programowanie Windows jest aktualna? w ?rodowisku Windows Vista/7?

Zainteresowalbym sie raczej ksiazka -- Windows, programowanie
systemowe (wyd. Helion), jest o 11 lat mlodsza!

Osobiscie, jesli chodzi o technologie unikam ksiazek starszych niz 4
lata, co innego teoria, tu ksiazki i sprzed 30 lat czyta sie swietnie.

milego dnia, hej

--
Moja wyprzedaz wszystkiego: ksiazki, plyty, filmy.
http://garaz.pl.hostingasp.pl/

do góry

On 2012-01-31, M.M. <m...@g...pl> wrote:
> identifikator: 20040501 <N...@g...pl> napisał(a):
>
>> ale nudzicie koledzy... mam zagadnienie: na ile ksiażka Petzolda
>> Programowanie Windows jest aktualna? w środowisku Windows Vista/7?
>
> Wszedzie gdzie proponowalem pisanie aplikacji w winapi to patrzyli sie
> na mnie jak na idiote - bo sami nie potrafili :)

Niespecjalnie jest co umieć. Trzeba czysto mechanicznie zapamiętać
fafset funkcji z echdziesięcioma parametrami. Każdy rozsądny programista
raczej weźmie jakąś gotową bibliotekę GUI, która ułatwia pracę. Myślisz
że dlaczego powstało MFC?

--
Secunia non olet.
Stanislaw Klekot

do góry

Stachu 'Dozzie' K. <d...@g...eat.some.screws.spammer.invalid> napisał(a):

> On 2012-01-31, M.M. <m...@g...pl> wrote:
> > identifikator: 20040501 <N...@g...pl> napisał(a):
> >
> >> ale nudzicie koledzy... mam zagadnienie: na ile ksiażka Petzolda
> >> Programowanie Windows jest aktualna? w środowisku Windows Vista/7?
> >
> > Wszedzie gdzie proponowalem pisanie aplikacji w winapi to patrzyli sie
> > na mnie jak na idiote - bo sami nie potrafili :)
>
> Niespecjalnie jest co umieć. Trzeba czysto mechanicznie zapamiętać
> fafset funkcji z echdziesięcioma parametrami.
Ale co to za programowanie w winapi? Jestem dokladnie przeciwnego zdania.
Najpierw trzeba poznac glowne idee programowania w winapi. Potem trzeba
napisac duzo aplikacji zeby nabrac wprawy. A gdy sie zapomni jak sie funkcja
nazywala albo jakie miala parametry to od tego jest dokumentacja.

> Każdy rozsądny programista raczej weźmie jakąś gotową bibliotekę GUI
> która ułatwia pracę.
Winapi to nic innego jak (miedzy innymi) jakas gotowa biblioteka GUI
ktora ulatwia prace. Winapi jest bardzo dobre do tego do czego zostalo
stworzone. Dostarcza wszystkie podstawowe kontrolki GUI, niektore
mozna narysowac w graficznym edytorze zamiast wklepywac recznie...
W czasach gdy aplikacje napisane w winapi wydajnie smigaly, to konkurencyjne
gnomy czy kde co chwile padaly, albo nie mogly pracowac z powodu braku
zasobow i nie wspolpracowaly z urzadzeniami - to chyba o czyms swiadczy.

Nie porownujmy z tym co jest teraz. Ale jesli aplikacja jest na tyle
prosta ze moze sie zadowolic (nie az tak) skapym arsenalem gotowych
elementow z winapi to nadal mozna efektywnie takie aplikacje robic.

> Myślisz że dlaczego powstało MFC?
Myslisz ze dlaczego MFC upadlo? :D

MFC to bardzo chamska, prawie jeden do jeden, nakladka na winapi. Nie
ulatwia programowania, a bez generatorow kodu skutecznie je utrudnia.
Nie widzialm jeszcze nigdy zeby wiadomy generator na wiekszych projektach
pracowal stabilnie. Kiedys generator skasowal mi zawartosc wszystkich
plikow w projekcie i potem puste pliki zapisal na dysk. Nie bylo mozliwosci
cofniecia zmian ani odzyskania kodu. Po tym incydencie przestalem
calkowicie uzywac MFC - recznie w winapi o niebo prosciej.

Sa jeszcze inne zalety gui z winapi. Po pierwsze nigdy nie mialem problemu
z uruchamianiem swoich aplikacji napisanych w gui winapi pod linuxem.
Napisane w visual basicu, w buidlerze w owl czy w delphi nie chcialy
dzialac. Kolejna zaleta: bardzo stary kod kompiluje nowym kompilatorem na
zupelnie inna architekture 64bit i to nadal dziala. Ile ludzie mieli
problemow z samym uruchamianiem np. srodowiska buildera na nowszych
systemach i procesorach? Jak sie zachowywaly aplikacje napisane w
visual basic 5 albo 6?



Pozdrawiam

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 2012-01-31, M.M. <m...@g...pl> wrote:
[...]
>> Każdy rozsądny programista raczej weźmie jakąś gotową bibliotekę GUI
>> która ułatwia pracę.
> Winapi to nic innego jak (miedzy innymi) jakas gotowa biblioteka GUI
> ktora ulatwia prace.

WinAPI to nic innego jak API systemu Windows. Niezbędna rzecz, żeby
zrobić cokolwiek, chociaż niekoniecznie trzeba zaraz w tym paprać
samemu. Zwykle lepiej zlecić coś gotowej bibliotece dostarczającej
abstrakcje.

> Winapi jest bardzo dobre do tego do czego zostalo
> stworzone.

WinAPI zostało stworzone do dostarczenia programiście API do systemu
operacyjnego. I owszem, bardzo dobrze _dostarcza_ to API. Tylko że samo
dostarczone API jest miernej jakości. Porównaj sobie lepiej jak wygląda
API uniksowe (mówię tu generalnie o funkcjach komunikacji z OS-em, a nie
o samym GUI). Tam nawet nie ma podziału na "usługę" i "program
użytkownika", bo i po co? Zysku z tego właściwie żadnego, a dodatkowy
kłopot przy pisaniu daemona i przy zarządzaniu nim.

> Dostarcza wszystkie podstawowe kontrolki GUI, niektore
> mozna narysowac w graficznym edytorze zamiast wklepywac recznie...
> W czasach gdy aplikacje napisane w winapi wydajnie smigaly, to konkurencyjne
> gnomy czy kde co chwile padaly, albo nie mogly pracowac z powodu braku
> zasobow i nie wspolpracowaly z urzadzeniami - to chyba o czyms swiadczy.

To znaczy kiedy? Za czasów GNOME 0.4beta1?

> Sa jeszcze inne zalety gui z winapi. Po pierwsze nigdy nie mialem problemu
> z uruchamianiem swoich aplikacji napisanych w gui winapi pod linuxem.

No ja miałem. Głównie takie, że aplikacje napisane pod WinAPI nie
kompilują się bez przepisania, bo oczywiście binarnej kompatybilności
nie ma.

--
Secunia non olet.
Stanislaw Klekot

do góry

Stachu 'Dozzie' K. <d...@g...eat.some.screws.spammer.invalid> napisał(a):

> On 2012-01-31, M.M. <m...@g...pl> wrote:
> [...]
> >> Każdy rozsądny programista raczej weźmie jakąś gotową bibliotekę GUI
> >> która ułatwia pracę.
> > Winapi to nic innego jak (miedzy innymi) jakas gotowa biblioteka GUI
> > ktora ulatwia prace.
>
> WinAPI to nic innego jak API systemu Windows. Niezbędna rzecz, żeby
> zrobić cokolwiek, chociaż niekoniecznie trzeba zaraz w tym paprać
> samemu. Zwykle lepiej zlecić coś gotowej bibliotece dostarczającej
> abstrakcje.
WinAPI dostarcza pewien zestaw abstrakcji, np. uchwyty do obiektow GDI,
standardowe funkcje ktore rozpoznaja na rzecz jakiego uchwytu zostaly
wywolane, abstrakcje okna, abstrakcje urzadzenia graficznego, czcionki,
gotowe frameworki aplikacji jedno- i wielo-dokumentowej, zestaw standardowych
kontrolek, zasoby z mozliwoscia wizualnego projektowania - troche tego jest.
Ale z winapi jest jak z matematyka. Jesli ktos nie nauczyl sie pochodnych,
to nie skorzysta z wzorow na calki, pomimo ze zna te wzory na pamiec.
Trzeba napisac troche aplikacji, nabrac wprawy i potem okazuje sie ze praca
w winapi moze byc w miare efektywna. W miare bo wiadomo ze nie dorowna np.
najnowszej wersji QT.


> WinAPI zostało stworzone do dostarczenia programiście API do systemu
> operacyjnego. I owszem, bardzo dobrze _dostarcza_ to API. Tylko że samo
> dostarczone API jest miernej jakości.
Niezgadzam sie. Gdy nabralem wprawy w poslugiwaniu sie winapi to nigdy nie
mialem sytuacji ze cos nie dzialalo, albo ze cos robi sie koszmarnie
trudno i wolno i przy okazji popelnia sie duzo bledow. Na pewno w innych
srodowiskach mialem problemow wiecej. Do WinApi potrzebowalem tylko
kompilator z wiersza polecenia, notatnik i zawsze aplikacje poprawilem,
skompilowalem i uruchomilem.

> Porównaj sobie lepiej jak wygląda API uniksowe (mówię tu generalnie o
> funkcjach komunikacji z OS-em, a nie o samym GUI).
Ale jak mozna takie porownanie sensownie zrobic? Z czym mam porownywac
CreateWindow z WinApi jesli z unixa nie mam analizowac GUI? Chyba
rozmawiamy o czym innym. Moze chcesz powiedziec ze jak zlosliwy
programista przekaze bzdurne agrumenty w API unixa to unix padnie
rzadziej niz Windows? To jakby jakosc implementacji a nie jakosc
API. Windows wiadomo slynal z braku odpornosci na wszelkie bledy
czy ataki. Pewne interfejsy z API unix/linux bardziej lubie niz
z WinAPI ale nie na tyle zeby WinAPI uznac za cos nieudanego.

> Tam nawet nie ma podziału na "usługę" i "program
> użytkownika", bo i po co? Zysku z tego właściwie żadnego, a dodatkowy
> kłopot przy pisaniu daemona i przy zarządzaniu nim.
Jest potrzebne obycie. Ja robilem copy-paste powtarzajacego sie
kodu we wszystkich uslugach w jakies 60s i potem normalnie pisalem.

> > Dostarcza wszystkie podstawowe kontrolki GUI, niektore
> > mozna narysowac w graficznym edytorze zamiast wklepywac recznie...
> > W czasach gdy aplikacje napisane w winapi wydajnie smigaly, to
> > konkurencyjne
> > gnomy czy kde co chwile padaly, albo nie mogly pracowac z powodu braku
> > zasobow i nie wspolpracowaly z urzadzeniami - to chyba o czyms swiadczy.
> To znaczy kiedy? Za czasów GNOME 0.4beta1?
Z czasow windows 95. Na windows 95 bylo duzo aplikacji graficznych bazujacych
na winapi i mozna w nich bylo pracowac. Oczywiscie z pewnymi problemami i nie
mozna bylo systemu narazac na celowe ataki, jednak szlo pracowac. W owczesnych
odpowiednikach na linuxie nie bylo mowy.


> > Sa jeszcze inne zalety gui z winapi. Po pierwsze nigdy nie mialem problemu
> > z uruchamianiem swoich aplikacji napisanych w gui winapi pod linuxem.
>
> No ja miałem. Głównie takie, że aplikacje napisane pod WinAPI nie
> kompilują się bez przepisania, bo oczywiście binarnej kompatybilności
> nie ma.
Wszystkie moje aplikacje napisane z GUI WinAPI dzialaja pod linuxem w
wersji binarnej :) Oczywiscie jeszcze z uzyciem wine. Aplikacji z
delphi, z visual basica, z borlnad buildera z reguly nie udawalo mi sie
uruchomic. Samo IDE buildiera czy delphi nie dawalo sie uruchomic na
niektorych kombinacjach (procesor - wersja windows), a co dopiero linux.
Trzeba tutaj pochwalic MFC, pod wine aplikacje napisane w MFC tez nie
sprawialy problemow.

Pozdrawiam!




--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 2012-01-31, M.M. <m...@g...pl> wrote:
> Stachu 'Dozzie' K. <d...@g...eat.some.screws.spammer.invalid> napisał(a):
>
>> On 2012-01-31, M.M. <m...@g...pl> wrote:
>> [...]
>> >> Każdy rozsądny programista raczej weźmie jakąś gotową bibliotekę GUI
>> >> która ułatwia pracę.
>> > Winapi to nic innego jak (miedzy innymi) jakas gotowa biblioteka GUI
>> > ktora ulatwia prace.
>>
>> WinAPI to nic innego jak API systemu Windows. Niezbędna rzecz, żeby
>> zrobić cokolwiek, chociaż niekoniecznie trzeba zaraz w tym paprać
>> samemu. Zwykle lepiej zlecić coś gotowej bibliotece dostarczającej
>> abstrakcje.
> WinAPI dostarcza pewien zestaw abstrakcji, np. uchwyty do obiektow GDI,
> standardowe funkcje ktore rozpoznaja na rzecz jakiego uchwytu zostaly
> wywolane, abstrakcje okna, abstrakcje urzadzenia graficznego, czcionki,
> gotowe frameworki aplikacji jedno- i wielo-dokumentowej, zestaw standardowych
> kontrolek, zasoby z mozliwoscia wizualnego projektowania - troche tego jest.

To samo można powiedzieć o API X11. I nie znaczy to, że od razu jest to
API wysokopoziomowe czy wygodne.

>> WinAPI zostało stworzone do dostarczenia programiście API do systemu
>> operacyjnego. I owszem, bardzo dobrze _dostarcza_ to API. Tylko że samo
>> dostarczone API jest miernej jakości.
> Niezgadzam sie.

To się niezgadzaj. Fakt jest taki, że w WinAPI jest burdel na kółkach,
a funkcje miewają po paręnaście parametrów, z czego w większości się
wstawia NULL i 0. Nie tak wygląda przemyślane i wygode API.

>> Porównaj sobie lepiej jak wygląda API uniksowe (mówię tu generalnie o
>> funkcjach komunikacji z OS-em, a nie o samym GUI).
> Ale jak mozna takie porownanie sensownie zrobic? Z czym mam porownywac
> CreateWindow z WinApi jesli z unixa nie mam analizowac GUI?

Czy dla ciebie WinAPI to tylko zestaw funkcji do budowania interfejsu
graficznego? Jeśli tak, to możemy w tym miejscu zakończyć dyskusję.

> Chyba
> rozmawiamy o czym innym.

Dlatego zaznaczyłem, że zmieniam grunt. Zostawiamy GUI i przechodzimy do
całokształtu komunikacji programów użytkownika z systemem operacyjnym.

> Moze chcesz powiedziec ze jak zlosliwy
> programista przekaze bzdurne agrumenty w API unixa to unix padnie
> rzadziej niz Windows?

Nie, gdzie niby tak twierdzę? Ja twierdzę, że API uniksów jest lepiej
przemyślane. Przykładami są tworzenie procesów (usługa-program dla
użytkownika) i obsługa gniazd i plików (w uniksach otwarty socket jest
praktycznie takim samym deskryptorem, co otwarty plik na dysku albo
STDIN/STDOUT).

> To jakby jakosc implementacji a nie jakosc
> API. Windows wiadomo slynal z braku odpornosci na wszelkie bledy
> czy ataki. Pewne interfejsy z API unix/linux bardziej lubie niz
> z WinAPI ale nie na tyle zeby WinAPI uznac za cos nieudanego.

To przyjrzyj się jeszcze raz, jak często wywołujesz funkcje mające po
paręnaście parametrów i jak jest zorganizowana obsługa sieci i plików.

>> Tam nawet nie ma podziału na "usługę" i "program
>> użytkownika", bo i po co? Zysku z tego właściwie żadnego, a dodatkowy
>> kłopot przy pisaniu daemona i przy zarządzaniu nim.
> Jest potrzebne obycie. Ja robilem copy-paste powtarzajacego sie
> kodu we wszystkich uslugach w jakies 60s i potem normalnie pisalem.

Tylko po *uj, skoro nie ma żadnego zysku na takiej organizacji?

>> > Dostarcza wszystkie podstawowe kontrolki GUI, niektore
>> > mozna narysowac w graficznym edytorze zamiast wklepywac recznie...
>> > W czasach gdy aplikacje napisane w winapi wydajnie smigaly, to
>> > konkurencyjne
>> > gnomy czy kde co chwile padaly, albo nie mogly pracowac z powodu braku
>> > zasobow i nie wspolpracowaly z urzadzeniami - to chyba o czyms swiadczy.
>> To znaczy kiedy? Za czasów GNOME 0.4beta1?
> Z czasow windows 95. Na windows 95 bylo duzo aplikacji graficznych bazujacych
> na winapi i mozna w nich bylo pracowac. Oczywiscie z pewnymi problemami i nie
> mozna bylo systemu narazac na celowe ataki, jednak szlo pracowac. W owczesnych
> odpowiednikach na linuxie nie bylo mowy.

Jeszcze raz, ale od początku i powoli. O czym ty w ogóle tu mówisz?

>> > Sa jeszcze inne zalety gui z winapi. Po pierwsze nigdy nie mialem problemu
>> > z uruchamianiem swoich aplikacji napisanych w gui winapi pod linuxem.
>>
>> No ja miałem. Głównie takie, że aplikacje napisane pod WinAPI nie
>> kompilują się bez przepisania, bo oczywiście binarnej kompatybilności
>> nie ma.
> Wszystkie moje aplikacje napisane z GUI WinAPI dzialaja pod linuxem w
> wersji binarnej :) Oczywiscie jeszcze z uzyciem wine. Aplikacji z
> delphi, z visual basica, z borlnad buildera z reguly nie udawalo mi sie
> uruchomic.

A widzisz. U mnie odwrotnie. Anecdotal evidence.

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu 31.01.2012 13:07, M.M. pisze:
> zestaw standardowych
> kontrolek, zasoby z mozliwoscia wizualnego projektowania - troche tego jest.
Ubogi zestaw dodajmy.

> Trzeba napisac troche aplikacji, nabrac wprawy i potem okazuje sie ze praca
> w winapi moze byc w miare efektywna. W miare bo wiadomo ze nie dorowna np.
> najnowszej wersji QT.
Tym trochę starszym tez nie.

> Wszystkie moje aplikacje napisane z GUI WinAPI dzialaja pod linuxem w
> wersji binarnej :) Oczywiscie jeszcze z uzyciem wine. Aplikacji z
> delphi, z visual basica, z borlnad buildera z reguly nie udawalo mi sie
> uruchomic. Samo IDE buildiera czy delphi nie dawalo sie uruchomic na
> niektorych kombinacjach (procesor - wersja windows), a co dopiero linux.
http://grota.be/~michoo/smieci/delphi.png (2007 rok)

Btw: w ogóle najlepiej pisać w WinAPI i MASMie - proste programy
wynikowe mają potem np 1-2kB. Piękna sprawa jak kod wynikowy jest
mniejszy od ikony... Tylko zazwyczaj nie o to chodzi w programowaniu.

--
Pozdrawiam
Michoo

do góry