Entwickeln unter Windows - Eine Nervenraubende Sache?

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?

GPC

Frachtkatamaran schrieb:

Hallo,
Das sollte eigentlich kein Flame-Thread Linux gegen Windows. Für so etwas gibt es heise.de

Für einen kurzen Moment dachte ich, du meinst das ernst. Offensichtlich habe ich mich aber getäuscht. Troll dich.

Shade Of Mine schrieb:

Selten so ne dumme argumentation gehoert...

Wieso? Wenn man sich an MS binden will vielleicht. Wenn man aber Platformunabhängig entwickeln will, wird man kaum zu .Net greifen.

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

Hab sogar schon mal damit programmiert.
Gtk+ hat für C ein schöner Aufbau.
Da man C als Kern genommen hat kann man auch einfacher Wrapper für andere Sprachen wie C++, Java, Fortran, Python etc schreiben. Mit C++ müsste man erst einen C Wrapper erstellen und dann auf die anderen Sprachen portieren.
Auch scheint es im Linux/Unix Bereich mehr C Fans als zu geben, die mit C++ nicht so wirklich was anzufangen wissen oder wissen wollen.

GPC schrieb:

Frachtkatamaran schrieb:

Hallo,
Das sollte eigentlich kein Flame-Thread Linux gegen Windows. Für so etwas gibt es heise.de

Für einen kurzen Moment dachte ich, du meinst das ernst. Offensichtlich habe ich mich aber getäuscht. Troll dich.

Am Anfang schon. Aber irgendwie schien man garnicht auf meine Kommentare einzugehen und nur aufzuzählen was unter Linux schlechter ist. Sei es drum.

Zeus

Frachtkatamaran schrieb:

GPC schrieb:

Frachtkatamaran schrieb:

Hallo,
Das sollte eigentlich kein Flame-Thread Linux gegen Windows. Für so etwas gibt es heise.de

Für einen kurzen Moment dachte ich, du meinst das ernst. Offensichtlich habe ich mich aber getäuscht. Troll dich.

Am Anfang schon. Aber irgendwie schien man garnicht auf meine Kommentare einzugehen und nur aufzuzählen was unter Linux schlechter ist. Sei es drum.

Verzehrte Wahrnehmmung? Andere haben dir gesagt, dass Windows anders ist, während du aufgezählt hast, was irgendwer in Windows vermissen würde.

Dravere

Frachtkatamaran schrieb:

Wieso? Wenn man sich an MS binden will vielleicht. Wenn man aber Platformunabhängig entwickeln will, wird man kaum zu .Net greifen.

Wieso nicht? Entwickle die Logik und co mit C++, verwende dazu Boost und für die Anzeige nimmst du .Net. Kannst dir eine Schnittstelle zu .Net in C++/CLI bauen, P/Invoke verwenden oder sogar ein COM-Interface wählen.

Habe ich auch schon gemacht. Auf Linux sind viele daran gewohnt ein Programm per Kommandozeile zu verwenden. Daher habe ich ein Programm entwickelt, welches unteranderem per Kommandozeile bedient werden konnte. Unter Windows habe ich mit .Net ein GUI angeboten. Da ich Logik, Persistenz und Anzeige sauber getrennt habe, hätte ich auch per Gtk ein GUI unter Linux anbieten können.

Zudem gäbe es ja auch noch Mono.

Kommt alles auf die Anwendung drauf an.

Grüssli

Artchi

Frachtkatamaran schrieb:

Wieso? Wenn man sich an MS binden will vielleicht. Wenn man aber Platformunabhängig entwickeln will, wird man kaum zu .Net greifen.

C# und die .NET-Basis sind nicht proprietär, es ist ECMA und ISO standardisiert.

Deshalb gibt es Mono.

Aber egal... bleiben wir bei Windows: du sagst, wenn man sich nicht binden will. OK, aber was hat das noch mehr mit Win32-API und WIndows-ENtwicklung zu tun, wenn es dir eh nicht um spezielle Win32-Entwicklung geht? Dann hast du doch noch weniger Grund dich über Windows aufzuregen. Weil du gar kein Win32 direkt nutzen darfst, sondern nur Qt, GTK+ etc.

Dravere schrieb:

Wieso nicht? Entwickle die Logik und co mit C++, verwende dazu Boost und für die Anzeige nimmst du .Net. Kannst dir eine Schnittstelle zu .Net in C++/CLI bauen, P/Invoke verwenden oder sogar ein COM-Interface wählen.

Ja sicher, aber dafür muss man auf jeder Plattform eine eigene Oberfläche schreiben. Je nachdem wie Komplex deine GUI ist macht man das nicht mal so.

Dravere schrieb:

Zudem gäbe es ja auch noch Mono.

Mono ist in Linux-Kreisen eher verpönt, da von M$, U-Bootpatente und was weiß ich alles.

Artchi schrieb:

C# und die .NET-Basis sind nicht proprietär, es ist ECMA und ISO standardisiert.

Ja und nein. CLI, was eine Teilmenge von .Net ist und C# bis Version 2 sind Standardisiert. Aber das interessante Zeug wie XAML und LINQ fällt meiner Meinung nach nicht darunter.

Artchi schrieb:

Aber egal... bleiben wir bei Windows: du sagst, wenn man sich nicht binden will. OK, aber was hat das noch mehr mit Win32-API und WIndows-ENtwicklung zu tun, wenn es dir eh nicht um spezielle Win32-Entwicklung geht? Dann hast du doch noch weniger Grund dich über Windows aufzuregen. Weil du gar kein Win32 direkt nutzen darfst, sondern nur Qt, GTK+ etc.

Ja wir sind vom Thema abgekommen. Wenn man sich aber nicht an eine Plattform wie Qt oder wx binden will kommt man gar nicht drum herum die Systemfunktionen zu kapseln.

hustbaer

Frachtkatamaran schrieb:

Wenn man sich aber nicht an eine Plattform wie Qt oder wx binden will kommt man gar nicht drum herum die Systemfunktionen zu kapseln.

Und was ist da bei den ganzen unixoiden Systemen anders?