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#.
:
Bearbeitet durch User
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...
:
Bearbeitet durch User
Boris P. schrieb: > Meine letzte Android App auf C# Basis Also damit hast du dich schon selbst disqualifiziert.
Klaus schrieb: > Boris P. schrieb: >> Meine letzte Android App auf C# Basis > > Also damit hast du dich schon selbst disqualifiziert. Vielleicht auch nicht: https://msdn.microsoft.com/de-de/library/dn771552.aspx
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.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.