Entwickeln unter Windows - Eine Nervenraubende Sache?
-
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 :).
-
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
-
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.
-
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
etcDer 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
etcDer 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.
-
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?
-
Frachtkatamaran schrieb:
Hallo,
Das sollte eigentlich kein Flame-Thread Linux gegen Windows. Für so etwas gibt es heise.deFü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.deFü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.
-
Frachtkatamaran schrieb:
GPC schrieb:
Frachtkatamaran schrieb:
Hallo,
Das sollte eigentlich kein Flame-Thread Linux gegen Windows. Für so etwas gibt es heise.deFü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.
-
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
-
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.
-
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?
-
Frachtkatamaran schrieb:
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.
Mit der Einstellung kommt man natürlich nicht weit. Schade, denn Microsoft war endlich mal so weit, die Karten mit ISO/ECMA auf den Tisch zu legen, eine Shared Source CLI 2.0 zu veröffentlichen und im Gegensatz zu Oracle mit Java nicht jeden gleich zu verklagen, der etwas mit C# und .NET herumfummelt.
Frachtkatamaran schrieb:
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.
Es gibt einen Grund. Technisch gesehen sind die Dinge wie etwa XAML und LINQ auf einer .NET 2.0 CLR lauffähig, aber die Libraries zu implementieren ist ohne NT Kernel nicht sinnvoll und sehr aufwändig. Gerade etwa XAML als Grundtechnologie macht fast nur sinn Sinn, wenn man es in Verbindung mit WPF nutzen kann, welches selbst direkt auf Direct3D und anderen Technologien von Microsoft aufsetzt. Da stecken unzählige Features drin, die mit einem UI-Framework à la Qt nie realisierbar wären. Ein Äquivalent gibt es ausserhalb von Windows schlicht nicht - mit grosser Mühe wurde es auf dem Mac mit Silverlight so halbwegs lauffähig gemacht.
Prinzipiell ist es aber jedem erlaubt, ein Framework à la WPF aus dem Boden zu stampfen. Warum das nicht passiert? Komplexität!
-
/rant/ schrieb:
Frachtkatamaran schrieb:
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.
Es gibt einen Grund. Technisch gesehen sind die Dinge wie etwa XAML und LINQ auf einer .NET 2.0 CLR lauffähig, aber die Libraries zu implementieren ist ohne NT Kernel nicht sinnvoll und sehr aufwändig. Gerade etwa XAML als Grundtechnologie macht fast nur sinn Sinn, wenn man es in Verbindung mit WPF nutzen kann, welches selbst direkt auf Direct3D und anderen Technologien von Microsoft aufsetzt. Da stecken unzählige Features drin, die mit einem UI-Framework à la Qt nie realisierbar wären. Ein Äquivalent gibt es ausserhalb von Windows schlicht nicht - mit grosser Mühe wurde es auf dem Mac mit Silverlight so halbwegs lauffähig gemacht.
Prinzipiell ist es aber jedem erlaubt, ein Framework à la WPF aus dem Boden zu stampfen. Warum das nicht passiert? Komplexität!
Dabei ist XAML und LINQ schon von Mono/Moonlight implementiert, aber wo kein Bedarf ist, wird's auch nicht weiterentwickelt.
-
/rant/ schrieb:
Mit der Einstellung kommt man natürlich nicht weit. Schade,
Die Aussage kommt ja nicht von mir sondern ließt man in etlichen Foren.
"Icaza ist ein Verräter",
"M$ will Linux mit Mono unterwandern",
"M$ will Linux Windowfizieren",
"Was .Net kann, kann Java schon lang",
".Net ist proprietärer Müll" ...denn Microsoft war endlich mal so weit, die Karten mit ISO/ECMA auf den Tisch zu legen, eine Shared Source CLI 2.0 zu veröffentlichen und im Gegensatz zu Oracle mit Java nicht jeden gleich zu verklagen, der etwas mit C# und .NET herumfummelt.
Im Gegensatz zu Java ist .Net noch eher klein. Da zu Klagen wäre eher kontraproduktiv. Aber genau darauf begründet sich die Angst vor Mono. Das "U-Boot" Mono geht auf Schleichfahrt bis es eine kritische Masse erreicht hat und BUUUM! Microsoft lässt die (Patent-)Bombe platzen und viele Potentielle Anwender/Entwickler würden aus Angst verklagt zu werden zu Windows zurück fliehen.
Es gibt einen Grund. Technisch gesehen sind die Dinge wie etwa XAML und LINQ auf einer .NET 2.0 CLR lauffähig, aber die Libraries zu implementieren ist ohne NT Kernel nicht sinnvoll und sehr aufwändig. Gerade etwa XAML als Grundtechnologie macht fast nur sinn Sinn, wenn man es in Verbindung mit WPF nutzen kann, welches selbst direkt auf Direct3D und anderen Technologien von Microsoft aufsetzt. Da stecken unzählige Features drin, die mit einem UI-Framework à la Qt nie realisierbar wären. Ein Äquivalent gibt es ausserhalb von Windows schlicht nicht - mit grosser Mühe wurde es auf dem Mac mit Silverlight so halbwegs lauffähig gemacht.
Warum? XAML ist ja nichts anderes als XML. Und Oberflächen mit XML zu programmieren ist in Qt, wxWidgets als auch in Gtk+ problemlos möglich. Ich sehen keinen Grund warum dass nicht Portieren könnte. WPF, dass seine Widget über die Grafikkarte rendert könnte man unter X11 mit Cairo und OpenGL ermöglichen.
PS: Das Forum hier scheint ja eher Pro MS eingestellt zu sein. Wenn ich jetzt an andere Foren denke, wo jeder nur Linux nutzt und beruflich/privat nur für Linux entwickelt. Über Windows nur spottet und das baldige Ende Microsofts prognostiziert bin ich doch etwas überrascht.
