VS-2008 – Seite 7 – Martins Blog

MFC Updates for Visual Studio 2008 and Beyond: MFCnext

Was ich hier schreibe ist an sich viel zu viel für einen einzigen Blog Artikel, deshalb behalte ich mir hier nur eine kurze Zusammenfassung vor. Kommentieren und diskutieren werde ich dies noch in den nächsten Wochen.

Was ❓
Heute in den C++ Sessions der TechEd 2007 in Barcelona wurde ein Geheimnis gelüftet. Das war uns MVPs schon etwas länger bekannt aber leider war es uns bis heute durch NDA (non-disclosure aggreement) untersagt davon zu berichten.
Microsoft wird der MFC einen neuen gewaltigen Schub geben und seit Jahren die ersten wirklich gravierenden Erweiterungen verpassen. Das Ganze wird unter dem Namen MFCnext laufen.

In diesem Bog will ich nur summarisch aufzählen was alles an Neuem kommen wird:

Office 2007 UI Stil. Ribbons und alles was dazu gehört
Tabbed MDI
Integration neuer Controls (Advanced button, Shell tree and list, Mask edit, Property list)
Erweiterter Applikations Assistent
Rückwärts kompatibel bis Windows 2000
Docking wie wir es von Visual Studio her kennen
Visual Styles (Skins)
Die Standard Template Library wird um TR1 erweitert (tr1::shared_ptr, tr1:: mem_fn, tr1:: bind, tr1::regex, tr1::tuple, tr1::array, unordered containers hash-based, tr1::type_traits)
Microsoft bekennt sich klar und offen zur weiteren Entwicklung und Unterstützung der nativen C++ Programmierung.
und vieles andere mehr…

Die MFC wird sich in Anzahl der Klassen und Größe verdoppeln.

Wann kommt das ❓
Das Ganze wird bereits im März 2008 nachgeliefert, in einem Update für VS-2008. Ein Release Kandidat (RC) wird bereits im Dezember 2007 zur Verfügung stehen. So die bisherige Planung.

Die MFC ist tot… lange lebe MFCnext 😀

Weitere Infos:
Auch in Deutschland bei dieser Veranstaltung werden die Vortargenden aus Barcelona zu sehen und hören sein:
München 15.11.2007: Visual C++ 2008 und danach, Ask the Experts

Noch mehr Infos gibt es auch in dem Blog von Jochen Kalmbach, der live aus Barcelona von der TechEd 2007 berichtet.

Neues für VC++ 2008 Express

Irgendwie habe ich es gar nicht mitbekommen, aber VC++ Express wird mit der 2008er Version endlich ein „brauchbareres“ Produkt auch für Win32-Entwicklung.

Es wird endlich entsprechende Wizards geben für Win32 Projekte wie, DLLs, statische Libraries etc.
Nur scheinbar scheint der Resource-Editor nicht den Weg in die Express Version gefunden. Auch die MFC+ATL wird nicht Bestandteil der Express Versionen.

Da es keinen RC Kandidat geben wird, befürchte ich, dass der Resource-Editor leider aus dem Produkt draußen bleiben wird. Schade!

Nachzulesen hier:
http://blogs.msdn.com/somasegar/archive/2007/08/11/what-s-new-with-visual-studio-2008-express-editions.aspx
http://blogs.msdn.com/nikolad/archive/2007/07/26/what-s-new-in-visual-c-2008-express-for-beta-2-release-of-visual-studio-2008.aspx

RTM für VS-2008 Orcas doch zum Ende des Jahres

Sorry für meinen etwas schnellen Blog-Eintrag:
http://blog.m-ri.de/index.php/2007/07/16/vs-2008orcas-kommt-jetzt-doch-erst-im-februar-2008/

Ich habe Launch und RTM (Release to Market) durcheinandergebracht. Sorry!

Wie es aussieht ist es doch schon Ende des Jahres soweit:

http://blogs.msdn.com/dseven/archive/2007/07/10/windows-server-2008-visual-studio-2008-and-microsoft-sql-server-2008-joint-launch-announced.aspx

„While the launch events are scheduled to kick off on February 27, 2008, Visual Studio 2008 will be released before the end of the year.“

http://blogs.msdn.com/somasegar/archive/2007/07/13/it-all-begins-february-27th.aspx

„While we will be launching our products together in February, we are still aiming to release Visual Studio 2008 and .NET FX 3.5 by the end of this year based on your feedbackso far.“

VS-2008/Orcas kommt jetzt doch erst im Februar 2008

KORREKTUR zu diesem Artikel hier
http://blog.m-ri.de/index.php/2007/07/17/rtm-fuer-vs-2008-orcas-doch-zum-ende-des-jahres/
Ich habe Launch und RTM durcheinander gebracht. Sorry!

„VS-2008/Orcas kommt jetzt doch erst im Februar 2008“ weiterlesen

Mein erster Codeproject Artikel…

Nun habe ich es endlich mal geschafft und meinen ersten kleinen Artikel auf Codeproject geschrieben:

http://www.codeproject.com/cpp/PrivateAssemblyProjects.asp

Er schließt sich nahtlos an über alles das was ich hier achon über die Manifest-Hölle geschrieben haben…

_MFC_NOFORCE_MANIFEST und _ATL_NOFORCE_MANIFEST

In meinem Blog habe ich bereits über Libraries und die Verwendug von _CRT_NOFORCE_MANIFEST geschrieben (siehe Link unten).

Wenn man nun eine Library erzeugt, die die MFC oder die ATL benutzt, sollte man sich auch noch der beiden Defines _MFC_NOFORCE_MANIFEST und _ATL_NOFORCE_MANIFEST bewusst sein. Diese beiden Defines verhindern, dass durch die Verwendung der ATL bzw. MFC Include-Dateien #pragma comment(linker,”/manifestdependency:..”) Statements erzeugt werden.

Werden diese Defines konsequent verwendet, dann hat der Benutzer der Library die volle Kontrolle welche CRT, MFC bzw. ATL Version angebunden wird.

Warum man sich mit diesen Defines beim erzeugen einer Library auseinenadersetzen sollte kann man in diesem Artikel nachlesen: Warum man seine Libraries mit _CRT_NOFORCE_MANIFEST erzeugen sollte!

❗ BTW: Durch diese Defines kann man allerdings nicht verhindern, dass überhaupt Manifest-Einträge erzeugt werden. Selbst wenn man sein Programm mit den entsprechenden Defines kompiliert. Die Objektdateien haben dann zwar keine Manifest-Einträge, aber spätestens in dem Moment, in dem man das Programm linkt werden aus der CRT, MFC bzw. ATL Libraries Objektdateien gezogen die wieder entsprechende #pragma comment(linker,”/manifestdependency:..”) Einträge haben. Entsprechend bekommt das Manifest Tool dann auch Futter. Dazu mehr in einem späteren Artikel 🙂

Orcas kommt ohne hauseigenes SDK, aber mit einem SDK ;-)

Die neue VC Version wird die SDK Dateien nicht mehr in den eigenen Include Verzeichnissen haben, die unterhalb des entsprechenden Visual Studio liegen..

Wer kennt nicht das Problem, dass man eine Funktion oder eine Konstante aus einem neuen SDK benötigt, aber eigentlich ja alle SDK Dateien in den Include Verzeichnissen des Compilers findet und dieses ist natürlich längst veraltet. Also SDK installieren. Include und Lib Verzeichnisse eintragen…

Damit ist jetzt Schluss. Mit dem neuen Visual Studio wird ein SDK installiert. Und dieses wird dann verwendet. Es gibt also kein „Grund-SDK“ mehr, dass mit dem Visual-Studio Dateien installiert ist, sondern höchstens noch eines, das zusammen mit dem Visual Studio installiert wird. Aber eben in einem separaten Verzeichnis-Baum.
In der Beta steckt das Vista-SDK, das auch mit zu Auslieferung kommen wird.

Wurde aber auch Zeit für diese Änderung!

MFC unter Orcas arbeitet nur mit WINVER>=0x0501, d.h. XP

Das kann hoffentlich nur ein Bug oder Vergesslichkeit sein.
Wenn man WINVER auf einen Wert <=0x0500, d.h. einschließlich Windows 2000 setzt, dann bekommt man einen gemeinen Fehler beim kompilieren, wenn man die afximpl.h verwendet:

…\src\mfc\afximpl.h(629) : error C2059: syntax error : ‚<L_TYPE_raw>‘

Die Zeile 629 der afximpl.h verwendet den Typ HRAWINPUT, diesen gibt es aber in den SDK-Headern erst ab Windows XP, also mit WINVER>=0x0501! Das kann ja wohl nicht sein. Orcas Programme sollen als unterstes Target Windows 2000 haben.

Andererseits ist das Problem hier hausgemacht, weil das Programm eben diese interne afximpl.h benutzt. Sie ist ja intern, obwohl deren Definitionen eher public sein sollten.

Windows XP wäre ja als niedrigstes Betriebssystem wirklich ein Hammer! 😮

Report hier https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=277982

Nun evtl. bekommt man es auch etwas einfacher hin. ein simpler

#define HRAWINPUT DWORD

tut es auch, wenn WINVER eben nur mit 0x0500 definiert ist.

Selbstgemachter Manifest-Ärger…

In dem C++.de Forum kam dieser Thread Sehr spezielles Problem – (DLL + Manifest) auf!

Man muss den Thread nicht ganz lesen, ich will hier eine kurze Übersicht geben, wie man ein Projekt verbiegen kann, dass es nur noch Ärger macht, den man nur schwer (oder nach langem Suchen) in den Griff bekommt.

Ursprüngliches Problem:
Es ging mal wieder darum eine EXE so zu schreiben, dass Sie nicht von einer VC-2005 Runtime Library Installation (CRT+MFC) abhängig ist. Es ging um ein spezielles Plugin (also eine DLL).

Die Empfehlung war, wie so oft bei Manifest Problemen:
Linke sowohl CRT als auch MFC statisch.

Begründung:
Die DLL benötigt keine weiteren DLLs oder Third Party Libs. Ist also mehr oder weniger standalone. Also warum noch zusätzliche Abhängigkeiten schaffen. Auch wenn dies etwas mehr Hauptspeicher kostet, wenn andere Applikationen die 8.0 Runtime-Libs auch gleichzeitig verwenden können.
Es erübrigt die Installation der VCRedist_x86.exe oder auch andere, komplexere Tricks wie die applikationslokale Installation der Runtime-Libs.

Folgeproblem:
Sowohl für die MFC als auch für die CRT wurde nun statisches Linken im Projekt eingestellt. Aber dennoch wurde weiterhin ein Manifest erzeugt, das die CRT anforderte.
Das erzeugte doch nun einiges Rätselraten bei mir. 😕
Auch die Projektdatei, die mir zugesandt wurde brachte auf den ersten Blick keinen Aufschluss über das Problem.
Weitere Prüfung mit DUMPBIN ergab, dass die Objekt Dateien alle mit einem Manifest Eintrag kompiliert wurden, oder in anderen Worten, das im Sourcecode ein #pragma comment manifest Eintrag drin steht.

Lösung:
Einze kurze Recherche in der crtdefs.h ergab, dass die #pragma Einträge für die Manifeste nur erzeugt werden wenn, _DLL definiert wird. Die Doku sagt klar:

Das ist eine interne, vordefinierte Präprozessor Variable
Diese ist nur bei den Kompileroptionen /MD und /MDd definiert

Derjenige, der dieses Projekt erzeugt hat, hat auch die Präprozessor Variable _DLL vordefiniert. Das Resultat war natürlich, dass Manifest-Einträge erzeugt wurden und weiterhin die CRT-DLLs genutzt wurden.

❗ Merke: Pfusche nie mit internen Nachrichten, Präprozessor-Variablen rum, die einen nichts angehen. Oft genug sind schnelle Workarrounds die man mit so etwas erreicht ein Schuss ins eigene Knie. 🙂

Ach ja! Man hätte übrigens noch weiter Pfuschen können und _CRT_NOFORCE_MANIFEST definieren können ! Dann hätten wir den einen Pfusch mit einem anderen behoben!

Erste (durchaus positive) Kontakte mit Orcas Beta1 VPC

Ich habe mir mal die Orcas Beta 1 für VPC heruntergeladen und versuche gerade mal, ein paar meiner größeren Projekte damit zu kompilieren.

1. Erfahrung: Ich habe ein VC-2005 Projekt geöffnet um es zu konvertieren. Orcas stürzt ohne Fehlermeldung ab. Erst beim zweiten Versuch klappt es. Gleicher Effekt bei einem anderen Projekt. Scheint irgendwie an den bestehenden temporären Projektdateien zu liegen. Bugreport wurde gesendet. Dem muss ich nochmal nachgehen.

2. Erfahrung: Der Platform SDK Include-Pfad ist in den VS-Einstellungen nicht definiert.
Resultat: Die Datei msdaguid.h wurde nicht gefunden bei einem Programm, dass die ATL OLE-DB Client Templates verwendet. Scheint ein Known-Bug des verwendeten Vista SDKs zu sein. Also am Besten die entsprechenden Einträge konform wie in VS-2005 erzeugen. Man sollte auch gleich das BIN und LIB Verzeichnis kontrollieren. Sonst wundert man sich beim Linken und wenn andere SDK Tools – wie mc.exe – verwendet werden sollen.

3. Erfahrung: Ein Breaking Change für mich. CWnd::GetMenu war bisher nicht virtuell. Jetzt wurde diese Funktion in der neuen MFC 9.0 virtuell. Die Folge: Eine meiner Fensterklassen definierte selbst GetMenu mit HMENU als Returnwert. Ja so was soll man nicht machen, aber man kann es, solange die Funktion nicht virtuell ist. Das Projekt kompiliert nicht mehr.

4. Erfahrung: Ein mittelgroßes Projekt das von VC-2005 umgestellt wurde (ca. 400 Source und Header-Dateien) kompilierte ohne weiteren Fehler. Das macht doch Hoffnung 🙂

Download der Beta1 hier: Visual Studio Code Name „Orcas“ Downloads