Hallo allerseits!
Mich beschäftigt gerade die Frage, wie Ihr Anwendungen mit C++ und der
Win32 API schreibt. Klar, man kann einfach tausende globale
Handles,structs etc nutzen, alle Funktionen global machen und im WndProc
alle Ereignisse verarbeiten.
Das Problem ist nur, dass ab einer bestimmten Programmgröße die
Übersichtlichkeit verloren geht (von den anderen OO-Prinzipien mal ganz
zu schweigen).
Wie macht ihr das? Versucht ihr einen OO-Entwurf für euer Projekt zu
erstellen, was sich mit C++ anbietet, oder programmiert ihr einfach
C-like?
Und wenn ihr oo-programmiert, wie weit geht ihr da? Also für jeden
Button, jede Bitmap etc. eine eigene Klasse oder ist das zuviel
Aufwand/Overhead? Man will (kann) ja nicht gleich ein eigenes Framework
schreiben, aber einfach alles als globale Variablen o.ä zu deklarieren
kanns ja auch nicht sein.
Gruß
Gast0815
Ich kenns nur von Linux, da wird es sicherlich ähnlich verlaufen:
Die allermeisten Programmierer werden sich fertiger Bibliotheken
bedienen...
Bei deinem Beispiel: Was ist denn ein 'Bitmap'? Nur ein Vektor mit
Rohdaten? Oder willst du dann (mal wieder...) das Rad und eine
Bildbearbeitungsbibliothek neu erfinden?
wenn ich mich recht erinnere ksnnst du beim öffnen eines fenters
extrabytes anfordern, die du dann mmit applikationsdaten - etwa zeiger
auf objekt o.ä. - füllen kannst. aber die windows api arbeitet
c-konform. deshalb gabs dann mal mfc und ähnliche wraper, die das ganze
mehr oder weniger objektorientiert aubereitet haben.
Nein, ich will bestimmt keine Bildbearbeitungsbibliothek erstellen. Um
bei dem Beispiel Bitmap zu bleiben: Es geht eher darum, dass wenn ich
einfach nur eine Grafik darstellen will, ich ein Handle für die Bitmap
und eine BITMAP-struct brauche. Um sie zu zeichnen, muss dann einmal ein
LoadBitmap-Aufruf erfolgen, um sie mit Daten zu füllen und dann bei der
Paint-Message ein BitBlt Aufruf.
Das sieht für mich so aus, als würde sich das Erstellen einer Klasse
lohnen, in deren Konstruktur dann automatisch eine entsprechende
Resource/Datei geladen wird. Die Daten könnten als private-Member
gespeichert sein und die Aufrufe in Methoden gepackt, so dass man sich
eine Menge Tipp-Arbeit sparen könnte. Es gibt da bestimmt noch ein paar
windows-spezifische Dinge zu beachten.
Analog dann das Verfahren für Dialoge. Anstatt für jedes GUI-Element ein
globales Handle, das Ganze in einer Klasse kapseln und die notwendigen
Funktionen zur Verfügung stellen.
OK. Wenn du MFC nicht magst, ist das ein Argument. Obwohl die MFC, wenn
auch nicht toll, immer noch um Längen besser ist als direkt an die C-API
zu gehen.
Aber es gibt ja auch noch andere Klassenbibliotheken.
Solche Bibliotheken schreibt man nicht selbst sondern benutzt eine
Fertige. Das hat dann auch den Vorteil, dass man das Rad nicht neu
erfinden muss, dass die einzelnen Klassen der Bibliothek auch
miteinander können, dass man von vorneherein schon mit einer
(einigermassen) fehlerfreien Bibliothek arbeiten kann und sich auf seine
Anwendung und nciht auf das Erstellen einer Bibliothek konzentrieren
kann und zu guter letzt: es gibt Tutorien dafür wie man so eine
Bibliothek einsetzen kann.
Google mit "Windows GUI Library" sollte mit einigen brauchbaren
Bibliotheken hochkommen. Hast du Qt schon ausprobiert?
> Mich beschäftigt gerade die Frage, wie Ihr Anwendungen mit C++ und> der Win32 API schreibt. Klar, man kann einfach tausende globale> Handles,structs etc nutzen, alle Funktionen global machen und im> WndProc alle Ereignisse verarbeiten.
Das macht heute kein Mensch mehr. Viel zu langsam in der Entwicklung,
viel zu fehleranfällig. Been there, done that; Microsoft gepriesen als
die MFC herauskam.
Karl heinz Buchegger (kbuchegg) (Moderator) wrote:
>> Mich beschäftigt gerade die Frage, wie Ihr Anwendungen mit C++ und>> der Win32 API schreibt.> Das macht heute kein Mensch mehr. Viel zu langsam in der Entwicklung,> viel zu fehleranfällig. Been there, done that; Microsoft gepriesen als> die MFC herauskam.
Die nativen Win32 Programme waren aber noch schön schlank, schnell in
ihrer Ausführung und laufen auch heute noch unter einem alten Win9x.
Während ein mit dot net kompiliertes "Zwischencode Programm" gar nicht
mehr zur Ausführung kommt, weil sich die Laufzeitumgebung erst gar nicht
mehr installieren lässt.
> Die nativen Win32 Programme waren aber noch schön schlank, schnell in> ihrer Ausführung und laufen auch heute noch unter einem alten Win9x.
Und sind grauenhaft zu warten. Wie Karl Heinz schon sehr treffend sagte,
been there, done that. Never again.
Und die Kompatibilität zu einem lausigen instabilen
16/32-Bit-Frickelsystem hat mich noch nie interessiert.
Das .net-Geraffel mag ich allerdings auch nicht.
> Und sind grauenhaft zu warten. Wie Karl Heinz schon sehr treffend sagte,> been there, done that. Never again.
War dem Erfolg von Windows abträglich? Mitnichten!
> Und die Kompatibilität zu einem lausigen instabilen> 16/32-Bit-Frickelsystem hat mich noch nie interessiert.
na kommm, die Vokabel "Frickelsystem" ist doch bereits vergeben :)
> Das .net-Geraffel mag ich allerdings auch nicht.
jaja, ich weiß :)
@Gast0815: das nutzt nix. die win32api ist C und nicht C++. wennst da
C++ drüberstülpen willst, viel spaß, aber der aufwand lohnt nicht.nimm
dir lieber wx oder fltk.
Gast schrieb:
>> Und sind grauenhaft zu warten. Wie Karl Heinz schon sehr treffend sagte,>> been there, done that. Never again.>> War dem Erfolg von Windows abträglich? Mitnichten!
O doch. Erst mit der Einführung von C++-Compilern und mehr oder weniger
brauchbaren Klassenbibliotheken bzw. von Alternativprodukten (Visual
Basic, Delphi) wurde der Markt für Windows-Anwendungen wirklich
attraktiv.
Ich habe ausreichend viel Zeit mit dem Windows-SDK verbracht, auch schon
zu Windows 3.0-Zeiten, und etwas später mit dem Umstieg auf 32-Bit mit
NT 3.1 ... und ich habe mich mit diesem unübersichtlichen Gekröse nie
anfreunden können.
Reinen SDK-Anwendungen sieht man deren Herkunft auch oft deutlich an: An
den GUI-Richtlinien vorbeiprogrammiert, hässliche Dialoge, merkwürdige
Toolbars veraltete Standarddialoge etc. (Beispiele: TeraTerm oder GsView
oder viel aus dem Unix/Linux-Lager her stammendes).
> na kommm, die Vokabel "Frickelsystem" ist doch bereits vergeben :)
Und passt hier auch wie der Arsch auf den Eimer.
Windows 95 und der nachfolgende Rotz hätte nie sein müssen.
Ok, danke für die Beiträge.
Ich hab gerade entdeckt, dass es Qt auch für Windows Mobile gibt. Von
daher ist für mich klar, dass ich in die Richtung gehen werde. Mit Qt
hab ich gute Erfahrungen gemacht, war aber bis eben der Meinung, dass Qt
Mobility bis jetzt nur für Nokia-Systeme erhältlich ist.
Wie gesagt, der Grund überhaupt nochmal die win32-api anzupacken war,
dass ich momentan für windows mobile entwickle. Ich kann Rufus nur
zustimmen, die Entwicklung mit dieser api ist sehr zeitintensiv und die
Ergebnisse sind optisch nicht unbedingt ansprechend. Allerdings hat sie
auch einen gewissen "Charme".
>> War dem Erfolg von Windows abträglich? Mitnichten!> O doch. Erst mit der Einführung von C++-Compilern und mehr oder weniger> brauchbaren Klassenbibliotheken bzw. von Alternativprodukten (Visual> Basic, Delphi) wurde der Markt für Windows-Anwendungen wirklich> attraktiv.
Und deswegen existiert die Win32 API trotzdem (weiter). Tatsache ist, MS
hat mit der Win32 API keine Bauchlandung gemacht, sonst gäbe es sie
schon lange nicht mehr. Aber wie sieht das denn mit dem damals auch so
gepriesenen (angeblich viel besseren) OS/2 aus? Wie erfolgreich waren
die denn? Warum soll(te) es auch nicht ein Visual BASIC geben? Es
bestand immer schon ein Bedarf nach einem leichten Einstieg in die
Windows Programmierung, ohne sich mit der Kompliziertheit der
Fenster-Erstellung mittels der API zu befassen. Und was Delphi betrifft,
das war die logische Weiterentwicklung von Turbo Pascal für Windows. Das
mag den Windows Markt beschleunigt haben (da dürfen wir aber auch die
MFC nicht unerwähnt lassen), aber welchen Stellenwert das jeweils hat
oder hatte, das müsste man erst mal genauer in Erfahrung bringen.
> Ich habe ausreichend viel Zeit mit dem Windows-SDK verbracht, auch schon> zu Windows 3.0-Zeiten, und etwas später mit dem Umstieg auf 32-Bit mit> NT 3.1 ... und ich habe mich mit diesem unübersichtlichen Gekröse nie> anfreunden können.
Mir war das was Petzold in seinem Standard Werk veröffentlicht hat viel
eher eingängig als die ganze Kapselung durch die MFC.
> Reinen SDK-Anwendungen sieht man deren Herkunft auch oft deutlich an: An> den GUI-Richtlinien vorbeiprogrammiert, hässliche Dialoge, merkwürdige> Toolbars veraltete Standarddialoge etc. (Beispiele: TeraTerm oder GsView> oder viel aus dem Unix/Linux-Lager her stammendes).
Naja, schau dir mal die alten Dialoge an die von Turbo Pascal bzw.
Delphi herrühren, da erkennst du auch immer schön Borland heraus. ;)
(ein grünes Häkchen im OK und ein rotes Kreuzchen im Cancel oder so
ähnlich)
Ich hab übrigens gerade die original Borland Handbücher von TP für
Windows vor mir liegen. Wollte sie schon wegschmeißen, bringe es aber
nicht übers Herz. ;)
>> na kommm, die Vokabel "Frickelsystem" ist doch bereits vergeben :)> Und passt hier auch wie der Arsch auf den Eimer.
na wenn du halt diesen Begriff hier ins Spiel bringst :)
> Windows 95 und der nachfolgende Rotz hätte nie sein müssen.
Damit willst du doch hoffentlich nicht sagen, Windows 3.x war das beste
Windows (das du kennst)?
Qt wäre vielleicht noch eine Alternative für den Fragesteller.
Gast schrieb:
> Die nativen Win32 Programme waren aber noch schön schlank, schnell in> ihrer Ausführung und laufen auch heute noch unter einem alten Win9x.
MFC Programme sind auch nicht soooo wahnsinng groß und laufen auch auf
Win9x immer noch sehr gut.
> Während ein mit dot net kompiliertes "Zwischencode Programm" gar nicht> mehr zur Ausführung kommt, weil sich die Laufzeitumgebung erst gar nicht> mehr installieren lässt.
Igiit. Sowas greif ich erst gar nicht an.
Gast0815 schrieb:
> Wie gesagt, der Grund überhaupt nochmal die win32-api anzupacken war,> dass ich momentan für windows mobile entwickle.
Ich hasse es das zu sagen.
Aber für Windows Mobile würde ich dir tatsächlich C# mit .Net empfehlen.
Hab das mal probiert. Das ging tatsächlich ziemlich problemlos. Ein paar
Abstriche muss man im .Net machen, aber sonst ganz brauchbar.
Gast schrieb:
> Und deswegen existiert die Win32 API trotzdem (weiter).
Logo. MS kann die nicht einfach über Bord schmeissen. Da steht schon
alleine das Kompatibilitätsargument dagegen. MS würde sich ins eigene
Fleisch schneiden, wenn sie das Grundprinzip ändern würden.
> Aber wie sieht das denn mit dem damals auch so> gepriesenen (angeblich viel besseren) OS/2 aus? Wie erfolgreich waren> die denn?
Das hat keine technischen Gründe. Marketing rules. Die meisten
Entwickler die ich kenne hätten viel lieber OS/2 gehabt. Aber was solls,
keine Firma entwickelt OS/2 Programme für die sie langwierig Kunden
suchen müssen, wenn ihnen die Leute die Telefone mit der Frage nach
Windows Programmen heiß laufen lassen. Linux hat(te) dasselbe Problem.
Wer entwickelt schon kommerziell Programme, wenn es keinen Kundenstock
dafür gibt.
> Warum soll(te) es auch nicht ein Visual BASIC geben?
Ich behaupte, VB war ein extrem wichtiges Standbein um den Markt mit
Windows Programmen regelrecht zu fluten.
> Es> bestand immer schon ein Bedarf nach einem leichten Einstieg in die> Windows Programmierung, ohne sich mit der Kompliziertheit der> Fenster-Erstellung mittels der API zu befassen.
Das ist auch mit einer Klassenbibliothek nicht allzu kompliziert. So
schnell wie man mit MFC einen Dialog hoch hat ... kein Vergleich zur SDK
Methode. Und in VB geht alles noch einen Tisck schneller.
> Mir war das was Petzold in seinem Standard Werk veröffentlicht hat viel> eher eingängig als die ganze Kapselung durch die MFC.
Ist Gewohnheitssache. Mann muss das ganze Konzept der Windows Procedure
über Bord werfen und dem Wizard vertrauen, dass er den entsprechenden
Handler schon richtig einbauen wird (zumindest am Anfang). Dann wird
auch die MFC relativ komfortabel und das Event-Konzept greift ganz gut.
(Der neue Class Wizard im VS ist für MFC Programmierer meiner Meinung
nach eine Zumutung. Das war in VC++ 6.0 noch um 3 Klassen besser)
> Naja, schau dir mal die alten Dialoge an die von Turbo Pascal bzw.> Delphi herrühren, da erkennst du auch immer schön Borland heraus. ;)>> (ein grünes Häkchen im OK und ein rotes Kreuzchen im Cancel oder so> ähnlich)
Die konnte ich nie leiden. War mit ein Grund warum ich das nie benutzt
habe.
> An den GUI-Richtlinien vorbeiprogrammiert
Und interessanterweise war Microsoft mit unter den ersten, die ihre
eigenen Designrichtlinien aber sowas von ignoriert haben :-)
Karl heinz Buchegger (kbuchegg) (Moderator) wrote:
> MFC Programme sind auch nicht soooo wahnsinng groß und laufen auch auf> Win9x immer noch sehr gut.
Stimme ich zu.
> Igiit. Sowas greif ich erst gar nicht an.
:)) na so schlecht kanns doch auch wieder nicht sein
> Aber für Windows Mobile würde ich dir tatsächlich C# mit .Net empfehlen.> Hab das mal probiert. Das ging tatsächlich ziemlich problemlos. Ein paar> Abstriche muss man im .Net machen, aber sonst ganz brauchbar.
na siehste, Karl-Heinz, geht doch (hehe)
Gast0815 schrieb:
> Die Frage ist, wieviel Aufwand ist es, sich in C# einzuarbeiten. Es geht> hier um ein einzelnes Projekt, und ich kenne C++ und Qt bereits.
Auch das hasse ich zuzugeben:
Hab mir in der Buchhandlung ein Werk zu C# geholt.
Nach einem Nachmittag hatte ich das erste Programm lauffähig. OK, das
war noch sehr primitiv, aber immerhin. Die Portierung auf die
Mobile-version war (fast) ein Kinderspiel.
Denn eines muss man zugeben: das .Net Framework ist schon sehr gut
aufgebaut. Logisch durchdacht und alles passt zusammen (wenn man erst
einmal ein paar Prinzipien kapiert hat). Dagegen ist MFc wirklich Kraut
und Rüben.
Karl heinz Buchegger (kbuchegg) (Moderator) wrote:
> Gast schrieb:>> Und deswegen existiert die Win32 API trotzdem (weiter).> Logo. MS kann die nicht einfach über Bord schmeissen. Da steht schon> alleine das Kompatibilitätsargument dagegen. MS würde sich ins eigene> Fleisch schneiden, wenn sie das Grundprinzip ändern würden.
Und eben gerade die Kompatibilität wurde MS auch immer wieder indirekt
vorgeworfen (Stichwort: alten 16-bit Code weiterhin unterstützen; die
API hatte dann zwei Versionen bei ihren Funktionsaufrufen, sieht man
schön im alten Win32api Help File).
>> Aber wie sieht das denn mit dem damals auch so>> gepriesenen (angeblich viel besseren) OS/2 aus? Wie erfolgreich waren>> die denn?> Das hat keine technischen Gründe. Marketing rules. Die meisten> Entwickler die ich kenne hätten viel lieber OS/2 gehabt.
Ja wie so oft. Das vermeintlich (oder wegen mir auch wirklich) bessere
muss noch lange nicht als "Sieger" hervorgehen.
> Aber was solls,> keine Firma entwickelt OS/2 Programme für die sie langwierig Kunden> suchen müssen, wenn ihnen die Leute die Telefone mit der Frage nach> Windows Programmen heiß laufen lassen. Linus hat(te) dasselbe Problem.> Wer entwickelt schon kommerziell Programme, wenn es keinen Kundenstock> dafür gibt.
Also bei Linux frage ich mich in der Tat wie sich manche da über
überhaupt Wasser halten können. Aber ich frage mich ehrlich gesagt auch
schon lange, wer überhaupt die vielen Linux-Zeitschriften noch kauft,
angesichts der vielen freien Informationen im Netz. Früher als man noch
auf Heftbeilagen der Distris angewiesen war hab ich mir die auch immer
gerne gekauft. Seit DSL ist's obsolet.
>> Warum soll(te) es auch nicht ein Visual BASIC geben?> Ich behaupte, VB war ein extrem wichtiges Standbein um den Markt mit> Windows Programmen regelrecht zu fluten.
Ja um VB gab es einen richtigen Hype. Mir war da mein altes Turbo Pascal
eingängiger (allerdings noch DOS). Habe dann die geschwätzige Sprache
Pascal zu gunsten TC 3.x (auch noch DOS) links liegen gelassen. :) (dann
MS Produkte ..).
>> Es>> bestand immer schon ein Bedarf nach einem leichten Einstieg in die>> Windows Programmierung, ohne sich mit der Kompliziertheit der>> Fenster-Erstellung mittels der API zu befassen.> Das ist auch mit einer Klassenbibliothek nicht allzu kompliziert. So> schnell wie man mit MFC einen Dialog hoch hat ... kein Vergleich zur SDK> Methode.
Das war ja immer der Punkt. Natürlich geht das alles schnell, besonders
mit Klick auf den Assistenten. Dann fing das aber an kompliziert zu
werden. Die Nachrichtenschleife war zerhackt und es hagelte lauter "
TODO: Add your command handler code hear" Fragmente. Das war im Petzold
alles übersichtlicher (wie ich finde). Die MFC macht sich erst "bezahlt"
wenn die Programme länger werden. Zum kennen lernen und
Programmiereinstieg fand ich das Klassenkonzept eher verwirrend (aus der
Sicht des Programmier-Einsteigers in Windows Applikationen; später sieht
man das anders).
> Und in VB geht alles noch einen Tisck schneller.
ei jo
>> Mir war das was Petzold in seinem Standard Werk veröffentlicht hat viel>> eher eingängig als die ganze Kapselung durch die MFC.> Ist Gewohnheitssache. Mann muss das ganze Konzept der Windows Procedure> über Bord werfen und dem Wizard vertrauen, dass er den entsprechenden> Handler schon richtig einbauen wird (zumindest am Anfang). Dann wird> relativ komfortabel und das Event-Konzept greift ganz gut.
Der Punkt war, man musste gleichzeitig OOP-Code (Klassen-Konzept) UND
Win32-API Funktionen lernen. C konnte man bereits, da war der Petzold
einem halt näher.
>> Naja, schau dir mal die alten Dialoge an die von Turbo Pascal bzw.>> Delphi herrühren, da erkennst du auch immer schön Borland heraus. ;)>>>> (ein grünes Häkchen im OK und ein rotes Kreuzchen im Cancel oder so>> ähnlich)> Die konnte ich nie leiden. War mit ein Grund warum ich das nie benutzt> habe.
Da gab es ein schönes Layout Programm namens Protelm dem man seine
Herkunft ansah. Das hat eigentlich schön funktioniert. ;)
>> An den GUI-Richtlinien vorbeiprogrammiert> Und interessanterweise war Microsoft mit unter den ersten, die ihre> eigenen Designrichtlinien aber sowas von ignoriert haben :-)
ei jo
Karl heinz Buchegger (kbuchegg) (Moderator) wrote:
> Denn eines muss man zugeben: das .Net Framework ist schon sehr gut> aufgebaut. Logisch durchdacht und alles passt zusammen (wenn man erst> einmal ein paar Prinzipien kapiert hat). Dagegen ist MFc wirklich Kraut> und Rüben.
bring das mal deinem Mod Kollegen Rufus' bei :-)
Also das Win32 API ist für C.
Für C++ hat Microsoft den MFC Wrapper geschrieben, der genau das tut,
was du sagst: Er baut "für jeden Button, jede Bitmap etc. eine eigene
Klasse".
Damit kannst du dein Programm schon mal vergessen, nur Idioten
programmieren so. Wer vernünftig programmiert, macht es generisch, d.h.
es ist egal wie viele Elemente im Dialog sind, die Dialogfunktion bleibt
möglichst gleich.
Es spricht alles dafür, MFC nicht zu verwenden, denn Win32 Funktionen
kann man auch direkt von C++ aufrufen.
Einzige Ausnahme: Wenn man OLE realisieren muß. Da helfen die
MFC-Klassen.
Rufus schreibt: "Reinen SDK-Anwendungen sieht man deren Herkunft auch
oft deutlich an: An den GUI-Richtlinien vorbeiprogrammiert, hässliche
Dialoge, merkwürdige Toolbars veraltete Standarddialoge etc. (Beispiele:
TeraTerm oder GsView oder viel aus dem Unix/Linux-Lager her
stammendes)." und merkt gar nicht, wie falsch er hier liegt.
Gerade SDK Anwendungen sehen nicht aus wie irgendwoher, und gerade SDK
Anwendungen sind sehr GUI konform. Rufus schreibt auch sonst viel
Unsinn, Karl heinz weist schon auf seine Unkenntnis von DotNET hin,
welches wirklich sehr geradlinig und gut designt ist, leider politisch
als "Microsoft's Antwort auf Java" verschissen und hat das
gleiche-DDLs-in-verschiedenen-Versionen echt krank gelöst.
Wenn du unter Mobile entwickeln sollst, achte darauf, daß das Win32 API
dort anders ist als unter Win32 :-( man kann Programme nicht einfach von
XP nach Mobile nehmen und gleichen Code verwenden. Da man aber Programme
sowieso in einen Teil der die Oberfläche definiert und einen Teil der
die Daten verarbeitet (und auch ohne Oberfläche z.B. fernsteuerbar ist)
aufteilt, ist es nicht so schwer, die Unterschiede in der GUI-Schicht so
zu programmieren, daß es unter beiden läuft.
Ob ich zu Qt für Mobile raten würde? Ein klares nein. Die Anwendung
sieht scheisse aus, schleppt Zeugs mit sich rum welches der Anwender
nicht haben will, und ist inkompatibel. Zudem musst du Qt für Nokia
debuggen.
Karl heinz Buchegger schrieb:
> Denn eines muss man zugeben: das .Net Framework ist schon sehr gut> aufgebaut. Logisch durchdacht und alles passt zusammen (wenn man erst> einmal ein paar Prinzipien kapiert hat). Dagegen ist MFc wirklich Kraut> und Rüben.
Klar, MS hat ja auch den besten und fähigsten Software-Architekten
Borlands für teuer Geld abgeworben. Schon traurig, wenn man anscheinend
im eigenen Haus niemanden hat, der sowas kann - aber die mussten
wahrscheinlich jahrelang mit der Win32 API und MFC arbeiten und waren
dementsprechend verdorben. ;-)
Mark Brandis schrieb:
> Klar, MS hat ja auch den besten und fähigsten Software-Architekten> Borlands für teuer Geld abgeworben.
Wenns nur der wäre :-)
MS hat sich auf vielen Gebieten vor einigen Jahren die besten Köpfe
eingekauft.
Computer Graphik: Jim Blinn, Jim Kajia
C++: Herb Suttner
(vor Jahren) BS: Dave Cutler und seine Mannschaft
... und noch viele mehr
> wahrscheinlich jahrelang mit der Win32 API und MFC arbeiten und waren> dementsprechend verdorben. ;-)
LOL
> > Windows 95 und der nachfolgende Rotz hätte nie sein müssen.>> Damit willst du doch hoffentlich nicht sagen, Windows 3.x war das beste> Windows (das du kennst)?
Um Gottes Willen, nein. Windows 95 hatte nur zwei(einhalb) Nachfolger,
98 (98SE) und Me.
Windows NT gibt es schon bedeutend länger, nur wird es von den
Marketingdrohnen von Microsoft alle paar Jahre mal wieder anders
genannt. Windows 7 ist Windows NT 7.0.
> Dagegen ist MFc wirklich Kraut und Rüben.
Das bestreite ich erst recht nicht. MFC ist furchtbar. Ich kenne sie,
ich lebe damit. Und ich würde ums Verrecken niemandem dazu raten, sich
das anzutun. Da gibt es wirklich bessere Alternativen, gerade auch in
Hinblick Plattformunabhängigkeit. Die halte ich für wichtig.
> Rufus schreibt: "Reinen SDK-Anwendungen sieht man deren Herkunft> auch oft deutlich an: An den GUI-Richtlinien vorbeiprogrammiert,> hässliche Dialoge, merkwürdige Toolbars veraltete Standarddialoge> etc. (Beispiele: TeraTerm oder GsView oder viel aus dem Unix/Linux-> Lager her stammendes)."> und merkt gar nicht, wie falsch er hier liegt.>> Gerade SDK Anwendungen sehen nicht aus wie irgendwoher, und> gerade SDK Anwendungen sind sehr GUI konform.
Die von mir genannten Anwendungen kennst Du?
Sicher, Anwendungen, die sich überhaupt nicht um GUI-Richtlinien
kümmern, lassen sich auch ganz wunderbar mit VB oder Delphi oder
irgendeinem C++-Compiler und dessen Klassenbibliothek zusammenklicken,
aber das hat andere Gründe.
Sieh Dir genau die beiden von mir erwähnten Anwendungen (TeraTerm und
GsView) mal an, und überlege dann, inwiefern die den GUI-Richtlinien
entsprechen.
> Rufus schreibt auch sonst viel Unsinn,
Das kannst Du gerne so sehen, bitte. Ich möchte nur darauf hinweisen,
daß ich seit ziemlich langer Zeit mein Geld damit verdiene, Software für
Windows zu entwickeln. Und das auch schon zu Zeiten von Windows 3.0
getan habe.
> Karl heinz weist schon auf seine Unkenntnis von DotNET hin,> welches wirklich sehr geradlinig und gut designt ist,
Daß das Zeug sauber designt sein mag, bestreite ich nicht. Ich mag es
einfach nicht. Ich mag keine "garbage collection", ich mag nicht die
C++-Sprachvergewaltigung namens "Managed C++" - ja, ich bin halt
konservativ.
Rufus t. Firefly schrieb:
>> etc. (Beispiele: TeraTerm oder GsView oder viel aus dem Unix/Linux->> Lager her stammendes).">> und merkt gar nicht, wie falsch er hier liegt.>>>> Gerade SDK Anwendungen sehen nicht aus wie irgendwoher, und>> gerade SDK Anwendungen sind sehr GUI konform.>> Die von mir genannten Anwendungen kennst Du?
Ich hab eigentlich auch diese Erfahrung gemacht. Die schlimmsten
Programme waren fast ausschliesslich über die Win32 API geschrieben. Und
da nehme ich mich sicherlich nicht aus. Verwundert auch nicht weiter,
wenn man weiß, welchen Aufwand man da treiben muss für Dinge, die ein
Framework einfach so mitbringt.
Allerdings wirst du mir sicherlich zustimmen: Es hilft auch in der MFC
Programmierung ungemein, wenn man die zugrundeliegende native API kennt.
Soviel zum Thema: Ein Framework abstrahiert die Details weg :-)
>> Karl heinz weist schon auf seine Unkenntnis von DotNET hin,>> welches wirklich sehr geradlinig und gut designt ist,
Wenn er das so gesehen hat, kann ichs nicht ändern. Es war allerdings
keineswegs meine Absicht auf irgendwelche Unkentnis von Seiten Rufus
hinzuweisen. Ich kenne Rufus zu lange und weiß, das er mit MFC arbeitet
(so wie ich auch). Und höchst wahrscheinlich hat er genauso wie ich
auch, in .Net hineingeschnuppert.
> Ich mag es> einfach nicht. Ich mag keine "garbage collection", ich mag nicht die> C++-Sprachvergewaltigung namens "Managed C++" - ja, ich bin halt> konservativ.
Ein Gesinnungsbruder!
Darf ich dich virtuell drücken?
PS:
Ich mag auch den neuen Ribbon-Style nicht.
Das erste was ich bei meinen Vistas mache: GUI zurückschalten auf
Classic Style. Die */%"$% bescheuerte automatische
Menüpunkte-wandern-ständig-hin-und-her-so-sie-überhaupt-sichtbar-sind-Au
tomatik abschalten.
Gleich danach kriegt der Explorer den Auftrag, Dateiendungen anzuzeigen
(da bin ich dann schon knapp am Blutrausch) und dass er sich seinen
linken platzverbrauchenden Teil in die Haare schmieren soll. Wenn er
sich dann noch erdreistet (das war aber glaub ich XP und nicht Vista)
mich bei einem Wechsel ins Program-Verzeichnis darauf aufmerksam zu
machen, dass ich da nicht rein sollte, bin ich soweit, dass ich meinen
Chef um ein Flugticket nach Seattle und etwas Geld für eine Pumpgun
anflehe.
> Allerdings wirst du mir sicherlich zustimmen: Es hilft auch in> der MFC Programmierung ungemein, wenn man die zugrundeliegende> native API kennt.
Das hilft nicht nur, das ist praktisch überlebenswichtig. Ohne die
Win32-API zu kennen, kann man nicht verstehen, wie und warum die MFC
funktioniert. Und viele MFC-"Programmierer" basteln sich dann
entsprechende merkwürdige Programme zusammen.
Wenn denn man meint, MFC nutzen zu müssen, dann aber erst nach
ausreichenden(!) Arbeiten mit der Win32-API. Den Petzoldt sollte man ein
paar Jahre lang als alleinige Lektüre nutzen ...
> Ich mag auch den neuen Ribbon-Style nicht.> Das erste was ich bei meinen Vistas mache: GUI zurückschalten auf> Classic Style.
Gottlob bin ich "auffe arbeit" noch um Vista & Co. umhingekommen, das
aber wird sich in nächster Zeit ändern. "Ribbons" inklusive. Buärks.
Mein privates Antidot war die Anschaffung eines Macs.
Karl heinz Buchegger schrieb:
>> Während ein mit dot net kompiliertes "Zwischencode Programm" gar nicht>> mehr zur Ausführung kommt, weil sich die Laufzeitumgebung erst gar nicht>> mehr installieren lässt.>> Igiit. Sowas greif ich erst gar nicht an.
Eure Konkurrenz schon...
http://through-the-interface.typepad.com/through_the_interface/2009/06/creating-fibonacci-spirals-in-autocad-using-f.html
(hier allerdings in der dafür besser geeigneten Sprache F#)
> Linux hat(te) dasselbe Problem.> Wer entwickelt schon kommerziell Programme, wenn es keinen Kundenstock> dafür gibt.
Mittlerweile gibt's Kunden, die meinen, dass auch die Entwicklungskosten
sinken, wenn sie *nix vorgeben. Frei nach dem Motto: Ist ja alles Open
Source und muss nur noch "zusammengestöpselt" werden...
> Denn eines muss man zugeben: das .Net Framework ist schon sehr gut> aufgebaut. Logisch durchdacht und alles passt zusammen (wenn man erst> einmal ein paar Prinzipien kapiert hat). Dagegen ist MFc wirklich Kraut> und Rüben.
Man sieht dem .NET Framework, zumindest in Teilen und insb. C# an, wer
da für die Architektur verantwortlich war: Anders Hejlsberg (Turbo
Pascal, Delphi, VCL)
Gast schrieb:
> Ja wie so oft. Das vermeintlich (oder wegen mir auch wirklich) bessere> muss noch lange nicht als "Sieger" hervorgehen.
So wie IBM daran gearbeitet hat, dass es ein Markterfolg wird...
> Das war ja immer der Punkt. Natürlich geht das alles schnell, besonders> mit Klick auf den Assistenten. Dann fing das aber an kompliziert zu> werden. Die Nachrichtenschleife war zerhackt und es hagelte lauter "> TODO: Add your command handler code hear" Fragmente. Das war im Petzold> alles übersichtlicher (wie ich finde). Die MFC macht sich erst "bezahlt"> wenn die Programme länger werden.
Sagen wir's mal so: Das letzte Stück Software was hier als reine
Win32-App entwickelt wurde, wurde das letzte mal 1998 gefixt, ab 1997
d.h. mit dem ersten C++Builder, hatte sich das Thema MFC/Win32 erstmal
(zu 99.9%) erledigt. Das fing auch mit einer übersichlichen
Nachrichtenschleife an, nachher konnte man es allerdings nicht mehr so
bezeichnen...
MaWin schrieb:
> und hat das gleiche-DDLs-in-verschiedenen-Versionen echt krank gelöst.
Besser als im .NET-Framework kann man es fast nicht mehr lösen.
Man kann bei jeder DLL/EXE festlegen, welche Versionen es
unterstützt bzw. welche Version genau vorausgesetzt wird (Stichworte:
requiredRuntime, supportedRuntime, app.config)
Karl heinz Buchegger schrieb:
> Wenns nur der wäre :-)> MS hat sich auf vielen Gebieten vor einigen Jahren die besten Köpfe> eingekauft.
Sun hat sich bspw. sehr viel Know-How für Java "besorgt" (Stichwort:
StrongTalk, SavaJe etc.), Apple hat sich so gut wie jedes Know-How
eingekauft (NeXt, Emagic, PASemi, MultiTouch mit/von FingerWorks
gekauft, Cover Flow (Bspw. Navigation durch die Musik beim iPhone)), IBM
hat Lotus, Tivoli, Informix, Rational etc. pp. gekauft.
Die Frage ist aber, warum die Leute zu Microsoft gegangen sind. Weil
Sun/IBM oder wer auch immer (die fähigsten Apple-Leute sind z.Z. bei
Palm inkl Jon Rubinstein) nicht bereit waren genug zu bezahlen, oder
gab's bei Microsoft vllt bessere Arbeitsbedingungen...
http://channel8.msdn.com/Posts/Du-willst-Karriere-bei-Microsoft-machen/
(ab 2:35 und 6:39 bzw. 8:51 bis zum Ende)
> Windows 7 ist Windows NT 7.0.
6.1 :->
Karl heinz Buchegger schrieb:
> Ich mag auch den neuen Ribbon-Style nicht.> Das erste was ich bei meinen Vistas mache: GUI zurückschalten auf> Classic Style. Die */%"$% bescheuerte automatische> Menüpunkte-wandern-ständig-hin-und-her-so-sie-überhaupt-sichtbar-sind-> Automatik abschalten.
Ich weiß schon gar nicht mehr wie das Classic Style Menü aussieht bzw.
wie "Alle Programme" aussieht, Win+"ZIP"+Enter eintippen geht halt
schneller, als im Menü das Programm zu suchen. Gleiches gilt für
richtige Suchen nach Dokumenten und deren Inhalten.
Also, ich hab mir jetzt Qt für Windows Ce installiert und sogar schon
zum Laufen gekriegt. Aber wie implementiere ich mobile-spezifische
Sachen, wie GPS-Anbindung und gprs-Verbindung ins Internet? Hat Qt
spezielle Klassen dafür(konnte ich bis jetzt noch nicht finden) oder
kommt da wieder die Microsoft-API ins Spiel(womit wir ja wieder bei C
und den handles wären)?
Arbeitet Qt überhaupt mit der API zusammen?
Nein, Qt ist mehr als GUI.
Es enthält u.a. Container-Klassen, Algorithmen, Klassen für OpenGl,
Kommunikation(z.B Sockets).
Ich finde, das macht Qt so interessant - man hat alle Hilfsmittel, die
man braucht um Anwendungen entwicklen zu können.
> Ich finde, das macht Qt so interessant - man hat alle Hilfsmittel, die> man braucht um Anwendungen entwicklen zu können.
oder es verhindert das man sauber zwischen GUI und Programm logig
unterscheidet. Sobald jemand von einem Programm nur noch ein
Kommandozeilen programm braucht muss man immer nocht Qt einbinden.
Man kann auch Console-Anwendungen erstellen. Allerdings vermute ich,
dass die dann trotzdem relativ groß sind. Wenn das aber irrelevant ist-
warum nicht?
