_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 🙂

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.

Attributed ATL für OLE-DB-Consumer in VC-2005 (db_command)

Ich habe Attributed ATL für OLE-DB-Consumer sehr nett gefunden und in VC.NET 2002 gleich eingebaut. In VC-2003 war auch alles noch OK.

Jetzt rächt sich meine Inovationsfreude in VS-2005! 😥

  1. Der Syntax von VC-2003 nach VC-2005 hat sich geändert! Aller Parameter müssen jetzt als Strings übergeben werden.
    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=98753
  2. Der Parameter bulk_fetch in db_command wird nicht mehr verstanden. Egal ob man ihn als String oder als Integer angibt.
    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=275256

Mein Rat: Man sollte kein Attributed ATL, so schön es auch ist. Man sollte bei den Standard Templates bleiben. Ist etwas mehr Schreibaufwand, aber:

  1. Leichter zu Debuggen
  2. Kompatibel
  3. Leichter kompatibel zu machen. 😉

Anmerkung zum Schluss:
Aus Gerüchten und Diskussionen bei Microsoft habe ich gehört, dass kein weiteres großes Augenmerk auf Attributed ATL gelegt wird.

Anfänglich als großer Wurf gefeiert. Mit der Möglichkeit in Zukunft vielleicht selbst als Entwickler attributierbare Module erzeugen zu können, scheint es jetzt eher ein Auslaufmodell zu werden.
Es gab zu viele Probleme damit und hat sich in der Entwicklung als kryptisch und schwer zu Testen herausgestellt.