Entwickeln unter Windows - Eine Nervenraubende Sache?

Dobi

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.

Burkhi

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/

Dravere

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.de

Shade 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?

Burkhi

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.

Shade Of Mine

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.

GPC

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.

Cpp_Junky

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.

Artchi

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/Xaw

Also, 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-Hell

Artchi 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.

dot

Frachtkatamaran schrieb:

Gerade DAS wird ja vielfach an Windows kritisiert.
*Keine sinnvolle Paketverwaltung
*Kein soname
*DLL-Hell

Die 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 Version

Und 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-Hell

Die 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 Version

Und 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
etc

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...

[/quote]
WinRT scheint nur für Metro-Apps zu sein. Und in Metro sehe ich ehrlich gesagt keine Zukunft.

SideWinder

Frachtkatamaran schrieb:

Gerade DAS wird ja vielfach an Windows kritisiert.
*Keine sinnvolle Paketverwaltung
*Kein soname
*DLL-Hell

Nein, 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 :).

rapso

vielleicht weil fuer windows die build umgebung nur ein stueck vom ganzen usecase ist, waehrend linux von codern geschrieben ist. der windowsNT kernel hat ja auch intern alles per pfade gemounted z.b. "CreateFile("\\\.\\PhysicalDrive1"... ", nur oben drueber kommt dann WinApi/CRT und macht c:\\
afaik sind auch alle anderen devices so gemounted (camera, sound card etc), weil man die windows welt in ein schwarzes loch stuertzen wuerde fuer ne weile wenn man alles umstellen wuerde (der grund weshalb das meiste an software immer noch 32bit ist, 10jahre nach WinXP64 afaik).

auf der anderen seite hatte ich schon oft, dass zwischen den linux distributionen ziemliche unterschiede existieren was build umgebung angeht. homebrew fuer PS3, PS2, PSP, GBA etc. konnte ich jeweils nur auf ganz bestimmten konfigurationen bauen. einfach nur eine paar tage zu neue fedora version und ich hatte eine neue gcc und irgendwas mit binutils oder so war zu irgendwelchen anderen modulen inkompatibel. es hat mich ein paar wochen gekostet die PS3 toolchain zu erstellen. es dauert jedesmal 12h+ alles zu bauen und es gibt keinen sonderlichen dependency graph, wenn ich etwas aender und 'sicher gehen will', muss ich komplet clean anfangen, configure etc.

und was ich bei linux software leider oft sah ist dass mit "" statt <> included wird, weil scheinbar alles im enviropment ist und es eh keinen unterschied macht, esseiden man will es mal auf win oder osx bauen. vielleicht nicht bei grossen dingen die eh cross platform bauen, aber ich hab manchmal in kleinen open source projekten geholfen und dann suckt sowas extrem. (auf der anderen seite sind wiederrum die win includes komplett nicht case sensitive geschrieben, was aber irgendwie noch leichter zu loesen ist, da man das build system nicht umschreiben muss).

my2cent

dot

Scorcher24 schrieb:

Klar, es geht auch so, aber es hätte schon Vorteile eine Buildumgebung wie unter Linux zu haben :).

Ein Betriebssystem ist ein Betriebssystem und ein Buildsystem ist ein Buildsystem. Ich persönlich seh keinen Grund, wieso man diese beiden Dinge vermischen sollte. Der User hat absolut keinen Vorteil davon und als Entwickler hab ich das persönlich auch noch nie als Nachteil erlebt. Und ja, ich hab auch schon genug unter Linux entwickelt.

Shade Of Mine

Frachtkatamaran schrieb:

Vielleicht, weil es unter Linux besser gelöst ist?

Nope. Es ist fast gleich gelöst.

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
etc

Der Admin installiert alles wichtige und der User lässt die Finger von Softwareinstallationen.

WinRT scheint nur für Metro-Apps zu sein. Und in Metro sehe ich ehrlich gesagt keine Zukunft.

Diese Argumentation führt ins Nirvana.

APIs sind APIs und die wird es immer geben. Ein Vergleich von enorm alten APIs miteinandr ist uninteressant. Schau dir lieber an was aktuell verwendet wird und vergleiche das.

Shade Of Mine schrieb:

Frachtkatamaran schrieb:

Vielleicht, weil es unter Linux besser gelöst ist?

Nope. Es ist fast gleich gelöst.

Es gibt unter Windows Pakte mit Abhängigkeitsüberprüfung.

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
etc

Der Admin installiert alles wichtige und der User lässt die Finger von Softwareinstallationen.
[/quote]
Wenn man aber sein eigener Admin ist ...

APIs sind APIs und die wird es immer geben. Ein Vergleich von enorm alten APIs miteinandr ist uninteressant. Schau dir lieber an was aktuell verwendet wird und vergleiche das.

Welche das Wären?
*WinRT?
WinRT soll laut [url] http://www.it-visions.de/lserver/artikeldetails.aspx?b=6241 [/url] eine moderne Variante der WinAPI sein. Kommt aber erst mit Windows8. Und basiert auf COM (ob das Performance mäßig so gut ist )
*.Net?
Ist nett. Benötigt aber eine proprietäre Sprache, die nicht mal auf der Maschine läuft.
*MFC?
Sieht alt aus, ist auch alt und benutzt einen C++ Stil der vielleicht mal in den 90ern Modern war. Also lange bevor es einen C++ Standard gab.

Shade Of Mine

Frachtkatamaran schrieb:

Es gibt unter Windows Pakte mit Abhängigkeitsüberprüfung.

Was wundert dich daran. Man loest unter Windows die Probleme anders aber man loest sie trotzdem. Meistens installiert man einfach alle abhaengigkeiten mit.

Aber eigentlich meinte ich die "DLL Hell" ist gleich geloest.

Wenn man aber sein eigener Admin ist ...

Dann wirst du es schon schaffen die MSI Datei doppelt zu klicken. Aber wir schweifen vom Thema ab.

*.Net?
Ist nett. Benötigt aber eine proprietäre Sprache, die nicht mal auf der Maschine läuft.

Selten so ne dumme argumentation gehoert...

*MFC?
Sieht alt aus, ist auch alt und benutzt einen C++ Stil der vielleicht mal in den 90ern Modern war. Also lange bevor es einen C++ Standard gab.

Jo und? Schonmal gtk gesehen? Das ist ja nichtmal C++.

Weiters gibt es zB noch die ATL oder eben Qt, wxWidgets, VCL, ...

Was genau ist denn deine Frage?