Entwickeln unter Windows - Eine Nervenraubende Sache?
-
Ich sage nur Eclipse mit VM und habe das Beste aus zwei Welten.
-
loks schrieb:
Bei der Einstellung gibt es nur einen guten Rat: Go away. Bleib bei Linux. Du willst nicht Windows lernen, Du willst Linux unter Windows. Und da aus Deiner Sicht Linux die Referenz ist wie man alles richtig macht und Windows Sachen anders macht muß es ja per Definition alles falsch sein.
Tu Dir selbst nen Gefallen...
Und nein, es liegt nicht an Windows, es liegt an Deiner Einstellung das Du mit Windows nicht klarkommst. Stichwort: Self-fulfilling-prophecy.
'nuff said.
-
Frachtkatamaran schrieb:
Unter Linux kann ich mittels pkg-config alle Bibliotheken und Compilerflags einbinden unter Windows scheint es so etwas gar nicht zu geben.
Doch, gibt es: meistens wird für MSVC ein Projekt/Solution mitgeliefert. Notfalls schmeisst man nmake vom MSVC an.
Auch bjam oder scons sind verfügbar.Genauso wie es unter Linux nicht das EINE Buildtool gibt.
Frachtkatamaran schrieb:
Es scheint auch keinen Ordner für DLLs zu geben (sowas wie /usr/lib )
im Windows-Verzeichnis gibt es natürlich einen Ordner. Es gibt sogar seit WinXP DLLs die per Version identifizierbar ist um Versionskonflickte zu vermeiden.
Wenn man keine Admin-Rechte hat, packt man notfalls die DLL in das gleiche Verzeichnis, wie die der EXE.Frachtkatamaran schrieb:
Die WinAPI selbst hat einen seltsame Aufbau und die ganzen typdefs Nerven mehr als sie helfen.
Ich kenne keine alte System-API die nicht merkwürdig ist. die Xlib ist auch nicht der Burner.
Frachtkatamaran schrieb:
Die ganzen OpenSource Bibliotheken lassen sich, wenn überhaupt nur mit massivem Aufwand bauen oder brechen mit mit seltsamen Fehlermeldungen ab.
Konkretes Beispiel?
Frachtkatamaran schrieb:
Bibliotheken wie wxWidgets (hab's mit 2.9 als auch mit 2.8) probiert solten sich doch unter Windows genauso einfach wie unter Linux übersetzen lassen (Das beste Ergebnis, dass ich erzielen konnte war dass die Programme, die gegen wx gelinkt waren direkt abgestürzt sind)
Was hat das mit Windows zu tun? Könnte ja nicht auch an wxWidgets liegen?
Vorallem weil wx eine Multiplattform-Lib ist und mal gar nichts mit Windows-only zu tun hat.Frachtkatamaran schrieb:
Sind meine Compiler kaputt? Ich bin zu blöd? Oder ist das unter Windows wirklich so schlimm?
Nö, unter Linux läuft es nur anders. Und auch dort musstest du dich hart einarbeiten! Die Fallstricke und das Knowhow hast du intus, und machst die alten Fehler nicht nochmal (oder zumindest nicht ein drittes Mal). Bei Windows fängst du bei Null an: Windows != Linux.
Du musst halt die Windows-Architektur lernen, dann die Tools, dann die APIs.
Übrigens, die Windows API ist Low Level. Wenn du sie als Vergleich heran ziehst, musst du auch eine Low-Level-API von Linux als Vergleich ran ziehen. Ich kenne aber ehrlich gesagt fast keine Anwendungen, die z.B. den X-Server-API nutzen. Die benutzen alle Hi-Level-APIs wie Qt oder GTK+. Das wäre unter Windows dann schon eher so was wie MFC und ATL und nicht WinAPI. Auch wenn die MFC auch nicht der Burner ist, ist sie schon viel einfacher als WinAPI.
-
Also ich komm beim Entwickeln auf Windows wunderbar klar. Unter Linux hätte ich vermutlich ähnliche Probleme wie der TE unter Windows. Man vergisst nur zu gerne die Mühen, die man auf sich nehmen musste, bis man sich fließend ausdrücken kann - ich durfte z.B. das DVCS meiner Wahl patchen damit ich mein Master Repository auf dem USB-Stick von Rechner zu Rechner mitschleppen kann.
Ich hab jetzt schon den Horror davor, irgendwann mal mein Projekt auf Linux portieren zu dürfen - sowas liegt aber nie am OS, sondern immer am Unverstand des Anwenders
-
Habe letytens SFML 2.0 auf Windows fuer VS2012 uebersetzt. Keine Probleme, wurde alles mitgeliefert. Ich bin ja mehr auf Linux zu Hause aber mit VS 2012 bin ich sehr zufrieden. Ja ist halt alles irgendwie anders unter Windows, who cares ...
-
Ach, es traut sich doch nur keiner "Ich find X/Y besser weil..." zu schreiben, weil man nicht wie ein flamender fanboy von X/Y, sondern wie ein weiser Überblickhabender wirken will.
-
Ich find Windows besser, weil..ich nicht unter Linux programmiere
Nein war Spass. Windows und Linux verfolgen nun einmal unterschiedliche Ansätze, und wenn man gewillt ist, unter dem jeweiligen BS zu programmieren, dann muss man sich eben auch mit diesen unterschiedlichen Ansätzen beschäftigen und diese so hinnehmen. Das gilt genauso für Android, IOS, Mac OS, usw.
Ein interessanter Text über das (leidige) Thema findet sich auch hier: http://www.felix-schwarz.name/files/opensource/articles/Linux_ist_nicht_Windows/
-
Burkhi schrieb:
Ein interessanter Text über das (leidige) Thema findet sich auch hier: http://www.felix-schwarz.name/files/opensource/articles/Linux_ist_nicht_Windows/
Wobei das und ähnliches jeder Windowsnutzer unter Linux an den Kopf geworfen bekommt. Ich finde es recht amüsant, wie nun ein Linuxnutzer auf den gleichen Artikel hingewiesen wird, wenn er nun zu Windows kommt.
Ich frage mich, wievielen Umsteigern von Windows nach Linux Frachtkatamaran diesen Artikel vor die Nase hielt. Und nun begeht er denselben Fehler in die andere Richtung.
Aber ich meine das Problem hat man ja nicht nur bei Betriebsystemen. Das Problem gibt es überall. Auch bei Programmiersprachen, Abläufen in Firmen oder wie in einer Familie nun Weihnachten gefeiert wird. Es wird alles überall etwas anders gemacht. Man muss lernen zu aktzeptieren, dass dies so ist, und wenn man anderswo was tun möchte, muss man sich halt anpassen.
Grüssli
-
Hallo,
Das sollte eigentlich kein Flame-Thread Linux gegen Windows. Für so etwas gibt es heise.deShade Of Mine schrieb:
Frachtkatamaran schrieb:
Inwiefern? Wenn ich mir http://msdn.microsoft.com/en-us/library/windows/desktop/ff381409%28v=vs.85%29.aspx ansehe, macht das nicht wirklich lust auf mehr.
Ja, weil http://xopendisplay.hilltopia.ca/2009/Mar/Xlib-tutorial-part-9----Buttons.html soviel besser ist.
Du machst hier einen Fehler und vergleichst die Xlib mit der WinAPI. Die Xlib bringt nicht mal Buttons mit. Und es werden heutzutage auch keine Anwenderprogramme mehr direkt in der Xlib entwickelt. Dafür nimmt man Gtk+, Qt, Motif, etc
Und?
Dann muss ich halt die ganzen Compilerflags und Libs in VS eintragen. Oder gibt's da was in den höheren Versionen. In VC Express konnte ich nicht der gleichen finden.Du nimmst einfach die passende Projektdatei und fertig.
???
Im ernst? Ich brauch für jede popelige DLL direkt einen COM-Server?
Genauso wie du für jede popelige .so einen Corba Server brauchst.
Ich kenne zwar die CORBA Technologie, aber brauchen tu ich sie nicht. Ist unter den Linux Distributionen auch gar nicht Standardmäßig vorinstalliert.
-
Artchi schrieb:
Frachtkatamaran schrieb:
Unter Linux kann ich mittels pkg-config alle Bibliotheken und Compilerflags einbinden unter Windows scheint es so etwas gar nicht zu geben.
Doch, gibt es: meistens wird für MSVC ein Projekt/Solution mitgeliefert. Notfalls schmeisst man nmake vom MSVC an.
Auch bjam oder scons sind verfügbar.Genauso wie es unter Linux nicht das EINE Buildtool gibt.
pkg-config ist aber kein Buildtool.
http://www.freedesktop.org/wiki/Software/pkg-config/[/quote]
Wenn man keine Admin-Rechte hat, packt man notfalls die DLL in das gleiche Verzeichnis, wie die der EXE.
Läuft das nicht irgendwo gegen die Philosophie von Gemeinsamen Bibliotheken?
Was hat das mit Windows zu tun? Könnte ja nicht auch an wxWidgets liegen?
Vorallem weil wx eine Multiplattform-Lib ist und mal gar nichts mit Windows-only zu tun hat.Hab ich das behauptet?
Ich kenne aber ehrlich gesagt fast keine Anwendungen, die z.B. den X-Server-API nutzen. Die benutzen alle Hi-Level-APIs wie Qt oder GTK+. Das wäre unter Windows dann schon eher so was wie MFC und ATL und nicht WinAPI. Auch wenn die MFC auch nicht der Burner ist, ist sie schon viel einfacher als WinAPI.
Also kann man Windows nur dann Highlevel Programmieren wenn man Geld zahlt?
-
Frachtkatamaran schrieb:
....
Also kann man Windows nur dann Highlevel Programmieren wenn man Geld zahlt?Nein, das kannst du auch problemlos mit dem GCC machen, und der kostet auch unter Windows nix. Oder in C# mit VS Express, Java mit Netbeans oder Eclipse. Die kosten auch nix. Und auch für Eclipse und Netbeans unter Windows gibt es C++ Compiler, ebenfalls kostenlos.
-
Frachtkatamaran schrieb:
Du machst hier einen Fehler und vergleichst die Xlib mit der WinAPI. Die Xlib bringt nicht mal Buttons mit. Und es werden heutzutage auch keine Anwenderprogramme mehr direkt in der Xlib entwickelt. Dafür nimmt man Gtk+, Qt, Motif, etc
Und es werden heutzutage auch keine Anwenderprogramme mehr direkt in der WinAPI entwickelt. Dafür nimmt man Qt, wxWidgets, MFC, VCL,...
Ich vergleiche Lowlevel API mit Lowlevel API.
Du nimmst einfach die passende Projektdatei und fertig.
???
Naja, statt "./configure ..." doppelklickst du die mitgelieferte VS Projekt Datei.
Genauso wie du für jede popelige .so einen Corba Server brauchst.
Ich kenne zwar die CORBA Technologie, aber brauchen tu ich sie nicht. Ist unter den Linux Distributionen auch gar nicht Standardmäßig vorinstalliert.
Das ist exakt mein Punkt. Du brauchst COM nicht, kann aber praktisch sein.
-
Frachtkatamaran schrieb:
Du machst hier einen Fehler und vergleichst die Xlib mit der WinAPI. Die Xlib bringt nicht mal Buttons mit. Und es werden heutzutage auch keine Anwenderprogramme mehr direkt in der Xlib entwickelt. Dafür nimmt man Gtk+, Qt, Motif, etc
In der WinAPI selbst wird auch nur noch wenig Neuentwicklung von Desktop-Apps betrieben. Klar ist die WinAPI nicht besonders hübsch
Was erwartest du.. das Teil ist sehr alt, über die Jahre stark gewachsen, sehr rückwärtskompatibel (damit auch alte Programme noch auf modernen Windows-Versionen laufen) und auch extrem umfangreich und mächtig. Die WinAPI baut im Kern eben auf Konzepten auf, die vor 20-30 Jahren modern waren.
Hat man sich aber erstmal in die "Denkweise" der WinAPI reingefunden, ist es halb so schlimm. Man darf halt kein modernes High-Level erwarten.Wer heute eine Neuentwicklung anstrebt, macht entweder MFC, ATL (gibt's beides ab VS Pro aufwärts) oder gleich .NET bzw. in Zukunft WinRT.
Du nimmst einfach die passende Projektdatei und fertig.
???
Eine gute Windows-Version einer Library liefert eine Projektmappe mit, die man mit VS öffnet und dann mit 'nem klick auf "Build All" die Library from scratch baut
Idealerweise kommt auch noch eine Projektvorlage für VS mit. AutoCAD macht das beispielsweise. Wenn man dann ein neues Projekt erstellt, macht man das auf Basis dieser Vorlage und die Verweispfade etc. sind schon richtig eingestellt.Ich kenne zwar die CORBA Technologie, aber brauchen tu ich sie nicht. Ist unter den Linux Distributionen auch gar nicht Standardmäßig vorinstalliert.
Du brauchst natürlich keinen COM-Server für eine normale DLL. Ich weiß nicht woran es genau bei dir gehakt hat, aber ich fühle mich nicht berufen, dem tiefer auf den Grund zu gehen
Frachtkatamaran schrieb:
Wenn man keine Admin-Rechte hat, packt man notfalls die DLL in das gleiche Verzeichnis, wie die der EXE.
Läuft das nicht irgendwo gegen die Philosophie von Gemeinsamen Bibliotheken?
Ja, wobei diese Philosophie nicht unbedingt die von Win ist (zumindest nicht seitdem SxS mit XP eingeführt wurde). Das hat Vor- und Nachteile, wie du dir sicher denken kannst.
-
Frachtkatamaran schrieb:
Wenn man keine Admin-Rechte hat, packt man notfalls die DLL in das gleiche Verzeichnis, wie die der EXE.
Läuft das nicht irgendwo gegen die Philosophie von Gemeinsamen Bibliotheken?
DLLs werden gerne verwendet um ein Programm "modularer" aufzubauen (solche Konstruktionen erkennst du dann meistens schon daran, das die DLLs im Arbeitsverzeichnis der Anwendung liegen). Das die im eigentlichen Sinne "gemeinsam verwendet" werden sollen trifft wohl eher seltener zu.
-
Frachtkatamaran schrieb:
Läuft das nicht irgendwo gegen die Philosophie von Gemeinsamen Bibliotheken?
Man muss nicht. Man kann. Und was macht man unter Linux, wenn man
A) keine Root-Recht hat?
zwei unterschiedliche LIB-Versionen auf einmal nutzen will?Frachtkatamaran schrieb:
Also kann man Windows nur dann Highlevel Programmieren wenn man Geld zahlt?
Nö, MFC war nur ein Beispie, das direkt von MS kommt. Es gibt auch kostenlose Compiler, IDEs und Hilevel-APIs. Z.B. gibt es die zur MFC konkurrierende VCL als kostenlose Variante.
Es gibt auch noch andere (Open Source) Hi-Level-APIs, die alles einfacher und schöner machen als die Win32-API.
Und ja, Win32 API steht in Konkurrenz zur Xlib. Und wenn es die nicht ist, dann wahrscheinlich X Toolkit (Xt) Intrinsics? Ach neee, stimmt... das ist es auch nicht. Man muss ja Xaw oder Motif nutzen, wenn man auf den wirklich historisch originalen Libraries seine Apps bauen will.
https://en.wikipedia.org/wiki/Intrinsics
https://en.wikipedia.org/wiki/XawAlso, historisch bedingt kann sich keiner von den beiden Fraktionen (X und Win32) mit Ruhm bekleckern.
Es gibt nicht umsonst neuere Libraries und Frameworks, die auf die alten API aufsetzen, um sie vor dem Programmierer zu verstecken.
-
Cpp_Junky schrieb:
solche Konstruktionen erkennst du dann meistens schon daran, das die DLLs im Arbeitsverzeichnis der Anwendung liegen
Gerade DAS wird ja vielfach an Windows kritisiert.
*Keine sinnvolle Paketverwaltung
*Kein soname
*DLL-HellArtchi schrieb:
Man muss nicht. Man kann. Und was macht man unter Linux, wenn man
A) keine Root-Recht hat?
zwei unterschiedliche LIB-Versionen auf einmal nutzen will? Für sowas gibt es unter Linux (eigentlich jedes System mit ELF) somane.
Die so Datei ist dann ein Link auf die richtige Version
A) Normalerweise ist auf dem System alles drauf, was man braucht. Wenn nicht wendet man sich an den Administrator.Zur WinAPI sollte man sagen: "Alte Zöpfe abschneiden". Und was die Abwärtskompatibilität angeht so könnte man einen Layer einbauen. Hat ja mit DirectX ja auch geklappt.
Außerdem soll die Abwärtskompatibilität unter Windows auch nicht der Renner sein.
-
Frachtkatamaran schrieb:
Gerade DAS wird ja vielfach an Windows kritisiert.
*Keine sinnvolle Paketverwaltung
*Kein soname
*DLL-HellDie Kritik hab ich interessanterweise bisher nur von Leuten gehört, deren eigentliches Problem mit Windows ist, dass es nicht Linux ist...
Frachtkatamaran schrieb:
Für sowas gibt es unter Linux (eigentlich jedes System mit ELF) somane.
Die so Datei ist dann ein Link auf die richtige VersionUnd unter Windows gibts eben Side by Side Assemblies...
Frachtkatamaran schrieb:
A) Normalerweise ist auf dem System alles drauf, was man braucht. Wenn nicht wendet man sich an den Administrator.
Ist ja unter Windows auch nicht anders...
Frachtkatamaran schrieb:
Zur WinAPI sollte man sagen: "Alte Zöpfe abschneiden". Und was die Abwärtskompatibilität angeht so könnte man einen Layer einbauen. Hat ja mit DirectX ja auch geklappt.
Na dann schau mal, was WinRT ist...
-
dot schrieb:
Frachtkatamaran schrieb:
Gerade DAS wird ja vielfach an Windows kritisiert.
*Keine sinnvolle Paketverwaltung
*Kein soname
*DLL-HellDie Kritik hab ich interessanterweise bisher nur von Leuten gehört, deren eigentliches Problem mit Windows ist, dass es nicht Linux ist...
Vielleicht, weil es unter Linux besser gelöst ist?
Frachtkatamaran schrieb:
Für sowas gibt es unter Linux (eigentlich jedes System mit ELF) somane.
Die so Datei ist dann ein Link auf die richtige VersionUnd unter Windows gibts eben Side by Side Assemblies...
Die kannte ich nicht, werd' ich mir mal ansehen.
Frachtkatamaran schrieb:
A) Normalerweise ist auf dem System alles drauf, was man braucht. Wenn nicht wendet man sich an den Administrator.
Ist ja unter Windows auch nicht anders...
Office
Shell
Fenstermanager
etcFrachtkatamaran schrieb:
Zur WinAPI sollte man sagen: "Alte Zöpfe abschneiden". Und was die Abwärtskompatibilität angeht so könnte man einen Layer einbauen. Hat ja mit DirectX ja auch geklappt.
Na dann schau mal, was WinRT ist...
[/quote]
WinRT scheint nur für Metro-Apps zu sein. Und in Metro sehe ich ehrlich gesagt keine Zukunft.
-
Frachtkatamaran schrieb:
Gerade DAS wird ja vielfach an Windows kritisiert.
*Keine sinnvolle Paketverwaltung
*Kein soname
*DLL-HellNein, wird es nicht.
MfG SideWinder
-
Naja, so einen gewissen Vorteil hat das Linux System bezüglich der standardisierten include pfade etc schon :).
Wundere mich warum M$ in die Richtung nie etwas getan hat.
Klar, es geht auch so, aber es hätte schon Vorteile eine Buildumgebung wie unter Linux zu haben :).
