Windows 8 Metro Apps nur noch mit .NET möglich?
-
Na dann, Mahlzeit:
<°)))><
-
Ah jetzt bist du mir zuvor gekommen. Also ich hab alle Infos selbst herausgefunden
Also es ist definitiv so, dass VS für Windows 8 NUR für die Metro-Apps ist. Für die gewöhnlichen Desktop Anwendungen (auch bei Windows
braucht man die Desktop Version.
Quelle: http://www.kwaschny.net/blog/1781/Difference-between-Visual-Studio-2012-Windows-8-and-Windows-Desktop
(Und unter anderem noch durch andere Funde bestätigt)Beefi schrieb:
- Die einzige Einschränkung an der Express Version (nur auf NET-Programmierung betrachtet) die einen etwas stören könnte, ist, dass man nur 32-Bit kompilieren kann.Das ist falsch.
Dass man nur 32-Bit kompilieren kann, oder dass es keine gravierende Einschränkung gibt, die man jetzt nicht unbedingt braucht. Was würdest du an der Express denn vermissen?
Da wir für unsere Schulungen per MSDNAA/Dreamspark alle Microsoft Produkte kostenlos bekommen (mit Einschränkung von nicht-kommerzieller Nutzung), ist natürlich ein Reiz zur Professional, Premium oder Ultimate Version da (auch wenn man es nicht wirklich braucht). Du würdest mir bestimmt zustimmen, dass es kontraproduktiv wäre, wenn ich diese Produkte zum wiedereinfinden und einlernen nutze, wenn ich letztendlich bei Express landen will. Oder?
VS geht bei über 600 EUR erst los...für ein C#-Windows-Hobby möchte ich das nicht unbedingt, wenn eigentlich C/C++ und Assembler beruflich wirklich wichtig für mich ist.
Deswegen wollte ich diesen C++ Zwang nutzen und noch ein ideales GUI Toolkit dazu lernen...deshalb eigentlich der Thread
Aber von C++/CLI (womit ich nur geringste Praxiserfahrung habe), höre ich immer nur Horrorgeschichten...C# hingegen flutscht sehr gut.
Und es ist eigentlich auch ein sehr gutes Argument, dass man bei der Betriebssystemeigenenen Lösung bleiben sollte. Ich hab ja selbst meine Erfahrung damit früher gemacht. Ich kenne Qt aber zu wenig um darüber urteilen zu können.Interessant, was da für eine Diskussionrunde ging, als ich diesen Text schrieb
-
und VB/C(++).. sind nunmal nicht .NET
sondern lediglich "eingeflossen"Was ist denn dann .NET?
C++/CLI, C#, VB,...das sind doch alles Programmiersprachen für das NET-Framework.
-
Beefi schrieb:
Wer für Windows entwickelt und dafür was anderes als Visual Studio verwendet, dem kann man imo sowieso nicht helfen...
Ja eigentlich stimmt das ganze schon.
Irgendeinen Grund muss es ja gegeben haben das MS zb Java in .NET integriert hat ^^
Und alles was den Horizont vom MS OOP-Modell übersteigt erfordert sowieso
andere Sprachen wie wär s mit Mathe zb..
..oder 3D - Grafikkarten sind nunmal keine OOP Prozessoren ^^Davon abgesehen gelten die Intel IDEs/Compiler wohl nach wie vor
als das Beste was im zivilen Bereich zu kriegen ist..Beefi schrieb:
COM/DCOM hat mit .NET nichts zu tun, das sind zwei völlig unabhängige Technologien.
Da geb ich dot recht. Damit hatte ich schon in den 90ern zu tun, wo es NET noch gar nicht gab.
Wie gesagt da jede DLL ein COM Object darstellt ist natürlich auch .NET
daran gebunden.. denk mal drüber nach was unter Windows OHNE dll s auskommt.
-
denk mal drüber nach was unter Windows OHNE dll s auskommt.
Aber unter Linux sind die Programme doch eigentlich auch so gut wie immer Abhängig von anderen "DLLs"...in dem fall halt .o's
Oder meinen wir gerade was anderes? Ich fand die DLL-Geschichte eigentlich immer sehr angenehmIrgendeinen Grund muss es ja gegeben haben das MS zb Java in .NET integriert hat
Damit man nicht extra ne neue Sprache lernen muss um mit .NET zu proggen
oder 3D - Grafikkarten sind nunmal keine OOP Prozessoren
Das verstehe ich nicht...würde mich aber interessieren wie es gemeint ist.
EDIT:
Wie gesagt da jede DLL ein COM Object darstellt ist natürlich auch .NET
daran gebunden.. denk mal drüber nach was unter Windows OHNE dll s auskommt.Jetzt versteh ich glaub ich was du meinst. Aber nicht, warum es schlimm ist
-
Beefi schrieb:
denk mal drüber nach was unter Windows OHNE dll s auskommt.
Aber unter Linux sind die Programme doch eigentlich auch so gut wie immer Abhängig von anderen "DLLs"...in dem fall halt .o's
Oder meinen wir gerade was anderes? Ich fand die DLL-Geschichte eigentlich immer sehr angenehmIn Linux Lib s kannst du für gewöhnlich immer in die Lib s "reingucken"
(wenige Ausnahmen proprietärer Software mal ausgenommen)
bei MS gibts endlos viel Undokumentiertes/nicht verfügbares Quellmaterial
was mit der Nähe zu Ring0 drastisch zunimmt.Beefi schrieb:
Irgendeinen Grund muss es ja gegeben haben das MS zb Java in .NET integriert hat
Damit man nicht extra ne neue Sprache lernen muss um mit .NET zu proggen
MS ist ein Unternehmen das wirtschaftet die "schenken" nichts..
..Java hat denen damals (Anfänge und Pubertät des Internet)
kräftig den Rang abgelaufen..
..daran hat sich bis heute nicht viel geändert http://www.tiobe.com/index.php/content/paperinfo/tpci/index.htmlBeefi schrieb:
oder 3D - Grafikkarten sind nunmal keine OOP Prozessoren
Das verstehe ich nicht...würde mich aber interessieren wie es gemeint ist.
DirectX zb baut massiv auf OOP
was imgrunde wenig bringt weil das Ziel ja der Bildschirm ist
und so ein Bildaufbau nunmal 100 % prozedural ist..
..optimiert der Compiler da nicht penibelst alles "weg"
hat man Bloat..
..verschränkt man nun 3D klassen mit anderen Klassen
sodas der Compiler keine Chance mehr hat zu optimieren
dann bremst der Bloat die maximale Performance aus..
-
Beefi schrieb:
Ah jetzt bist du mir zuvor gekommen. Also ich hab alle Infos selbst herausgefunden
Also es ist definitiv so, dass VS für Windows 8 NUR für die Metro-Apps ist. Für die gewöhnlichen Desktop Anwendungen (auch bei Windows
braucht man die Desktop Version.
Quelle: http://www.kwaschny.net/blog/1781/Difference-between-Visual-Studio-2012-Windows-8-and-Windows-Desktop
(Und unter anderem noch durch andere Funde bestätigt)Gut zu wissen.
Beefi schrieb:
Beefi schrieb:
- Die einzige Einschränkung an der Express Version (nur auf NET-Programmierung betrachtet) die einen etwas stören könnte, ist, dass man nur 32-Bit kompilieren kann.Das ist falsch.
Dass man nur 32-Bit kompilieren kann, oder dass es keine gravierende Einschränkung gibt, die man jetzt nicht unbedingt braucht.
Dass man nur 32-Bit kompilieren kann.
Beefi schrieb:
Was würdest du an der Express denn vermissen?
Beefi schrieb:
Da wir für unsere Schulungen per MSDNAA/Dreamspark alle Microsoft Produkte kostenlos bekommen (mit Einschränkung von nicht-kommerzieller Nutzung), ist natürlich ein Reiz zur Professional, Premium oder Ultimate Version da (auch wenn man es nicht wirklich braucht). Du würdest mir bestimmt zustimmen, dass es kontraproduktiv wäre, wenn ich diese Produkte zum wiedereinfinden und einlernen nutze, wenn ich letztendlich bei Express landen will. Oder?
VS geht bei über 600 EUR erst los...für ein C#-Windows-Hobby möchte ich das nicht unbedingt, wenn eigentlich C/C++ und Assembler beruflich wirklich wichtig für mich ist.
Deswegen wollte ich diesen C++ Zwang nutzen und noch ein ideales GUI Toolkit dazu lernen...deshalb eigentlich der Thread
Aber von C++/CLI (womit ich nur geringste Praxiserfahrung habe), höre ich immer nur Horrorgeschichten...C# hingegen flutscht sehr gut.
Und es ist eigentlich auch ein sehr gutes Argument, dass man bei der Betriebssystemeigenenen Lösung bleiben sollte. Ich hab ja selbst meine Erfahrung damit früher gemacht. Ich kenne Qt aber zu wenig um darüber urteilen zu können.Die letzte Express Edition die ich selbst benutzt hab war 2008. Es handelt sich in jedem Fall einfach um eine abgespeckte Variante der großen Versionen. Wenn du im Moment Zugang zu einer besseren Version hast, verwend sie ruhig. Es hängt natürlich davon ab, was man macht, aber die Express Edition ist auf jeden Fall gut genug für den Hobbybereich und in vielen Fällen wohl auch den semiprofessionellen und professionellen Einsatz. Ich vermute, dass du den Unterschied gar nicht bemerken würdest. Was ich persönlich immer vermisst hab, war die Möglichkeit, Projekte in verschiedenen Sprachen in der selben Solution zu haben. Ich vermute, dass diese Einschränkung in 2012 verschwunden ist, habs aber nicht ausprobiert. Abgesehen davon, würde ich wohl am heftigsten den Graphics Debugger vermissen. Zumindest im Moment gibt es dafür aber auch noch PIX als externes Tool.
Die Horrorgeschichten von C++/CLI sind allesamt wahr und kommen daher, dass die meisten Leute, die diese Sprache benutzen, selbige nicht verstanden haben, versuchen, Dinge damit zu tun, für die die Sprache nicht gedacht und völlig ungeeignet ist (GUI Entwicklung z.B.), mangels Verständis natürlich am ersten kleinen Problem scheitern und es dann auf die Sprache schieben. Das Problem mit C++/CLI ist nicht die Sprache, sondern dass 99.999% aller Leute, die sie verwenden, sie nicht verwenden sollten...
Beefi schrieb:
und VB/C(++).. sind nunmal nicht .NET
sondern lediglich "eingeflossen"Was ist denn dann .NET?
C++/CLI, C#, VB,...das sind doch alles Programmiersprachen für das NET-Framework.VB und C++ haben mit .NET nichts zu tun. C++/CLI, C# und VB**.NET** sind Programmiersprachen für das .NET Framework. Da pV auch nach mehrfachem Hinweis offenbar noch nichtmal den kleinsten Versuch unternommen hat, seine völlig schwachsinnigen "Fakten" zu überprüfen, ist davon auszugehen, dass es sich um einen Troll handelt und ich schlage vor, ihn so lange zu ignorieren (EDIT: Insbesondere auch den Beitrag über mir), bis er mal was Sinnvolles schreibt. Auf keinen Fall lass dich von dem Zeug, das er bisher hier von sich gegeben hat, verwirren...
-
dot schrieb:
VB und C++ haben mit .NET nichts zu tun. C++/CLI, C# und VB**.NET** sind Programmiersprachen für das .NET Framework. Da pV auch nach mehrfachem Hinweis offenbar noch nichtmal den kleinsten Versuch unternommen hat, seine völlig schwachsinnigen "Fakten" zu überprüfen, ist davon auszugehen, dass es sich um einen Troll handelt und ich schlage vor, ihn so lange zu ignorieren (EDIT: Insbesondere auch den Beitrag über mir) bis er mal was Sinnvolles schreibt. Auf keinen Fall lass dich von dem Zeug, das er bisher hier von sich gegeben hat, verwirren...
Hab ja eingangs erwähnt das hier viele Interessen aufeinanderknallen
und gewisse Personen da sehr emotional werden können..
..schade das es dot erwischt hat, welcher sich in anderen Threads meistens bemühte sachlich zu bleibenAlles was ich schrieb ist per Recherche nachprüfbar,
ich denke dot s Wutausbruch spricht für sich..
-
Ich bin nicht wütend, sondern hab einfach nur weder Zeit noch Lust, zu jeder einzelner deiner Behauptungen eine Erklärung zu schreiben, wieso genau das Schwachsinn ist...
pV schrieb:
Alles was ich schrieb ist per Recherche nachprüfbar,
ich denke dot s Wutausbruch spricht für sich..Dann bitte ich ganz sachlich um Verweis auf ein paar Quellen.
-
dot schrieb:
Ich bin nicht wütend, sondern hab einfach nur weder Zeit noch Lust, zu jeder einzelne deiner Behauptungen eine Erklärung zu schreiben, wieso genau das Schwachsinn ist...
pV schrieb:
Alles was ich schrieb ist per Recherche nachprüfbar,
ich denke dot s Wutausbruch spricht für sich..Dann bitte ich ganz sachlich um Verweis auf ein paar Quellen.
Für aus dem Kontext gerissene quote s ?
Wer mal genauer
-
Z.B. für Aussagen wie dass jede DLL ein COM Objekt darstellt. Abgesehen davon, fällt mir beim nochmaligen Durchlesen deiner Beiträge gerade auf, dass wir es da mit derartigen Mengen an Schwachsinn zu tun haben, dass ich nichtmal weiß, wo ich anfangen sollte und der Großteil davon auch einfach nur aus irrelevantem Gelaber und unbelegbaren Behauptungen besteht, daher: Lassen wir das besser einfach, sieh das als meinen letzten Fisch an...
-
dot schrieb:
Z.B. für Aussagen wie dass jede DLL ein COM Objekt darstellt. Abgesehen davon, fällt mir beim nochmaligen Durchlesen deiner Beiträge gerade auf, dass wir es da mit derartigen Mengen an Schwachsinn zu tun haben, dass ich nichtmal weiß, wo ich anfangen sollte und der Großteil davon auch einfach nur aus irrelevantem Gelaber und unbelegbaren Behauptungen besteht, daher: Lassen wir das besser einfach, sieh das als meinen letzten Fisch an...
-
Hi,
also vielen Dank schon mal für die ganzen hilfreichen Antworten und die Unterstützung. Ich werd morgen nochmal genauer auf die letzten Beiträge eingehen...aber ich muss hier jetzt für heute unbedingt schluss machen
Gute Nacht allen
-
So hallo heute,
Dass man nur 32-Bit kompilieren kann.
Ok. Ich las nur von solch einer Einschränkung bei VS2010. Entweder hat sich was geändert, oder das hängt mit dieser CLI-Sache zusammen. Laut Microsoft, werden nämlich auch als 32-Bit Anwendungen erstellte Programme unter einem 64-Bit System als 64-Bit Programme ausgeführt. Das ist für mich zwar unverständlich wie das gehen soll, aber immerhin ist es ja noch kein Maschinencode.
Hier die Quelle: http://msdn.microsoft.com/de-de/library/vstudio/ms241064.aspx
Wahrscheinlich hab ich die Erklärung nur nicht verstanden.VB und C++ haben mit .NET nichts zu tun. C++/CLI, C# und VB.NET sind Programmiersprachen für das .NET Framework.
Ja ich meinte schon das VB.NET. Als ich von Visual Studio 6 sprach...hiermit habe ich früher viele Jahre ausschließlich VB6 programmiert. Als dann .NET kam, war VB.NET ja eine "komplett andere" Sprache und ich habe mich auch seitdem nicht mehr wirklich mit der Windows-Programmierung beschäftigt, da ich mich mehr auf Assembler/C und Mikrocontroller/Prozessor konzentrieren musste. Ich dachte nur, dass es mittlerweile normal ist, dass mit VB auch nur VB.NET gemeint ist...das alte ist ja komplett tot.
Nun gut. Das Thema ist eigentlich gelöst
Installiert wird heute noch VS2012 Express. So kann ich mich als Nebenhobby wieder der Windows-Programmierung widmen und in C# einarbeiten.
C++ mit GUI-Toolkit, welches sowohl auf Windows und Linux läuft (Mac egal) ist jedoch Pflicht. Ich muss hier Programme schreiben, welche Messwerte aus Maschinen, Controllern, usw auslesen bzw diese steuern. Zudem müssen aus den Daten Diagramme gezeichnet werden, welche abgespeichert bzw gedruckt werden können. Sonst brauch ich da eigentlich nichts...außer noch zugriff auf RS232 und USBWenn ich an Visual Basic 6 zurückdenke, würde mir sofort eine simple Lösung einfallen, das Diagramm einfach in einer PictureBox zu zeichnen
Ich denke also, dass jedes simple GUI Toolkit damit zurecht kommen würde.Also was die eigentliche Themafrage angeht...
Ich wollte, da ich von C++ eh abhängig bin, Qt lernen und als Nebeneffekt auch mal wieder Windows Programme schreiben können (kann man immer gut gebrauchen). Daher die Frage, ob Qt denn "zeitgemäß" bzw "Windows 8 gemäß" ist. Und was das ganze Microsoftzeug angeht (Windows RT, Windows 8, Windows Phone) ist die Microsoftlösung wohl die beste und Qt eher ungewiss.
Meine Meinung hat sich mittlerweile so gebildet:"Mit Qt kann man keine Windows-Programme schreiben, sondern Qt erstellt einem ein Programm, dass unter Windows lauffähig ist"Problem ist jetzt nur, dass sich Qt und VS Express anscheinend nicht wirklich miteinander verbinden lässt. So muss ich wohl zweigleisig fahren. Also .NET allgemein für Anwendungen (da hier Zielplattform eigentlich nur Win).
Und irgendeine IDE + GUI Lösung für diese simplen Aufgaben (wie oben erklärt), welche als Zielplattform Linux haben. Dafür würde ich mich dann aber nicht extra in Qt einlernen und lieber auf FLTK greifen.FLTK würde sich auch prima in VS "integrieren" lassen. Der GUI Builder dazu (FLUID) erstellt aus der Zeichnung einfach nur Code, den man in seinen Quelltext reinkopieren muss. So kann man sagen, dass der FLTK GUI Builder mit jeder IDE-Lösung nutzbar ist. Würde ich hier jedoch auf VS setzen, sehe ich es sehr kompliziert, das ganze auf Linux zu bringen. Hier wird es wohl Code::Blocks und GNU GCC bleiben
Es sei denn, jemand hat ne bessere Idee
-
Beefi schrieb:
So hallo heute,
Dass man nur 32-Bit kompilieren kann.
Ok. Ich las nur von solch einer Einschränkung bei VS2010. Entweder hat sich was geändert, oder das hängt mit dieser CLI-Sache zusammen. Laut Microsoft, werden nämlich auch als 32-Bit Anwendungen erstellte Programme unter einem 64-Bit System als 64-Bit Programme ausgeführt. Das ist für mich zwar unverständlich wie das gehen soll, aber immerhin ist es ja noch kein Maschinencode.
Hier die Quelle: http://msdn.microsoft.com/de-de/library/vstudio/ms241064.aspx
Wahrscheinlich hab ich die Erklärung nur nicht verstanden.Reine .NET Anwendungen sind erstmal weder 32 noch 64 Bit, sondern werden in Zwischencode für eine virtuelle Maschine übersetzt. Zur Laufzeit wird dieser Zwischencode dann in tatsächlichen Maschinencode für die jeweilige Maschine, auf der das Programm gerade läuft, übersetzt. Und das kann dann x86 oder x64 oder ARM oder was sonst noch alles sein. Auf der von dir verlinkten Seite steht lediglich, dass Anwendungen die für .NET 1.0 und 1.1 (uralt) geschrieben wurden, immer als 32 Bit Anwendungen ausgeführt werden.
C++ auf der anderen Seite wird direkt in Maschinencode kompiliert. Hier war es früher mal so, dass die 64 Bit Compiler nicht von Haus aus dabei waren, aber man konnte sie immer über das Windows SDK nachinstallieren. Bei der 2012 Express Edition sind die 64 Bit Compiler afaik nun automatisch dabei.
Beefi schrieb:
Meine Meinung hat sich mittlerweile so gebildet:"Mit Qt kann man keine Windows-Programme schreiben, sondern Qt erstellt einem ein Programm, dass unter Windows lauffähig ist"
Gut zusammengefasst
Beefi schrieb:
Problem ist jetzt nur, dass sich Qt und VS Express anscheinend nicht wirklich miteinander verbinden lässt. So muss ich wohl zweigleisig fahren. Also .NET allgemein für Anwendungen (da hier Zielplattform eigentlich nur Win).
Und irgendeine IDE + GUI Lösung für diese simplen Aufgaben (wie oben erklärt), welche als Zielplattform Linux haben. Dafür würde ich mich dann aber nicht extra in Qt einlernen und lieber auf FLTK greifen.Das Problem dabei ist wohl, dass die Express Edition keine Add-ins unterstützt und der Qt Designer daher nicht direkt in Visual Studio integriert verfügbar ist. Die Libraries kannst du aber auf jeden Fall verwenden und den Designer gibts afaik auch als standalone Tool.
Wenn du komplexe GUIs auf Basis von Qt bauen willst, solltest du dir aber vielleicht mal QtCreator anschauen. Wenn deine C++ Anwendungen allerdings nur unter Linux laufen müssen, dann kannst du für deine separaten Windows Anwendungen ja einfach .NET verwenden...
-
Die Libraries kannst du aber auf jeden Fall verwenden und den Designer gibts afaik auch als standalone Tool.
Also was Qt Downloads betrifft, gucke ich immer hier: http://qt-project.org/downloads
Da gibt es jetzt nur die Libraries und den QtCreator. Den Designer sehe ich gar nicht, obwohl ich der Meinung bin, dass er hier auch immer früher angeboten wurdeWenn du komplexe GUIs auf Basis von Qt bauen willst, solltest du dir aber vielleicht mal QtCreator anschauen.
Ja, den QtCreator kenne ich...hatte ich unter Linux am Laufen. Ist echt nicht schlecht. Der QtCreator und das ganze Qt Paket wäre eigentlich das Toolkit für meine Zukunft gewesen. Also quasi ein Visual Studio für plattformübergreifende Dinge.
Ich wollte es eigentlich meiden, mich in so vielen Programmiersprachen und Toolkits einzuarbeiten...ich hab mit Visual Basic 6 schon Jahre gebraucht, bis ich da wirklich heftig was auf den Kasten hatte. Dafür konnte ich damals aber (aus meiner Sicht) jede Aufgabe lösen.Und jetzt hast du es tatsächlich geschafft, mich wieder aufs Visual Studio zurückzubringen
Wobei ich dir da schon recht geben muss. Wenn man mit C++ plattformübergreifend programmieren will, geht das zwar, aber zum Teil über harte Lösungen. Bei der "Microsoft-Lösung" ist alles sehr simpel und macht auch wirklich Spaß.
Softwareprogrammierung ist ja nur ein Hobby von mir...und ich bleib etz dabei: Windows + .NET Framework.
Was das Berufliche angeht, wäre dann Qt vielleicht zu gigantisch, es neben der Windows-Programmierung zu lernen. Hier sind wirklich nur die simpelsten GUIs von Nöten, hauptsache man kann es mit der Maus bedienen und auf jedenfall Graphen ausgeben und speichern/drucken.
Wobei ich wieder glaube, dass es auch hier mit Qt am leichtesten gehtKann es sein, dass es den Qt Designer seit Qt5 nicht mehr gibt? Und kannst du vielleicht nur mal ganz kurz zusammengefasst erläutern, wie das Zusammenspiel zwischen Designer und VS aussehen würde? Also was der Designer produziert und wie man das Formular aus einem unter VS geschriebenen Programm anspricht?
Ich denke kaum, dass der Designer nur Code erzeugt, den man mit Copy und Paste in VS einfügt (so wie bei FLTK)(was jedoch sehr simpel wäre)
PS: Achja wegen der "aufgeblasenen Größe von Visual Studio": Ich sagte ja immer, dass es so lange zum Laden braucht und so fett ist. Bei Express ist es absolut nicht der Fall...ein Kaltstart braucht 5 Sekunden und aus dem RAM nicht mal 1 Sek
Wenn man VS Ultimate damit vergleich, war es als würde man nochmal ein ganzes Betriebssystem starten
Mein Atmel Studio, welches auf Visual Studio 2010 (Shell?) aufsetz, braucht hingeben mindestens 30 Sekunden zum Starten.