Schönen Tag zusammen. Ich möchte mich mit der Windows Programmierung
beschäftigen und denke da konkret daran mir den Petzold zu beschaffen,
gibts ja noch gebraucht.
Lohnt sich die Anschaffung oder ist das Werk zu sehr in die Jahre
gekommen? Es könnte ja sein, dass für die aktuellen Windows Versionen
z.B. Win7 oder Win10 schon ganz anders programmiert wird. Oder dass die
Quellcodes aus dem Buch einfach nicht mehr auf den neuen
Betriebssystemen laufen weil sich eben einiges geändert hat oder in
Zukunft noch stärker ändern wird.
Wie ist eure Meinung dazu?
Im Petzold ist beschrieben, wie man Programme mit graphischer Oberfläche
in C per Win32-API schreibt. Das ist extrem umständlich und macht
deshalb heutzutage niemand mehr. Lern dafür lieber ein GUI-Framework wie
Qt oder Windows Forms bzw. was in Deiner Lieblings-Programmiersprache
üblich ist.
Der Petzold ist nur interessant, wenn Du Dich aus persönlichem Interesse
für die Grundlagen interessierst oder selber ein GUI-Framework schreiben
willst.
Wenn es nicht um graphische Oberflächen sondern Systemprogrammierung
geht, dazu gibt es andere und aktuellere Bücher, z.B. "Windows System
Programming" von Johnson M. Hart oder "Windows via C/C++" von Jeffrey
Richter.
Natürlich kann man den Petzoldt nach wie vor verwenden (sofern man ein
32-Bit-Ausgabe erwischt), aber damit erwirbt man kaum anderweitig
verwertbares Inselwissen. Obendrein ist der Weg zum funktionierenden
Windows-Programm sehr, sehr steinig.
Die wenigen reinen in C geschriebenen Win32-Anwendungen, die es so gibt,
die erkennt man an der ... sagen wir mal sehr grottigen GUI. Der
Aufwand, überhaupt eine GUI hinzubekommen, ist so groß, daß praktisch
alle entsprechenden Programmierer dann nicht mehr Aufwand dort
hineinstecken ...
Nicht nur deswegen verwendet praktisch niemand, der Windows-Programme
schreibt, diesen Ansatz, sondern nutzt irgendwas komfortableres.
Wie z.B. C++ zusammen mit einer GUI-Klassenbibliothek.
Da gäbe es die (schon lange als veraltet geltende) MFC von Microsoft
höchstselbst, oder andere, potentiell plattformübergreifende Ansätze wie
wxWidgets oder Qt.
Und dann gibt es noch das .Net-Geraffel von MS, aber das setzt auf dazu
passenden Programmiersprachen (C#, VB.Net und etwas, was sich "C++"
nennt, aber nicht ist) auf.
Wenn man schon über andere Programmiersprachen redet, darf natürlich
auch Delphi nicht unerwähnt bleiben, oder auch Java ...
Die Frage ist natürlich auch, was programmiert werden soll. Geht es eher
um Programmieren tief im System drin und ganz spezifisch für Windows
oder eher "gewöhniche" GUI-Anwendungen? Für letzteres empfehlen sich
dann eher die von Rufus genannten Dinge, von denen einige auch nicht
Windows-spezifisch sind, sondern auch auf einem MAC oder einem
Linux-System (vom RasPi bis zum Mainframe) verwendet werden können.
Nun, wenn es um Dinge "tief im System drin" ginge, dann dürfte der
Petzoldt völlig ungeeignet sein. Dann dürften aber auch GUI-Libraries
eher nachrangig sein; für Dienste, Devicetreiber etc. ist das kaum von
Relevanz.
Wenn Dennis noch fast keine Programmiererfahrung
hat und nur Programme für den Hausgebrauch programmieren
will, würde ich von C, C++ usw. abraten.
Da gibt's ja genug andere schöne Sprachen, die wenig kosten
bzw. kostenlos sind. Vor allem sind die wesentlich leichter
zu erlernen.
Ich persönlich arbeite gerne mit XProfan.
(www.Profan.de).
Ist alles in deutsch und leicht zu erlernen. Der Sprachschatz reicht
für alle gängigen GUI-Elemente.
Die etwas älteren Versionen gibt es sogar kostenlos für den
Einstieg.
Ein weiterer Kandidat wäre auch PureBasic.
Warum nicht die kostenlosen Express Versionen von M$ für C, C# und C++?
Da gibt es jede Menge Beispiele und das komplette SDK. Wer möchte, kann
sich auch das DirectX SDK dazu installieren oder mit PhysX
experimentieren, wenn man sich das Zeugs von NVidia dazukippt.
C/C++ ist gut wenn du auch was in Richtung mikrocontroller machen
möchtest. Programme mit wenig GUI kann man schon mit der WinAPI bauen,
vielleicht grottige Optik aber dafür sehr schnell. Der Weg ist steinig,
aber mit dem VS hat man einen guten Debugger und kann gut C lernen.
Ansonsten etwas verwenden was dich beruflich weiterbringt, Exoten
gehören sicher nicht dazu.
Auch wenn ich mich damit persönlich noch schwer tue: JavaScript mit
Node.js und WebBrowser als Frontend. Man muss sich da allerdings auch
erst durch einige Libs hangeln bis man da alles nötige zusammen hat.
Rufus Τ. F. schrieb:> Natürlich kann man den Petzoldt nach wie vor verwenden (sofern man ein> 32-Bit-Ausgabe erwischt), aber damit erwirbt man kaum anderweitig> verwertbares Inselwissen.
Oha. Bei ca. 90% Marktanteil bei den Desktops kommt mir das irgendwie
doch wie eine SEHR GROSSE Insel vor, irgendwas in der Größenordnung von
Pangea...
> Obendrein ist der Weg zum funktionierenden> Windows-Programm sehr, sehr steinig.
So schlimm ist es nun auch wieder nicht. Es gibt schätzungsweise nur
zwei Dutzend Funktionen, um irgendwas auf einen DC zu zeichnen. Und,
viel wichtiger: man muss die meisten davon auch kennen, wenn man in
irgendwelchen "fortgeschritteneren" Frameworks irgendwas frei
definiertes zeichnen will. Oder auch einen Drucker mit ordentlichem
Futter versorgen will. Und nicht zuletzt: die meisten Konzepte des
Win32-API finden sich in der einen oder anderen Form auch in
"fortgeschritteneren" Frameworks wieder, hier natürlich dann
"OO-translated"...
Was die Steuerelemente betrifft, sind die grundlegendsten auch via C
(oder auch Asm, hihi) leicht erreich- und benutzbar. Was allerdings
schwer fällt, ist die Designzeit. Da gibt's dann keinen komfortablen
WYSIWYG-Editor. Das allerdings ist auch bei den "fortgeschritteneren"
Frameworks immer noch nicht unbedingt die Regel...
> Nicht nur deswegen verwendet praktisch niemand, der Windows-Programme> schreibt, diesen Ansatz, sondern nutzt irgendwas komfortableres.
Ähemm. Eigentlich ist es doch eher NUR deswegen... Reine Faulheit, die
grundlegendste Eigenschaft eines jeden Programmierers, einschließlich
meiner Wenigkeit wohlgemerkt...
Es muss schon einen Anreiz geben, um der Faulheit adé zu sagen. Z.B.
Ressourcenknappheit des Zielsystems. Das kommt richtig gut, ist
allerdings bei heutigen Desktoprechnern eher selten zu erwarten. Da kann
ich also heute in den meisten Fällen auch locker faul sein.
> Und dann gibt es noch das .Net-Geraffel von MS, aber das setzt auf dazu> passenden Programmiersprachen (C#, VB.Net und etwas, was sich "C++"> nennt, aber nicht ist) auf.
Nein, das nennt sich nicht "C++". Das MS-"C++" ist wirklich C++. Was du
meinst, aber mangels hinreichender Kompetenz nicht korrekt ausdrücken
konntest, nennt sich "C++/CLI". Ist allerdings auch weitgehend C++, nur
mit diversen Erweiterungen der Sprache, die halt dafür gut sind, auf das
".Net-Geraffel" einfach und komfortabel zugreifen zu können. So lange du
diese Erweiterungen nicht benutzt, ist es eben einfach nur C++. Einige,
sehr wenige Ausnahmen bestätigen hier wie immer die Regel.
> Wenn man schon über andere Programmiersprachen redet, darf natürlich> auch Delphi nicht unerwähnt bleiben, oder auch Java ...
Delphi ist geil. Delphi hat zehn Jahre vor .Net gezeigt, wie komfortable
Anwendungsentwicklung geht (und ObjectPascal ist obendrein eine tolle
Sprache). Aber Delphi ist leider tot. Bzw. wurde von Damagern
umgebracht, aber egal, tot ist tot.
Und Java... Ja, Java war eigentlich schon bei der Geburt tot. Stirbt
aber irgendwie sehr langsam... Das Problem bei Java war meiner Meinung
nach, dass die furchtbare Sprache sehr starr mit dem Backend verknüpft
war.
Diesen Fehler hat Winzigweich nicht wiederholt und .Net für viele
Sprachen nutzbar gemacht. Damals gab es halt noch Leute bei Microsoft,
die noch irgendwas geblickt haben. Leider auch vorbei, diese Zeit...
c-hater schrieb:> Oha. Bei ca. 90% Marktanteil bei den Desktops kommt mir das irgendwie> doch wie eine SEHR GROSSE Insel vor, irgendwas in der Größenordnung von> Pangea...
O nein. Man begreift damit nichts von dem, was GUI-Frameworks machen.
Wer GUI-Programme mit C und der Win32-API à la Petzoldt schreibt ... ist
ähnlich progressiv aufgestellt wie jemand, der meint, µCs ausschließlich
in Assembler programmieren zu müssen.
Natürlich ist es sinnvoll, beides mal gesehen zu haben, um zu begreifen,
warum man sich das nicht antun will, und um zu begreifen, was
GUI-Toolkits (bzw. Hochsprachen auf dem µC) machen. Als
Grundlagenwissen ist beides nicht zu verachten. Aber für das tägliche
Programmiergeschäft ist beides gleichermaßen ungeeignet, auch wenn
gewisse Forentrolle sich in ewiglangen Diskussionen über das Gegenteil
auslassen müssen.
> Nein, das nennt sich nicht "C++". Das MS-"C++" ist wirklich C++. Was du> meinst, aber mangels hinreichender Kompetenz nicht korrekt ausdrücken> konntest, nennt sich "C++/CLI".
Du solltest lesen lernen. Das, was nötig ist, um das .net-Geraffel zu
nutzen, ist nicht C++, sondern eine MS-Perversion namens "Managed C++"
bzw. "C++/CLI".
Natürlich hat MS auch echtes C++ im Angebot - aber das hat dann nichts
mit dem .net-Geraffel zu tun.
Was an .NET-Geraffel soll denn bitte Geraffel sein?
Die fehlende Portierbarkeit? Dass es von MS stammt?
Ich halte .NET für kein Geraffel. Viel schneller kann man in
Windowsprogrammierung auch gar nicht einsteigen, wie mit .NET und sagen
wir mal C#.
Rufus Τ. F. schrieb:> Wer GUI-Programme mit C und der Win32-API à la Petzoldt schreibt ... ist> ähnlich progressiv aufgestellt wie jemand, der meint, µCs ausschließlich> in Assembler programmieren zu müssen.
Also ich mache das sogar in Zeiten von .net noch so.
Mit Codeblocks und ResEdit hat man recht schnell mit wenig Code eine
nette GUI erzeugt. Solange es sich um Standard Steuerlemente wie
Buttons, Checkbox, Richtext etc handelt sehe ich keine Sinn darin meiner
GUI eine 5 MB lib ranzuhängen. Mit ResEdit klickt man sich sein GUI ganz
normal zusammen wie in VisualStudio und hat am ende eine exe die nur ein
paar KB groß ist und keinerlei Runtime benötigt.
Eddy C. schrieb:> Ich halte .NET für kein Geraffel. Viel schneller kann man in> Windowsprogrammierung auch gar nicht einsteigen, wie mit .NET und sagen> wir mal C#.
Umgedreht: Was ist an .NET KEIN Geraffel? Geht ja schon mit der
schrecklichen Abhängigkeit der ganzen Versionen los.
Man kann es etwa so sagen: C# ist das PHP der "höheren"
Programmiersprachen.
Dass sich .NET weiterentwickelt, steht ausser Frage. Aber von welchen
"Abhängigkeiten" Du sprichst? Eher lese ich aus Deinem zusammenhanglosen
Geschreibsel heraus, dass Du auch nur unbegründet abledern willst. MS
muss Scheisse sein und wird es daher auch immer bleiben!
Eine Alternative darf gerne genannt werden! Mein Weg war Borland C++ und
auch Builder, mit Ausflügen nach Delphi und da schloss sich VS/C#/.NET
eigentlich recht nahtlos und unkompliziert an.
c-hater schrieb:> Delphi ist geil. Delphi hat zehn Jahre vor .Net gezeigt, wie komfortable> Anwendungsentwicklung geht (und ObjectPascal ist obendrein eine tolle> Sprache). Aber Delphi ist leider tot. Bzw. wurde von Damagern> umgebracht, aber egal, tot ist tot.
Wer mal mit der VCL in Delphi oder C++ gearbeitet hat (oder noch älter
ist und Turbo Pascal kennt), wird viel im .Net-Framework wiedererkennen.
Ein und derselbe Architekt: Anders Hejlsberg.
Das Problem bei Delphi/C++-Builder ist und war/waren/sind der/die
Eigentümer.
> Und Java... Ja, Java war eigentlich schon bei der Geburt tot. Stirbt> aber irgendwie sehr langsam... Das Problem bei Java war meiner Meinung> nach, dass die furchtbare Sprache sehr starr mit dem Backend verknüpft> war.
Scala oder wer https://xkcd.com/297/ übrig hat: Clojure
Rufus Τ. F. schrieb:> Du solltest lesen lernen. Das, was nötig ist, um das .net-Geraffel zu> nutzen, ist nicht C++, sondern eine MS-Perversion namens "Managed C++"> bzw. "C++/CLI".
Wie oft noch? Managed C++ ist toter als tot.
C++/CLI ist eine Obermenge von C++, ebenso wie C++/CX (die Windows
Runtime-Variante). Letzteres erzeugt zudem direkt nativen Code, kein CIL
und keine GC.
Eddy C. schrieb:> Was an .NET-Geraffel soll denn bitte Geraffel sein?>> Die fehlende Portierbarkeit?
Das hat sich auch fast erledigt. U.a. ist .NET-Core Open Source und
Xamarin mittlerweile ebenso.
https://blog.xamarin.com/net-standard-library-support-for-xamarin/http://open.xamarin.com/>> Ich halte .NET für kein Geraffel. Viel schneller kann man in> Windowsprogrammierung auch gar nicht einsteigen, wie mit .NET und sagen> wir mal C#.
Eddy C. schrieb:> Was an .NET-Geraffel soll denn bitte Geraffel sein?>> Die fehlende Portierbarkeit? Dass es von MS stammt?>> Ich halte .NET für kein Geraffel. Viel schneller kann man in> Windowsprogrammierung auch gar nicht einsteigen, wie mit .NET und sagen> wir mal C#.
Es ist Geraffel.
Ich muß mit .net und C# arbeiten weil mein Arbeitgeber es so will und
weil der Co-Entwickler der jetzt mit machen soll zu faul ist was anderes
zu lernen. Ich hatte das Programm seinerzeit mit Delphi 4 gemacht. Ich
hatte damals 10 Wochen Zeit eine Grundversion auf die Beine zu stellen.
Der Co schraubt mittlerweile 2 Jahre dran rum, hat jetzt ne Version die
halbwegs stabil läuft, aber die kann nur ca. 1/4 der Funktionalität
meiner Basisversion. Soviel zum Thema es geht schneller mit .net + c#.
Weiterer Nachteil von C# der gewaltige Overhead. Selbst für das
simpelste Konsolenprogramm brauch ich das komplette Framework -
mittlerweile einige 100MB. Und auch das Programm selbst mit seinen
tausenden DLL's und sonstigen Assemblies ist riesengroß - beim obigen
Beispiel ca. Faktor 5 bei 1/4 Funktionalität.
Die Ausführungsgeschwindikeit, insbesondere beim Programmstart ist
Grotte, was ja auch logisch ist das Ganze wird ja erst zur Laufzeit
compiliert.
Portabilität ist immer eine schwierige Sache aber mit .net/c# kann man
es komplett vergessen, da es eine probitäre auf MS zugeschittene Lösung
ist.
Und viel lernen über die Funktion einer GUI tut man mit .net/c# auch
nicht, da alles in fertigen Klassen gekapselt ist.
Nein wenn man was übers GUI lernen möchte dann ist die klassische
steinige Variante schon der beste Weg auch wenn, wie schon meine
Vorredner aufskizzierten, ihn niemand mehr geht. Man ist mit einer
modernen IDE und vorkonfigurierten GUI-KOmponenten einfach schneller.
Für Delphi/Lazerus gab es mal Komponenten - nannten sich glaube ich Cool
Komponenten - die so ein Mittelding zwischen vordefinierten Komponenten
und der klassischen Art waren. Auch etwas steinig aber man wir am Ende
mit einem kompakten und performanten Programm belohnt.
Zeno
Zeno schrieb:> Weiterer Nachteil von C# der gewaltige Overhead. Selbst für das> simpelste Konsolenprogramm brauch ich das komplette Framework -
Meine letzte Android App auf C# Basis war ca. 3MB groß. Und davon waren
ein Großteil Resourcen...
Außerdem ist .NET sowiso auf 99% aller PCs schon drauf. Und auf
OSX/Linux ist so ein Mono auch in Null Komma Nix installiert.
GUI ohne Framework geht nun mal nicht.
Zeno schrieb:> Die Ausführungsgeschwindikeit, insbesondere beim Programmstart ist> Grotte, was ja auch logisch ist das Ganze wird ja erst zur Laufzeit> compiliert.
Du kannst den Code genauso auch vorab kompilieren.
Zur Laufzeit gibt es keine nennenswerten Unterschiede zu anderen
Sprachen (wie z.B. C++).
Zeno schrieb:> Portabilität ist immer eine schwierige Sache aber mit .net/c# kann man> es komplett vergessen, da es eine probitäre auf MS zugeschittene Lösung> ist.
Aua.
Ich entwickle schon seit etlichen Jahren in C#/.NET, und die Programme
laufen, ohne sie neu kompilieren zu müssen auf Windows, OSX und Linux
(Raspberry Pi). Sogar für meine iOS und Android Projekte kann ich den
Code 1 zu 1 verwenden.
Mehr Portabilität geht nicht.
Zeno schrieb:> Soviel zum Thema es geht schneller mit .net + c#.
Wenn man nicht weiß was man tut, dauert es immer länger. Egal mit
welcher Sprache/Framework...
Klaus schrieb:> Also damit hast du dich schon selbst disqualifiziert.
In welcher Hinsicht?
Weil ich über den Tellerrand hinausschaue, und neben Java auch mal zu
C++ + NDK, zu C# und Mono oder zu Webtechnologien wie HTML5 + JS greife?
Ich würde eher sagen es qualifiziert sich derjenige, der sich nicht mit
allen zur Verfügung stehenden Technologien vertraut macht. Denn nur so
kann man für jedes Projekt das auswählen, was am besten passt.
Zeno schrieb:> Ich muß mit .net und C# arbeiten weil mein Arbeitgeber es so will und> weil der Co-Entwickler der jetzt mit machen soll zu faul ist was anderes> zu lernen. Ich hatte das Programm seinerzeit mit Delphi 4 gemacht. Ich> hatte damals 10 Wochen Zeit eine Grundversion auf die Beine zu stellen.> Der Co schraubt mittlerweile 2 Jahre dran rum, hat jetzt ne Version die> halbwegs stabil läuft, aber die kann nur ca. 1/4 der Funktionalität> meiner Basisversion. Soviel zum Thema es geht schneller mit .net + c#.
dann stimmt etwas nicht. Es gibt keinen sinnvollen Grund warum man bei
C# länger also bei Delphi braucht, wenn man beide Sprachen beherrscht.
Wenn du einen Profi vergleichst der 10Jahre lang Delphi gemacht hat, und
jemand der einen 3 Wochen Kurs C# gemacht hat, dann kommen solche
unterschiede raus.
> Und auch das Programm selbst mit seinen> tausenden DLL's und sonstigen Assemblies ist riesengroß - beim obigen> Beispiel ca. Faktor 5 bei 1/4 Funktionalität.
wer zwingt euch so viele DLLs einzusetzen? Man kann auch alles eine ein
exe packen. Meine Erfahrung nach sind .net Programm kleiner als ein
vergleichbares C++ Programm. weil das Framework schon ein Großteil der
Funktionen abbildet.
> Die Ausführungsgeschwindikeit, insbesondere beim Programmstart ist> Grotte, was ja auch logisch ist das Ganze wird ja erst zur Laufzeit> compiliert.
Dafür braucht man keine 2 Programme für 32 oder 64bit (oder arm)
auszuliefern.
Wer es nicht will, kann es auch gleich für native kompilieren.
Du klingst mir nach jemand, der nicht von seinem alten Wege abweichen
will, auf keine Fall etwas neues lernen und dann eventuell noch
zuzugeben das es eventuell sogar besser ist.
Peter II schrieb:> Du klingst mir nach jemand, der nicht von seinem alten Wege abweichen> will, auf keine Fall etwas neues lernen und dann eventuell noch> zuzugeben das es eventuell sogar besser ist.
Naja irgendwie muss man sich ja sein hoffnungslos veraltetes Wissen
schönreden und seine überbezahlten Pfründe gegen alles und jeden
verteidigen bevor man endgültig dadurch entsorgt wird indem die
Abteilung wegen Innovationslosigkeit geschlossen wird ;) duck und weg
(Wenn es dann soweit ist, kommt man hier ins Forum und jammert, dass man
keinen Job mehr findet) scnr
Matthias S. schrieb:> Warum nicht die kostenlosen Express Versionen von M$ für C, C# und C++?
Nee, die nun grade nicht. Wenn schon dann die Community Variante.
Die beschnittenen Express Versionen braucht man höchstens unter
bestimmten Bedingungen im kommerziellen Umfeld.
