Entwickeln unter Windows - Eine Nervenraubende Sache?
-
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.
-
Frachtkatamaran schrieb:
Die Aussage kommt ja nicht von mir sondern ließt man in etlichen Foren.
Ja wenn du das in "etlichen Foren" gelesen hast, dann muss das natürlich stimmen...wenn du wüsstest, was ich alles schon in "etlichen Foren" so gelesen hab...
Frachtkatamaran schrieb:
"M$ will Linux mit Mono unterwandern",
Sry, das ist einfach nur bescheuert, Mono hat mit Microsoft nichts zu tun.
Frachtkatamaran schrieb:
"M$ will Linux Windowfizieren",
Klar, genau darum hat "M$" ja auch dieses "Mono" Projekt in die Welt gesetzt...
Frachtkatamaran schrieb:
"Was .Net kann, kann Java schon lang",
".Net ist proprietärer Müll" ...Tjo, sowas kann nur von Leuten kommen, die keine Ahnung haben was .NET ist. Denn wenn sie Ahnung hätten, dann wüssten sie, dass .NET Java in technischer Hinsicht weit überlegen ist. Schade, dass diese Leute Mono so verteufeln, statt eine tatsächlich freie und auch noch bessere Technologie, die noch dazu bereits als Open Source Implementierung zur Verfügung steht, zu umarmen und sich endlich von Java zu trennen. Denn im Gegensatz zu Microsoft steht mit Oracle hinter Java wirklich ein Konzern, mit dem ich nichts würde zu tun haben wollen...
Frachtkatamaran schrieb:
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.
Setz dich mal damit auseinander, was Oracle mit Java so treibt. Und dann überleg dir nochmal, wo du jetzt U-Boote zu sehen glaubst...
Frachtkatamaran schrieb:
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.
Könnte man. Und niemand hindert dich dran, das zu implementieren. Aber anstatt das einfach zu machen, wird natürlich lieber über dieses "M$" geschimpft...
Frachtkatamaran schrieb:
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.
Ja, da hast du mich jetzt überzeugt, was soll man gegen solche Argumente noch sagen, das klingt tatsächlich nach Leuten, die wirklich voll den Durchblick haben müssen...
Mein Tipp: Informier dich mal selbst, anstatt einfach alles zu glauben, was irgendwelche Leute so von sich geben; auch wenn sie sich wie ganz die coolen Checker geben. Oder noch besser: Ganz besonders dann...
-
dot schrieb:
Frachtkatamaran schrieb:
Die Aussage kommt ja nicht von mir sondern ließt man in etlichen Foren.
Ja wenn du das in "etlichen Foren" gelesen hast, dann muss das natürlich stimmen...wenn du wüsstest, was ich alles schon in "etlichen Foren" so gelesen hab...
Ich muss sagen, ich mag Mono auch nicht. Ich weiß, ist nicht repräsentativ - nur meine Meinung. Obwohl ich meist Windows nutze und jahrelang beruflich und privat C# programmiert habe und das auch auch sehr gut finde, würde ich Mono unter Linux nur sehr ungern nutzen und sicher nicht dafür entwickeln (Java auch nicht, außer auf dem Server als J2EE, aber sicher keine Enduser Software). Linux ist einfach eine andere Welt und da passt Mono nicht, macht keinen Sinn, wird sich nicht durchsetzen. Unter Linux bin ich eher spartanisch unterwegs (absichtlich), mit Arch Linux, einem sehr schlanken Tiling window Manager, die allermeisten Anwendungen die ich nutze sind Kommandozeilen Anwendungen bestenfalls mit einem curses Frontend, außer Firefox und Thunderbird. Für einen Neuling, der sich mal Ubuntu angeschaut hat und noch wenig Ahnung hat, mag es egal sein, er wird auch Mono nehmen. Aber wenn man sich auskennt, wird man sich meist nach Monofreien Alternativen umschauen und meist auch welche finden. Weil native Monoanwendungen für Linux gibt es meines Wissens nicht. Das sind nur Windows Programme, die man versucht irgendwie unter Linux zum Laufen zu bekommen. Ich kenne niemanden, der primär für Linux entwickeln will und sich grad Mono als Plattform aussucht.
-
dot schrieb:
Frachtkatamaran schrieb:
Die Aussage kommt ja nicht von mir sondern ließt man in etlichen Foren.
Ja wenn du das in "etlichen Foren" gelesen hast, dann muss das natürlich stimmen...wenn du wüsstest, was ich alles schon in "etlichen Foren" so gelesen hab...
Hab ich das irgendwo behauptet? Nein, hab ich nicht!
Frachtkatamaran schrieb:
"M$ will Linux mit Mono unterwandern",
Sry, das ist einfach nur bescheuert, Mono hat mit Microsoft nichts zu tun.
Frachtkatamaran schrieb:
"M$ will Linux Windowfizieren",
Klar, genau darum hat "M$" ja auch dieses "Mono" Projekt in die Welt gesetzt...
Gängigen Verschwörungstheorien nach schon. Die Aussage stammt aber nicht von mir!
Frachtkatamaran schrieb:
"Was .Net kann, kann Java schon lang",
".Net ist proprietärer Müll" ...Tjo, sowas kann nur von Leuten kommen, die keine Ahnung haben was .NET ist. Denn wenn sie Ahnung hätten, dann wüssten sie, dass .NET Java in technischer Hinsicht weit überlegen ist. Schade, dass diese Leute Mono so verteufeln, statt eine tatsächlich freie und auch noch bessere Technologie, die noch dazu bereits als Open Source Implementierung zur Verfügung steht, zu umarmen und sich endlich von Java zu trennen. Denn im Gegensatz zu Microsoft steht mit Oracle hinter Java wirklich ein Konzern, mit dem ich nichts würde zu tun haben wollen...
Und hinter .Net steht ein Konzern der offen zu gibt, dass er OpenSource nicht ausstehen kann und es als Bedrohung sieht. Davon abgesehen hat MS schon in der Vergangenheit Konkurrenten durch unfaire Mittel vom Markt gekickt.
Setz dich mal damit auseinander, was Oracle mit Java so treibt. Und dann überleg dir nochmal, wo du jetzt U-Boote zu sehen glaubst...
Die Ansicht mit dem Uboot ist so alt wie mono selbst. also aus einer Zeit als java noch zu Sun gehörte. Und nochmals. Die Aussagen stammen nicht von mir.
Geh doch einfach in die entsprechenden Foren / Mailinglisten rein und erzähl denen deine Thesen.Könnte man. Und niemand hindert dich dran, das zu implementieren. Aber anstatt das einfach zu machen, wird natürlich lieber über dieses "M$" geschimpft...
Nö anstatt einfach zu machen wollen die Mono Entwickler Geld sehen (Ja auch OpenSOurce Entwickler leben entgegen gängiger Klischees nicht von der Luft und der Liebe) und konzentrieren sich auf die neuen Mobile Plattformen, als Android, iOS ...
Wenn du das aber doch so toll findest, warum setzt du dich dann nicht hin, und bastelst dran rum?Frachtkatamaran schrieb:
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.
Ja, da hast du mich jetzt überzeugt, was soll man gegen solche Argumente noch sagen, das klingt tatsächlich nach Leuten, die wirklich voll den Durchblick haben müssen...
ja wirklich. Aber vielleicht hätte ich es für Leute wie dich, extra kennzeichnen sollen, dass es sich dabei um eine einfache Festellung handelt.
Mein Tipp: Informier dich mal selbst, anstatt einfach alles zu glauben, was irgendwelche Leute so von sich geben; auch wenn sie sich wie ganz die coolen Checker geben. Oder noch besser: Ganz besonders dann...
-
so ein troll thread
