Seit den letzten Tagen des April ist nun auch der Release Candidate für VS_2015 verfügbar.
http://www.visualstudio.com/en-us/news/vs2015-vs.aspx
Die Liste ist lang. Was sich für C++ Neues ergibt dagegen doch recht übersichtlich. 😉
Hier ein paar Punkte, die ein erster Test und Streifzug ergab:
- Man sollte in jedem Fall die angepasste Installation verwenden. Ansonsten wird der MFC Sourcecode nicht mit installiert (siehe auch Kommentar von Michael Külshammer)
- „Fast“ alle Projekte ließen sich fehlerfrei kompilieren. Es gab zwar einen Haufen neuer Warnungen aber, diese haben eher mit dem Stil des Programmierens zu tun. Speziell sind es C4456, C4457, C4458 (Declaration off… hides previous … declaration). Im Klartext. Ich verwende immer mal wieder eine Variable it oder i gerne, die auch im äußeren Scope vorhanden ist.
Für diese neuen Warnings gibt es allerdings bisher keine Dokumentation. - Und eben die typischen Fallen in denen man eben thirdparty Libs (z.B. OpenSSL) eben neu erzeugen muss.
- Leider benötige ich für ein spezielles Update Programm noch die MBCS Variante der MFC. Diese ist zwar über das Netz als Link bei MS vorhanden, führt aber zu einer 404 Sackgasse. (Dieses Programm benutzt extrem alten Code, bei denen noch niemand an char/wchar_t bzgl. der Windows API und anderes dachte und Neuschreiben hatte ich bisher vermieden. 🙂 )
- Nervig war eine „neue“ Compilermeldungen C1041, aber diese ist nirgendwo beschrieben (wie auch andere nicht). Online jedenfalls nicht. Ich bekam den Hinweis, dass eine PDB Datei nicht geschrieben werden kann und ich bitte die Option /FS verwenden soll. Die Ursache ist mir unklar, weil bei späteren Kompilierungsversuchen das Ganze durchlief.
- Etwas länger musste ich für den folgenden Fehler suchen:
(odbccp32.lib(dllload.obj) : error LNK2019: unresolved external symbol _vsnwprintf_s referenced in function StringCchPrintfW).
Hier scheint noch etwas mit dem SDK auch in der Release Version nicht zu passen. Auf connect.microsoft.com fand ich einen entsprechenden Eintrag um diesen Fehler zu umgehen. Scheinbar ist das neue „korrigierte“ SDK, dass in der Lösung versprochen wird im RC noch nicht enthalten. - Vieles in der UI hat sich geändert. So werden zum Beispiel die Breakpoint mit einem eigenen Kontexttoolbar angezeigt und benutzt man diesen dann werden die Einstellungen nicht in einem Dialog angepasst, sondern innerhalb des Sourcecode Fensters wird am unteren Rand ein Box für die Eigenschaften geöffnet. Das ist definitiv gewöhnungsbedürftig. Und nur mit der Maus zu bedienen.
- Im MFC Sourcecode findet sich nur eine neue Header-Datei afxlayout.h. In dieser Headerdatei findet sich die Deklaration für die Klasse CMFCDynamicLayout. Diese Klasse wird direkt in CWnd als Zeiger verwendet und erlaubt die Neupositionierung von Kindfenstern damit für alle Fenstertypen. D.h. nicht nur Dialoge. D.h. man kann in jedem MFC-Fenster EnableDynamicLayout ausführen und entsprechend die Kindfenster neu anordnen lasen wie man es selber definiert.
Die Implementierung schließt scheinbar die Nutzung des Ressourceneditors ein, denn die Einstellungen können aus dem Ressourcentyp RT_DIALOG_LAYOUT ausgelesen werden. In den Fenstereigenschaften eines Controls findet sich nun der Abschnitt Dynamic Layout in dem man Position und Größe in Prozent zur Gesamtänderung angeben kann. - Wer die Header genauer untersucht findet klitze kleine Änderungen Hier und Da wie z.B. die Unterstützung von runden Ecken bei Tooltipps.
- In der ATL konnte ich bisher keine Erweiterungen und gravierende Änderungen finden.
- Die meisten Änderungen im ATL und MFC sind Änderungen im Trace Code. Statt „%s“ wird nun konsequent „%Ts“ als Formatierungszeichen verwendet. Angekündigt war eine grundsätzliche Änderung bzgl. „Wide String Format Specifiers“ allerdings wurde diese bereits im April zurückgezogen (siehe hier).
- Vermisst habe ich einige CRT Source Dateien, die normalerweise im VC\CRT\SRC Order liegen. Der Ordner war in meiner Installation leer und enthielt nur weitere Ordner.
Mir war es auch nicht möglich beim Testen in den CRT Code zu steppen. Zumindest bei mir wurden keine passenden Source Dateien gefunden. - Mit den CRT-DLLs werde ich mich ab morgen mal befassen. Auch hier hat Michael Külshammer gerade eben einen Beitrag in meinem Blog geschrieben.
Summa summarum nur minimale Anpassungen in meinen Projekten für den Umstieg von VS-2013 auf VS-2015, darüber hinaus so gut wie keine (erkennbaren) Änderungen in der CRT/ALT und MFC. Was es an neuen Compiler Features gibt findet man in den Blogs ausführlicher beschrieben als ich das kann. Zudem halte ich mich nicht für den großen C++ Sprachen-und-Standard-Guru.
Hallo Maddin,
ich heisse aber Kü(h)lshammer, ohne „h“, ich meine das erste, aber egal.
Die MBCS-Erweiterung für Visual Studio 2015 RC soll nachgeliefert werden, man würde daran arbeiten, meinte das VC-Team.
Für das Aufsplitten der CRT gibt es hier einen Artikel, wenn man denn das Englisch so einigermassen drauf hat, ich tue mich damit etwas schwer, Eindeutschen wäre daher nicht verkehrt, Martin:
http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx
100%ig verstanden habe ich den Artikel noch nicht, was die genaue Absicht ist, vermutlich stabile Teile der CRT zu erzeugen, die nicht mehr angefasst werden und andere Teile, die je nach Betriebssystem angepasst werden. Allerdings müsste sich ja dann auch immer die vcredist_x86.exe mitändern, bzw. von Betriebssystem zu Betriebssystem andere DLL’s installiert werden.
Unter Windows-XP lief dann auch alles einwandfrei (vc140 für WindowsXP auswählen), allerdings erstmal nur in Unicode, bis es dann irgendwann die MBCS-Installation gibt.
Name soeben geändert. Sorry dafür!
Die Entwickler, die installationsfreie (bzw. auf einem USB-Stick laufende) Programme anbieten, sollten sich den Umstieg gut überlegen. Die CRT wurde in einen stabilen und einen compilerabhängigen Teil aufgesplittet. Der stabile (Universal CRT) ist nun Teil von Windows 10 und wird in Zukunft über Windows Update aktualisiert. Frühere Systeme erhalten die Universal CRT auch über Windows Update oder über die VCRedist mit den entsprechenden MSU-Paketen. Eine app-lolale Verwendung (also das Kopieren der Universal CRT in das Anwendungsverzeichnis) hat MS nicht vorgesehen. Das ist technisch auch schwierig, weil die Dll keine Versionskennung mehr im Namen hat. Damit hätte man die frühere DLL-Hölle zurück.
Der compilerabhängige Teil entspricht quasi dem bisher verwendeten System (ohne die Funktionen der Universal CRT). Diese Dlls lassen sich auch weiter app-lokal verwenden. Auf Windows 10 gibt es keine Schwierigkeiten, weil die Universal CRT auf jedem System installiert ist. Auf älteren Systemen muss der Anwender bei installationsfreien Programmen in Vorleistung gehen und die Universal CRT einmalig installieren. Wie sich das in der Praxis macht wird man sehen.
Wenn man Wert auf die Implementierung der neuen Compiler-Standards bzw. die neuen Optimierungen (beim Code und für die Kompilierungs-Zeit) legt und trotzdem nicht auf die app-lokale Nutzung verzichten möchte, dann kann man auch die neuen Compiler in Verbindung mit der alten Laufzeit verwenden. Man muss dafür zwar etwas tricksen, aber es funktioniert prinzipiell.
Neue Warnungen lassen sich übrigens mit der Compileroption /Wv:xxx unterdrücken, wobei xxx für die gewünschte Compilerversion steht. Mit /Wv:18 sollten alle nach VC 2013 neu eingeführten Warnungen unterdrückt werden.
Vielen Dank für die ausführliche Erläuterung.
In der Praxis hatte ich aber bisher keinerlei Probleme, meine Exe lokal zu halten.
Unter Windows 10 ist es bisher am einfachsten, ich benötige nur die vcruntime140.dll und die mfc140(u).dll und die Exe läuft einwandfrei. Alles weitere ist anscheinend schon in den hunderten von WinSxs-Verzeichnissen und und in Windows/System32 installiert. Ich hab sogar eine MFC42.dll gefunden :o)
Ausserdem, wenn ich eine vcredist_x86.exe auf irgendeinem Rechner laufenlasse, dann werden ja immer dieselben Dateien installiert. Wenn ich nun genau diese Dateien lokal in mein Verzeichnis packe, dann muss mein EXE doch laufen. Es sei denn, Microsoft hätte geändert, dass zuerst nach DLL’s im eigenen Verzeichnis gesucht wird.
Kann natürlich sein, dass sich später mal etwas in Windows 10 ändert, was meine obigen Aussagen zunichte macht.
Nehme ich nur den Compiler ohne die CRT’s, dann komme ich sicher nicht in den Genuss der Kontrollelemente-Verschiebung. Und hier mal gleich ein kleines Rechenbeispiel:
Ich habe 3 Knöpfe rechts unten im Dialog, wie muss ich die Verschiebung der Knöpfe im Ressource-Editor einstellen, damit sie beim Aufziehen des Dialogs immer am rechten unteren Dialog-Rand haften bleiben. Richtig !!!! Für alle Knöpfe die horizontale und vertikale Verschiebung auf 100 setzen. Nettes Feature haben sie da eingebaut. Was allerdings total blöd ist, dass man immer noch den Gripper rechts unten im Dialog selbst zeichnen muss. Das hätten sie doch wenigstens mal verbessern können.
Die Weitergabe der Universal CRT im Anwendungsverzeichnis ist nur möglich, wenn Microsoft es in den Lizenzbestimmungen zulässt. Danach schaut es im Moment aber nicht aus. Die verteilbaren Dateien befinden sich immer im VC\redist-Verzeichnis. Und da sind die Dlls nicht einzeln enthalten.
Die Verwendung der Universal CRT im Anwendungsverzeichnis würde nur funktionieren, solange sich die exportierten Funktionen nicht ändern. Sollten später einmal System-Dlls (oder sonstige in einen Prozess geladene Dlls von Drittparteien) gegen eine neue erweiterte Universal CRT gelinkt werden, dann läuft die Anwendung nicht mehr, weil Exporte von den geladenen Dlls nicht aufgelöst werden. Den derzeitigen Aussagen nach will MS das zwar vermeiden. Aber wir wissen ja alle, wie groß die strategische Halbwertzeit bei MS ist.
Das Update auf Windows 10 ist ja (angeblich) kostenlos, also müssen wir uns ja keine Sorgen mehr machen, da jeder updaten wird. 😉
Im wirklichen Leben gibt es aber immer noch mfc42-Programme, XP und vereinzelt noch Win2000-Server, auch wenn das nicht Microsofts Zielgruppe ist.
Ich bin schon sehr gespannt, wie das mit der rechnerabhängigen Komponente ist und wie sich das alles in ein Mergemodul packen lässt.
CMFCDynamicLayout klingt für mich jetzt nicht so wirklich spannend da ich seit Jahren die GUILayoutLib benutze und MS damit einfach zu spät kommt.
Die anderen Neuerungen interessieren mich da schon mehr.
@Sven: Ich habe kaum Fremdbibliotheken, und wenn, dann compiliere ich die selber :o), ausserdem liefern wir unsere Software nicht weltweit aus.
@Andreas: GUILayoutLib benutze ich auch, aber gleich beim Designen der Dialogbox die Kontrollelemente richtig setzen ist schon besser, man kann ja den Dialog sofort anzeigen lassen im Ressource-Editor und direkt ausprobieren, wie sich die Controls bewegen.
Das beste passierte heute, ich habe die VS2015 RC Community Edition installiert, die soll ja kostenlos sein, jedenfalls lese ich nirgendwo etwas anderes, und heute kam beim Starten von Visual Studio folgende Meldung: „Achtung, Ihre Testlizenz ist in 6 Tagen abgelaufen“, häh, nicht verstanden, ich dachte, die Version ist kostenlos. Na gut, bevor die Lizenz abläuft, dachte ich mir, logge ich mich mal bei Microsoft ein, danach erhöhte sich die Laufzeit der Lizenz auf 177 Tage, ganz toll, und was ist danach ? Ist das jetzt ein Bug oder ein Feature ?
Das mit der Lizenz-Nachfrage scheint zumindest für MSDN-Abonnenten ein Bug zu sein:
https://connect.microsoft.com/VisualStudio/feedback/details/1301736/license-problem-rc-license-shows-expiration-in-15-days
Lol :o)
@Michael: Es geht nicht um Fremdbibliotheken sondern um Dlls, die in den Adressraum der Anwendung geladen werden. Ich denke da insbesondere an Shell-Erweiterungen (z.B. für das Kontextmenü), die ja auch im normalen ‚Datei öffnen‘-Dialog automatisch zum Einsatz kommen.
Zur Community-Edition: Ich vermute mal, dass diese regelmäßig reaktiviert werden muss. So ist es seit VS 2013 auch bei der MSDN-Version, wenn man diese mit seinem MSDN-Konto verwendet (und nicht mit einem Aktivierungsschlüssel).
@Sven: Wenn man sehr systemnah arbeitet, so wie Du, dann hat man natürlich jede Menge Probleme mehr, das verstehe ich schon. Wenn ich z.B. Dateien über die Shell kopiere oder ähnliches. Das Schreiben von portablen Apps hat MS dadurch komplett verhindert, deswegen auch der Aufschrei im VCBlog, aber ich glaube nicht, dass MS da noch was ändern wird, MFC ist legacy Code und an hinterster Stelle. Plattformübergreifende Programmierung auf iOS und Android ist gefragt.
Aber wo siehst Du Probleme, eine portable Installation der UniversalCRT ist nur in WinXP, Win7, Win8 erforderlich, bei einer Installation auf Win10 installiere ich nur die MFC-DLL’s und die vcruntime.dll. Für Dich ist das ab jetzt nicht mehr machbar, eine portable Programmversion anzubieten, es sei denn, Du bleibst bei VS2013. Aber bei mir auf hausinternen Arbeitsplätzen ist das schon machbar.
MSDN ist in unserem Hause nur einmal verfügbar und hat unser MVP, weil der mit dem MS SQL-Server rummacht, ich habe die Professional-Version immer gekauft, wir sind halt ein kleiner Betrieb.
Das mit der Lizenzmeldung scheint ein Bug zu sein, ich bekam diese Antwort von MS Connect:
„Hi and thanks for your feedback!
This is a known issue that has been corrected. If you login to Visual Studio this should remove the expiration message and extend the expiration out to just after our release date.
Please try this and let us know if this corrects the issue.
Thanks and apologies!“
Kleine Betriebe bis zu 5 Programmierern dürfen ja ab jetzt die Express Edition oder wie sie jetzt heisst, Community Edition, die kostenlos ist, benutzen. Das zusätzliche MSDN-Abo ist zwar schön, aber auch teuer, und ich habe in der Vergangenheit kaum vermisst, dass ich es nicht habe, ausser zu VS6-Zeiten, heute kriegt man ja alle Infos bequem übers Internet.
@Michael: Probleme bei der nötigen Installation der Universal CRT gibt es mit Rechnern, auf denen man als Nutzer keine Adminrechte hat. Dazu zählen z.B. öffentliche Rechner im Internet-Cafe oder auch Firmenrechner, bei denen aufgrund eingeschränkter Rechte nur eine portable Nutzung möglich ist. Und wenn die Universal CRT nicht bereits installiert ist und ich sie auch nicht installieren kann, dann läuft meine Anwendung nicht mehr vom USB-Stick.
Es wird sich zeigen, wie schnell sich die Universal CRT auf älteren Windows-Systemen verbreitet. Vielleicht bewegt sich MS ja hier auch noch etwas. Glaube es zwar nicht, aber Hoffnung kann man immer haben (wenn ich an das Nachreichen der XP-Unterstützung in VS2012 denke).
Für mich sind die Neuerungen von VS2015 auch nicht weltbewegend. Die von mir gemeldeten HiDPI-Probleme mit der Quellcodeverwaltung in VS2013 wurden leider als nicht so wichtig eingestuft und in VS2015 auch nicht behoben. So fällt es mir im Moment auch nicht so schwer, bei VS2013 zu bleiben.
Da wird sich kaum was dran ändern, weil MS gerne alle Geräte unterstützen möchte von Phone, Tablet bis PC. Daher kann man Universal Apps für den MS Store schreiben, mit einer Codebasis, die dann auf allen Geräten laufen sollen, unter anderem kann man die auch mit VC schreiben. Obwohl die meisten Apps mit C# geschrieben sind. MS will das Schreiben von Apps voranbringen, mit 1/4 der Anzahl von Apps gegenüber Android und iOS muss sich MS halt was einfallen lassen. Ob das Konzept aufgeht wird man sehen. Daher vermutlich die UniversalCRT für ARM-Prozessoren usw.
Ach ja, schon wieder vergessen, die vcredist…exe kann man ja nur mit Admin-Rechten installieren.
Wer verwendet Lambdas ??
Ein MVP hat mal gesagt: „Was hat man eigentlich früher all die Jahre ohne Lambdas gemacht ?“ Für den anspruchsvollen Informatiker sind Lambdas was ganz tolles. Ausserdem hat MS ziemliche Probleme, die neuen C++-Standards in ihren Compiler und Debugger reinzukriegen.
Erstmal abwarten 🙂
Gibts noch irgendwo Internet-Cafes ? Hotspots soll man ja auch nicht nehmen wegen Sicherheit usw., schöne unsichere Welt nach Snowden, NSA und Co.
Achtung auch bei der Verwendung der C-Runtime und MFC merge modules (falls ein msi installer damit erstellt wird):
* die merge modules installieren zwar die meisten dlls, aber nicht die Windows-Komponenten davon! Zumindest nicht unter Vista bis Win8.1 (Win10 hat diese bereits installiert, nur unter XP werden diese von den merge modules mit installiert). D.h.: sogar wenn die merge modules verwendet werden kriegt man Fehlermeldungen beim Programmstart dass dlls fehlen!
* die merge modules für x64 sind zudem korrupt: die dlls werden in den SYSWOW64 Ordner kopiert statt in den System32 Ordner: https://connect.microsoft.com/VisualStudio/feedback/details/1639267/c-runtime-and-mfc-merge-modules-for-x64-are-broken-install-to-syswow64-instead-of-system32
Weitere Probleme:
Wenn die C-Runtime statisch gelinkt wird kann es assert() im Debugmodus geben, da new/delete zur jeweiligen dll gelinkt wird, und im Debug-Modus ein assert auftritt wenn new nicht in derselben dll ausgeführt wird wie das delete. Dies kann auch auftreten wenn new/delete von derselben dll ausgeführt wird, aber ein Objekt erstellt/zerstört wird welches in einer anderen dll zuhause ist! Wo genau dann new/delete ausgeführt wird erscheint mir zur Zeit noch nicht genau definiert: habe noch nicht herausgefunden wie ich das kontrollieren kann.
Ein weiteres Problem sind FILE* handles (erstellt mit fopen) beim statisch linken: diese können nur noch in derselben dll verwendet werden, nicht mehr über dlll-Grenzen hinweg (auch wenn alle dllls mit derselben runtime gelinkt sind). Hier gibts auch im Release-Mode eine Exception.
Danke für Deinen Beitrag!
Das die Merge Module defekt (falsch gebaut) sind ist ein Ding….
Das new/delete und FILE* Problem war doch bisher genau so. statisch/DLL durfte man nicht mischen statisch/statisch genauso wenig. Mischen heißt hier: In einem Modul belegen (fopen/new/malloc) und im anderen freigeben (fclose,delete/free).
Ganz verstehe ich nicht was sich da geändert haben soll.
Da hast du Recht. Hab das Problem mit new/delete und den FILE* Handles bisher nicht bemerkt, weil der VS2015-Compiler viel mehr Code jetzt Inline optimiert: bei mir wurde plötzlich der new Konstruktor inline kompiliert, aber der Destruktor mit delete nicht (der Destruktor ist ein bisschen grösser, hat mehr Code drin). Deswegen gibts jetzt bei mir die Probleme: new wird in dll1 ausgeführt (inline in dll1), aber delete in dll2 (aufgerufen auch von dll1).
Könntest Du auch mal als einen Artikel in Deinem Blog veröffentlichen:
VC2015 Kompilate können jetzt auch auf Win7 etc. verwendet werden:
http://www.dotnetpro.de/dotnetpronews6075.aspx
Habe ich nicht ausprobiert, aber hört sich so an, als gehören die Probleme mit der Universal CRT ab jetzt der Vergangenheit angehören ?! Habs nur gerade im Newsletter gelesen.