mikrocontroller.net

Forum: PC-Programmierung Windows Programmierung


Autor: Dennis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Hans (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Heinz B. (Firma: Privat) (hbrill)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: c-hater (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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...

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Eddy C. (chrisi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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#.

Autor: Timmo H. (masterfx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Horst (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Eddy C. (chrisi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arc N. (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-supp...
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
Autor: Zeno (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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

Autor: Borislav B. (boris_b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Klaus (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Boris P. schrieb:
> Meine letzte Android App auf C# Basis

Also damit hast du dich schon selbst disqualifiziert.

Autor: Eddy C. (chrisi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Borislav B. (boris_b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Hansschmanz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zeno: Meinst du die KOL-Komponenten? http://wiki.freepascal.org/KOL

Autor: Peter II (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: D. I. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: lalala (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dennis schrieb:
> daran mir den Petzold zu beschaffen

Mal blöd gefragt: welchen Titel?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.