Schlagwort: COMSPEC

Aufstellung aller Änderungen an der MFC durch VS-2010 SP1

Ich habe mir mal die Mühe gemacht alle Änderungenan der MFC, die im VS-2010 SP1 enthalten sind, hier im Detail aufzuführen.

Viele Änderungen sind es nicht, wie man schnell sieht. Ich empfehle als weitere Quelle für Infos über den SP1 die bekannten Blogs des MS-C++ Teams und die KB.
http://blogs.msdn.com/b/vcblog/archive/2011/03/10/10139062.aspx
http://support.microsoft.com/kb/983509

Neue Samples finden sich nach dem SP1 Setup auf der Festplatte im folgenden Ordner:
C:\Program Files\Microsoft Visual Studio 10.0\Samples\1033\VC2010SP1Samples.zip

Für entsprechende bekannte Fixes habe den Text aus den Blogs übernommen. Alle anderen Änderungen habe ich durch einen Vergleich des Sourcecode mit WinMerge ermittelt. Codeänderungendie ich nicht direkt einem Fehler zuordnen konnte habe ich mit dem Prefix Change, markiert und natürlich die neuen Features entsprechend.

In einem späteren Artikel werde ich mich noch die Änderungenan CRT und STL genauer unter die Lupe nehmen.

Neues Feature: Direct2D Unterstützung (dokumentiert)

Direct2D, a hardware-accelerated, immediate-mode, 2-D graphics API that provides high performance and high-quality rendering for 2-D geometry, bitmaps, and text. For more information, visit the following Microsoft website: Direct2D.
http://msdn.microsoft.com/en-us/library/dd370990.aspx
http://msdn.microsoft.com/en-us/library/gg482719.aspx

Geänderte Dateien:

  • afx.h, afxglobals.h, afxrendertarget.h, afxwin.h
  • afxglobals.cpp, afxrendertarget.cpp, appui3.cpp, wincore.cpp

Anmerkung: Die Verwendung von Direct2D führt dazu, dass CoInitialize ausgeführt wird.

Neues Feature: Windows Animation Manager Unterstützung (dokumentiert)

Windows Animation Manager, which enables rich animation of user interface elements. For more information, visit the following Microsoft website: Windows Animation Manager.
http://msdn.microsoft.com/en-us/library/gg482719.aspx

Geänderte Dateien:

  • afxanimationcontroller.h, afxanimationhelper.h, afxwin.h
  • afxanimationcontroller.cpp

Bugfix: Korrektur eines Fehlers in den RDX Kompontenten (dokumentiert)

In the CDatabase/Crecordset MFC, the „DoFieldExchange“ variable does not work correctly in Visual Studio 2010.
http://connect.microsoft.com/VisualStudio/feedback/details/574974

Geänderte Dateien:

  • dbrfx.cpp

Bugfix:  Umgang mit SPI_GETNONCLIENTMETRICS in unterschiedlichen Windows Versionen (nicht dokumentiert)

Der interne Umgang mit unterschiedlichen Windows Versionen und SPI_GETNONCLIENTMETRICS wurde gefixed.

Geänderte Dateien:

  • afxglobals.cpp, afxribbonbar.cpp, afxvisualmanageroffice2007.cpp, afxvisualmanagerwindows7.cpp

Change: Cleanup der MFCNext Klassen (nicht dokumentiert)

Das Cleanup für die neuen MFC-Next Klassen wurde geändert.

Geänderte Dateien:

  • afxcontrolbarutil.h
  • afxglobals.cpp, afxwinappex.cpp, ctlmodul.cpp

Bugfix: Fehler bei Anzeige in CFormView Klassen (nicht dokumentiert)

VC-2010 MFC CFormViewzeichnet Buttons beim Rollenfalsch, es erscheinen schwarze Blöcke
http://blog.m-ri.de/index.php/2010/08/28/bug-vc-2010-cformview-zeichnet-buttons-beim-rollen-falsch-es-erscheinen-schwarze-bloecke/

Geänderte Dateien:

  • afxext.h
  • viewform.cpp

Bugfix: CImageList::DrawIndirect wurde korrigiert (nicht dokumentiert)

CImageList::DrawIndirect funktioniert nicht korrekt weil cbSize nicht initialisiert wurde
http://blog.m-ri.de/index.php/2010/07/21/bug-in-der-mfc-von-vc-2010-in-cimagelistdrawindirect/

Geänderte Dateien:

  • winctrl7.cpp

Change: Änderung des Suchalgorithmus für MFC Satellite DLLs (nicht dokumentiert)

Das Handling des Suchalgorithmus für die MFC Resource DLLs wurde geändert

Geänderte Dateien:

  • appcore.cpp, dllinit.cpp

 

PS:
Erstaunlich, dass zwei der Bugs, die ich zur MFC gemeldet habe auch direkt in diesem SP1 gefixed wurden. Das ist eine Quote, die ich in den letzten 12 Jahren bei einem SP noch nie hatte 🙂

Nachtrag und Ergänzungen am 18.03.2011
durch Sven von http://www.speedproject.de

Infos zum Laden der dwmapi.dll

Die Datei dwmapi.dll wird nun explizit aus dem Systemverzeichnis geladen.

Geänderte Dateien:

  • afxglobals.cpp

Infos zum Suchalgorithmus der MFC DLLs

Die Änderung des Suchalgorithmus für die zusätzlichen Sprachressourcen ist ebenfalls eine Schutzmaßname gegen das ‘Binary Planting’. Die Dlls werden jetzt nur noch aus dem Verzeichnis geladen, in dem sich die MFC-Dll befindet.

Infos zu dem geänderten Clennup der MFCNext Klassen

Der Grund für die Änderung beim Aufräumen ist wohl ein mögliches Speicherleck beim Beenden:
http://connect.microsoft.com/VisualStudio/feedback/details/577870/cmfcbutton-causes-memory-leak

Danke Sven!

Abgespecktes 4NT als TCC/LE von JP-Software als Freeware

Ich bin seit Jahren ein begeisterter Fan von 4NT (kennengelernt habe ich es noch als 4DOS unter DOS 4.0).
Was man so alles vermisst wenn man mal mit CMD.EXE arbeitet merke ich immer sofort, wenn ich ein DIR oder COPY ausführe und die komplexen Ranges, die 4NT bietet , sofort vermisse.
Ganz zu schweigen von netten Befehlen wie LIST, SELECT und anderem.

Auf den großen Bruder Take Command habe ich bisher immer verzichtet.
Ich verwende 4NT gerade auch da, wo ich komplexe Batchfiles für den gesamten Weg vom Build bis zum Setup benötige. All‘ das Kopieren von Dateien und Tools anwerfen, die dann irgendwann ein fertiges SETUP Paket erzeugen. Es ist einfach unschlagbar von den internen Funktionen, die hier geboten werden.

Jetzt hat mich JP-Software überrascht:

  1. Negativ: 4NT als Produkt alleine gibt es nicht mehr. Man kann den gesamten Funktionsumfang nur noch als Take Command erhalten.
  2. Positiv: Es gibt 4NT in etwas abgespeckter Form nun als TCC/LE (Take Command Console LE) kostenlos ❗

Soweit ich das sehe fehlt nur der Batch-Debugger und der Batch-Compiler, die ich sowieso kaum nutze, sonst sind alle meine gliebten Befehlszeilenfunktionen vorhanden.
In den internen Funktionen wird man evtl. die Datums- und Zeitfunktionen vermissen, die komplett herausgenommen wurden. Gleichfalls wie einige andere Funktionen.
Selbst mit den eingeschränkten Funktionen: TCC/LE ist ein Muss ❗

Download hier: http://www.jpsoft.com/tccledes.htm

Vista: Wie man den Kontextmenübefehl „Eingabeaufforderung hier öffnen“ auf die Powershell umbiegen kann

Torsten Schröder hat mir einen netten Kommentar in meinem letzten Blog-Artikel Vista: Wie man den Kontextmenübefehl “Eingabeaufforderung hier öffnen” umbiegen kann gegeben. Er meinte (Zitat):
„noch einen Tick besser fänd ich es, wenn man es Richtung Powershell umbiegt!“

Nun das gefällt mir auch und es ist auch nicht schwer. Mit dem folgenden kleinen Hack in der Registry kann man auch diesen erweiterten Kontextmenübefehl auch die Powershell umbiegen.

Einfach in der Registry unter HKEY_CLASSES_ROOT\Directory\shell\cmd\command
den Eintrag: cmd.exe /s /k pushd „%V“
z.B. in „C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe“ -noexit -command „set-location ‚%V'“ tauschen.

Damit lässt sich nun auch für mich das erweiterte Kontextmenü unter Vista perfekt nutzen:

  • 4NT integriert sich mit eigenen Kontextmenü-Befehlen.
  • und die Powershell ist nun über das erweiterte Kontextmenü des Vista-Explorers durch das Drücken der Umschalt-Taste extrem einfach zu erreichen.

Anmerkung: Wer den Faden verloren hat, alles beginnt mit diesem Tipp:
Zusätzliche Befehle im Explorer-Kontextmenü von Vista  😉

Vista: Wie man den Kontextmenübefehl „Eingabeaufforderung hier öffnen“ umbiegen kann

In meinem Artikel Zusätzliche Befehle im Explorer-Kontextmenü von Vista habe ich ja erwähnt, dass der Menüpunkt Eingabeaufforderung hier öffnen immer CMD.EXE verwendet und nicht den Befehlszeileninterpreter, der durch COMSPEC definiert ist.
Aber mit einem kleinen Hack in der Registry kann man auch diesen Befehl auf den eigenen Befehlszeileninterpreter umbiegen.

Einfach in der Registry unter HKEY_CLASSES_ROOT\Directory\shell\cmd\command
den Eintrag: cmd.exe /s /k pushd „%V“
z.B. in „C:\Program Files\4NT\4NT.EXE“ /s /k pushd „%V“ tauschen.

Anmerkung: Da 4NT normalerweise auch seine eigenen Einträge in den Kontextmenüs des Explorers macht, kann man es natürlich auch als Vorteil ansehen, wenn man bei Bedarf den originalen Befehlszeileninterpreter starten kann. 🙂

Zusätzliche Befehle im Explorer-Kontextmenü von Vista

Gerade habe ich durch Zufall im Explorer von Windows Vista entdeckt, dass sich das Kontextmenü verändert, wenn man die Umschalttaste festhält. Es ist hierbei egal ob man dies mit der rechten Maustaste oder mit der Kontextmenütaste macht. Es erscheinen 3 zusätzliche Befehle, wenn man eine Datei selektiert hat:

  1. An Startmenü anheften
  2. Zur Schnellstartleiste hinzufügen
  3. Als Pfad kopieren

und 2 neue Befehle wenn man ein Verzeichnis ausgewählt hat:

  1. Eingabeaufforderung hier öffnen
  2. Als Pfad kopieren 

Die beiden ersten Befehle für Dateien kann man vergessen.

Ganz anders sieht das jedoch mit dem letzten Befehl Als Pfad kopieren aus.  Der ist überaus nützlich um den Pfad einer Datei, oder gar die Pfade mehrerer Dateien in die Zwischenablage zu kopieren.
Unter XP hatte ich dazu immer noch das uralte Windows 95 Powertoy SendToX verwendet, das es leider für spätere Windows Versionen nicht mehr gab. Eigentlich schade, aber nun verschmerzbar.

Auch der Befehl Eingabeaufforderung hier öffnen ist sehr nützlich. Denn mit diesem Befehl kann man direkt ein DOS-Fenster in einem bestimmten Verzeichnis öffnen. Dafür gibt es zwar auch Registry-Hacks, aber Vista liefert das inklusive.
Leider verwendet Vista hier immer CMD.EXE und nicht den Befehlszeileninterpreter, der in COMSPEC eingetragen ist. Ich verwende seit Jahren 4NT.EXE und deshalb ist bei mir auch 4NT.EXE in COMSPEC eingetragen. Aber das ist verschmerzbar, denn 4NT mach seine eigenen Einträge im Explorer Kontextmenü, wenn man dies wünscht.

PS: Entdeckt habe ich das ganze, weil ich wusste, dass man bei einem Word Dokument zusätzlich den Befehl Schreibgeschützt Öffnen angeboten bekommt, wenn man die Umschalttaste festhält und das Kontextmenü öffnet über die rechte Maustaste oder die Kontextmenütaste. Das funktioniert auch für Excel-Dateien. Vielleicht wusste das ja auch noch nicht jeder ❗

VS-Tipps & Tricks: Command-Prompt öffnen im Projektverzeichnis

Es ist oft genug sinnvoll direkt im Projektverzeichnis eine Eingabe-Konsole zu öffnen. Ich persönliche verwende 4NT von JP-Soft, damit lassen sich viele Sachen weitaus schneller erledigen als mit dem Explorer.

Um schnell eine Eingabefenster zu öffnen kann man sich ein eigenes Tool einrichten.

  • Man klickt auf Tools -> External Tools…
  • Add Schalter anklicken
  • Dem Tool einen Namen geben (z.B. 4NT im Projektverzeichnis)
  • Als Command gibt man %COMSPEC% an
  • Als Argument /k „%VS80COMNTOOLS%\..\..\VC\vcvarsall.bat“ x86
    Durch diese Eingabe werden alle Environment Variablen gesetzt, die z.B. die Tools von VS2005 benötigen oder eben auch der Compiler. Dadurch kann man sofort alle Tools aus VS direkt von der Befehlszeile öffnen.
  • Bei Initial directory gibt man jetzt noch den Makro $(ProjectDir) an

Die entsprechenden Makros und Environment Variablen garantieren, dass die entsprechenden Batchfiles und auch der korrekte Befehlszeileninterpreter gefunden wird. Bei mir eben 4NT und nicht CMD.EXE. Durch die Verwendung von %VS80COMNTOOLS% wird auch der entsprechende Batchfile gefunden, egal wie das Programmverzeichnis heißt.

Der Aufruf von vcvarsall.bat setzt PATH, INCLUDE und LIB Environment-Variablen. Damit kann man alle VS-Tools diekt aus der Befehlszeile nutzen.

Warum ich diese komplizierte Methode gewählt habe? Ich liebe einfach universelle Angaben die man auf jeden Rechner übernehmen kann, egal wo die entsprechenden Softwarekomponenten installiert sind.