Wenn man mal schnell eine Foren Software braucht…

Für den internen Gebrauch und Austausch mit einem paar Freunden benötigte ich eine Foren Software.

Also ging ich auf die Suche nach „Forensoftware nicht kompliziert, leistungsfähig, funktional, schnell, kostenlos“!

Meine Wahl viel letzten Endes auf SMF (Simple Machines Forum).
Ich kann nur sagen, dass die Wahl äußerst gut, war. Einrichtung und kleine Anpassungen waren im Nu durchgeführt. Eine Shoutbox habe ich auch noch gefunden und nun läuft dieses kleine geschlossene Forum wie eine 1.

Die ein oder zwei Fragen, die auftauchten waren schnell mit dem Online Handbuch bei SMF geklärt, oder es gab die entsprechende Antwort im Support Forum bereits.

PS: Ja klar. PhpBB war natürlich auch im Blickfeld, aber irgendwie hat mich dieser Dinosaurier nicht angelockt.  SMF erschien mir einfacher, kleiner kompakter, moderner und vor allem pflegeleichter.

 

Visual Studio 2013 Update 2 RC ist nun verfügbar

Mit dem neuen SQL 2014 der gestern veröffentlicht wurde kamen auch ein RC für Visual Studio 2013 Update 2. Dabei ist das Update 1 erst ende Januar heraus gekommen.
Das Update 2 für den TFS 2013 ist bereits veröffentlicht worden.
Siehe:  http://blogs.msdn.com/b/bharry/archive/2014/04/02/tfs-2013-2-update-2-released.aspx

Besonders gespannt bin ich auf die Linker Enchantements, die mit Update 2 kommen.
http://blogs.msdn.com/b/vcblog/archive/2014/03/25/linker-enhancements-in-visual-studio-2013-update-2-ctp2.aspx

Die Geschwindigkeit mit der aktuell Updates und Releases veröffentlicht werden ist geradezu verstörend. Man kommt kaum dazu sich auf eine Entwicklungsumgebung festzulegen und da ist schon das nächste Update, dass mit neuen Features Funktionen und Fixes reizt. 🙁

PS: Die Veröffentlichung von MS-SQL 2014 erinnert mich schmerzhaft, dass es nur noch 5 Jahre Support für OLE-DB gibt. Das ist noch einen traurigen Smiley wert 🙁

Advanced Developers Conference zu native C++ in Münchem vom 29.-30.04

Wer das lange Wochenende zum 1. Mai auf ganz besondere Weise einleiten will, dem rate ich die ADC C++ Konferenz vom 29.-30.04.2014 in München zu besuchen.

Die Agenda enthält alt bekannte Themen, aber auch interessantes Neues. Nachdem mit C++x11, C++/RT wieder etwas Schwung in die Weiterentwicklung von C++ gekommen ist und auch die Geschwindigkeit in denen neue Compiler und Library Features veröffentlich werden beschleunigen, lohnt sich ein Blick über den Tellerrand.
Oft genug finden wir als Entwickler nicht die Zeit uns neuem zu widmen, dass bereits verfügbar ist oder in nächster Zeit verfügbar wird.

Veranstalter ist die ppedv AG (hinter der Johannes Preishuber steht). Ich habe die Konferenzen der letzten Jahre, an denen ich teilgenommen habe, immer in guter Erinnerung. Sowohl in der Auswahl der Themen und Redner, als auch in der exzellenten Durchführung, mit immer sehr schon gewählten Konferenzorten und Hotels.
Insofern lohnt sich sicherlich ein Blick in die Agenda.
Und ganz gespannt bin ich persönlich auf die Abendveranstaltung am Mittwoch, denn hier wird auf den ADC-Konferenzen den Teilnehmern immer etwas wirklich außergewöhnliches geboten.

Da ich letztes Jahr aus privaten Gründen leider nicht teilnehmen konnte freue ich mich dieses Jahr wieder dabei sein zu können; ,alte Kontakte beleben zu können, neue Entwickler kennen zu lernen und Neues aus der C++ Welt zu hören.

ADC

VSOne in München vom 17.-18. Februar 2014

Am 17. und 18. Februar 2014 wird in München de VSone stattfinden. Die VSone ist eine Entwickler-Konferenz mit einem sehr weit gefächertem Spektrum, das reicht von der App-Entwicklung, über SQL-Server Themen, klassischen .NET Themen bis hin zu JQuery und Azure.

Veranstalter ist die ppedv AG (hinter der Johannes Preishuber steht). Ich habe die Konferenzen der letzten Jahre, an denen ich teilgenommen habe, immer in guter Erinnerung. Sowohl in der Auswahl der Themen und Redner, als auch in der exzellenten Durchführung, mit immer sehr schon gewählten Konferenzorten und Hotels.
Insofern lohnt sich sicherlich ein Blick.

Weitere Informationen und die Liste der geplanten Sessions und Redner findet sich hier.

VSone

 

Das Problem, wenn man Fehler richtig erkennt, richtig dokumentiert aber dann den gleichen Blödsinn wieder macht

… oder auch: Es gibt Tage, da könnte man sich in der Tischplatte verbeißen…

Wir haben vor ein paar Wochen einen sehr mystischen Fehler in unserer Software gefunden.
Das Problem war eine Funktion, die einen (const) Zeiger auf einen Datenblock bekam.
Die Funktion hat aber unter Umständen eine UI-Interaktion (Dialog) ausgelöst und die entsprechende offene Nachrichtenschleife hat es wiederum einen Hintergrundthread erlaubt (unter bestimmten Umständen) Nachrichten an den Mainthread zu senden, der wiederum die Anzeige aktualisierte und auch den Datenblock, der eben noch als Zeiger übergeben wurde, ungültig machte.

Die Funktion sah in etwa so aus:

bool CSomeClass::SomeAction(const S_FOO *pData)
{
...

pData war nun ungültig und wurde verändert, war aber immer noch gültiger Speicher in dem ein paar Ids aus einer Datenbank standen. Das Programm stürzte nicht ab. Tat aber aufgrund der falschen Ids auch nicht das, was es eigentlich sollte.

Der Code wurde dann wie folgt geändert und ein entsprechender Kommentar geschrieben:

bool CSomeClass::SomeAction(const S_FOO &data)
{
// We use a copy of the result object. There is a chance that the
// global result gets replaced while we are inside this routine and 
// the storage where our pointer points gets deleted and replaced 
// by a new result object.
...

Oha. Aber was passierte hier. Anstatt wirklich eine Kopie zu verwenden, wurde wieder nur ein Zeiger verwendet. Nur diesmal in Form einer Referenz.

Es wird nun niemanden wundern., dass mir die selbe Fehlebeschreibung wieder auf den Tisch flatterte. Im Debugger  wurden die selben Probleme festgestellt und ich musste dreimal auf die Code-Zeile schauen und den Kommentar dreimal lesen, bevor ich verstand was hier geändert wurde.

  • Fehler erkannt.
  • Fehler dokumentiert.
  • Fehler aber nicht gefixed.

So hätte es aussehen müssen:

bool CSomeClass::SomeAction(const S_FOO data)
{
...

PS: Ich oute mich mal. Der Trottel war ich…

Visual Studio 2013 ist nun verfügbar

Heute ist Visual Studio 2013 verfügbar gemacht worden.

Weitere Infos finden sich im VC++ Blog und in Somasegar’s Blog:
http://blogs.msdn.com/b/vcblog/archive/2013/10/17/visual-studio-2013-available-now.aspx
http://blogs.msdn.com/b/somasegar/archive/2013/10/17/visual-studio-2013-available-for-download.aspx

 

Mein 15. Award als deutscher MVP für Visual C++

Da denkt man: „Das war es dann wohl!“, aber dann kommt doch anders.

Pünktlich am 01. Oktober bekam ich eine Email mit dem folgenden Inhalt:

Sehr geehrte(r) Martin Richter,
herzlichen Glückwunsch! Wir freuen uns, Ihnen den Microsoft® MVP Award 2013 verleihen zu können! Diese Auszeichnung wird an herausragende, führende Mitglieder der technischen Communities verliehen, die ihre wertvollen praktischen Erfahrungen mit anderen Menschen teilen. Wir schätzen Ihren außerordentlich bedeutenden Beitrag in den technischen Communities zum Thema Visual C++ im vergangenen Jahr hoch ein.

Das ist nun mein 15. Award als MVP für C++.

Ich bleibe dabei: Alles hat seine Zeit (Prediger 3, 1-11) 😉

PS:
Kleiner Nachtrag. Ich war einer von fast 1.000 MVPs:
Nachzulesen hier http://blogs.msdn.com/b/mvpawardprogram/archive/2013/10/01/new-and-renewed-mvps-announced.aspx

Windows 7, PlaySound und die vermisste Prüfung auf Speicherlecks

Bei der Entwicklung von neuen Funktionen in einem Modul bekam ich irgendwann einen ASSERT. Diesen ASSERT hatte ich in einem Cache eingebaut. Der ASSERT sprang an, wenn bei Programmende der Cache nicht sauber aufgeräumt wurde. Also eigentlich in der Entwicklungsphase nichts ungewöhnliches. Irgendwo wurde also eine Funktion zum Aufräumen nicht aufgerufen.

Aber was mich in diesem Moment extrem stutzig machte, war, dass in der Debugausgabe meines VisualStudios keine Memory Leaks angezeigt wurden ❗ Das machte irritierte mich nun schon sehr. Erster Verdacht. Evtl. hat ja jemand die Leakprüfung für den Cache ausgeschaltet (siehe AfxEnableMemoryTracking). Aber eine kurze Prüfung ergab, dass dem nicht so ist.

Also den Test noch mal ausgeführt. Diesmal wieder der ASSERT und zusätzlich der Dump. „Oha“ dachte ich „Hier ist aber was richtig faul!“

Nachdem ich immer wieder andere Testszenarien verwendet habe, erschienen mal die Leaks und mal erschienen sie nicht. Und nach einiger Zeit kaum ich dahinter, dass immer wenn PlaySound in meiner Debug Version der Anwendung verwendet wurde, kein Leak-Check erfolgte. Wurde PlaySound nicht verwendet war alles gut und die Leaks wurden ausgegeben.

Jetzt ging es ans eingemachte. Schnell isolierte ich folgende DLLs die zusätzlich beim ersten PlaySound geladen wurden.

'xyz.exe': Loaded 'C:\Windows\SysWOW64\MMDevAPI.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\propsys.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\wdmaud.drv', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\ksuser.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\avrt.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\setupapi.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\cfgmgr32.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\devobj.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\AudioSes.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\msacm32.drv', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\msacm32.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\midimap.dll', Symbols loaded (source information stripped).

Und nach etwas weiter debuggen kam ich dahinter, dass der DllMain Code von setupapi.dll beim DETACH_PROCESS den Prozess sofort terminiert und nicht alle DLLs einen DETACH_PROCESS Aufruf erhalten. Aber der Code für die Leak-Detection der MFC liegt in der MFCx.DLL und wird durch eine statische Variable ausgelöst, die beim Entladen der MFCx.DLL dann zur Ausgabe der Speicherlecks führt. (Siehe PROCESS_LOCAL(_AFX_DEBUG_STATE, afxDebugState) und AfxDiagnosticInit).

Eine genauere Analyse des Stacktraces ergab folgendes Bild:

ntdll.dll!_ZwTerminateProcess@8()  + 0x5 bytes	
ntdll.dll!_RtlpWaitOnCriticalSection@8()  + 0x1d38f bytes	
ntdll.dll!_RtlEnterCriticalSection@4()  + 0x16a38 bytes	
setupapi.dll!_pSetupInitGlobalFlags@4()  + 0x1fc bytes	
setupapi.dll!_pSetupGetGlobalFlags@0()  + 0xe2 bytes	
setupapi.dll!_FlushWVTCache@0()  + 0x2f bytes	
setupapi.dll!_DestroyDeviceInfoSet@8()  + 0x3f bytes	
setupapi.dll!_SetupDiDestroyDeviceInfoList@4()  + 0x44 bytes	
MMDevAPI.dll!CDeviceEnumerator::FinalRelease()  + 0x78 bytes	
MMDevAPI.dll!ATL::CComObjectCached::~CComObjectCached()  + 0x3c bytes	
MMDevAPI.dll!ATL::CComObjectCached::`scalar deleting destructor'()  + 0xd bytes	
MMDevAPI.dll!ATL::CComObjectCached::Release()  + 0xf0c6 bytes	
MMDevAPI.dll!ATL::CComClassFactorySingleton::~CComClassFactorySingleton()  + 0x18 bytes	
MMDevAPI.dll!ATL::CComObjectNoLock<ATL::CComClassFactorySingleton >::`scalar deleting destructor'()  + 0x1a bytes	
MMDevAPI.dll!ATL::CComObjectNoLock<ATL::CComClassFactorySingleton >::Release()  + 0xe0e3 bytes	
MMDevAPI.dll!ATL::CAtlComModule::Term()  + 0x27 bytes	
MMDevAPI.dll!__CRT_INIT@12()  + 0x26e6 bytes	
MMDevAPI.dll!__CRT_INIT@12()  + 0x2588 bytes	
ntdll.dll!_LdrpCallInitRoutine@16()  + 0x14 bytes	
ntdll.dll!_LdrShutdownProcess@0()  + 0x141 bytes	
ntdll.dll!_RtlExitUserProcess@4()  + 0x74 bytes	
kernel32.dll!75eb7a0d() 	
msvcr100d.dll!__crtExitProcess(int status=0)  Line 709	C
msvcr100d.dll!doexit(int code=0, int quick=0, int retcaller=0)  Line 621 + 0x9 bytes	C
msvcr100d.dll!exit(int code=0)  Line 393 + 0xd bytes	C
xyz.exe!__tmainCRTStartup()  Line 568	C

Ursache war, dass MMDevAPI.DLL in seinem DllMain Code ausführt in der setupapi.dll, die aber bereits den DETACH_PROCESS abgearbeitet hat. Das grundsätzliche Problem wird hier in diesem Blog Artikel geschildert: http://blogs.msdn.com/b/oldnewthing/archive/2005/05/23/421024.aspx
Mit eigenen Worten: Die MMDevAPI.dll ruft Funktionen in einer DLL auf, die bereits alle Ihren Speicher und Ressourcen freigegeben hat. Und wie es hier im Code so aussieht, versucht die SetupAPI.DLL wieder Ressourcen zu akquirieren, die eben bereits schon freigegeben wurden, weil eine DLL sie erneut benutzt.

Die Folge ein „Crash“ in DllMain, die der Windows-Lader aber abfängt und sofort mit einer Terminierung des Prozesses ahndet. D.h. nun aber, dass nicht alle DLLs, die noch einen DllMain Aufruf mit DETACH_PROCESS erhalten müssten,  auch an die Reihe kommen.

Etwas weitere Recherche ergab, dass dieses Problem auch in den MSDN Foren bereits diskutiert wurde inkl. einer möglichen Lösung.
http://social.msdn.microsoft.com/Forums/vstudio/en-US/8cb1847d-3218-4610-9cb8-6905bd255ff5/no-dllprocessdetach-after-calling-playsound-on-windows-7-64bit

Die Lösung ist erstaunlich einfach: Wenn vor der Benutzung von PlaySound explizit die SetupAPI.DLL geladen wird, dann verläuft der Rest der Deinitialisierung vollkommen normal. SetupAPI.DLL wird nicht entladen, weil die DLL durch den LoadLibrary Aufruf die DLL im Speicher sperrt. MMDevAPI.DLL kann erfolgreich selbst aufräumen und der Code läuft nicht mehr ins Nirvana.

Hier handelt sich offensichtlich um einen Bug in Windows 7 (Windows 8 konnte ich dies bzgl. nicht testen).
Dieser Bug kann natürlich auch empfindlichere Probleme mit sich bringen, wenn Ressourcen betroffen sind, die nicht automatisch mit Prozessende freigegeben werden und wenn diese Ressourcen ausschließlich in der DllMain bei einem DETACH_PROCESS behandelt werden.

Änderungen für MFC + ATL in VS-2013

Im Microsoft C++ Team Blog kann nachgelesen werden was sich in ALT+MFC in VS-2013 tun wird:
http://blogs.msdn.com/b/vcblog/archive/2013/08/20/atl-and-mfc-changes-and-fixes-in-visual-studio-2013.aspx

Wer hätte es gedacht…, ja es gibt wieder etwas „Neues“, auch wenn es mehr oder weniger nur Bugfixes sind.

Besonders erwähnenswert ist der Wegfall des MBCS Supports in der MFC, siehe auch hier.
Das die ATL jetzt nur noch als statische Bibliothek mit sehr kleinem Footprint existiert ist nett. Warum eigentlich nicht gleich so?

Nachtrag und Korrektur durch den aufmerksamen Blog-Leser Sasche:

Wie auch im verlinkten Artikel beschrieben, fällt der MBCS Support in VS-2013 noch nicht weg, sondern ist erst mal nur “deprecated” (und die entsprechenden Libs nur noch als separater Download verfügbar). Erst in einer Folgeversion soll der Support für MBCS ganz wegfallen.

 

Microsoft veröffentlicht Update 3 für VS-2012 und zeitgleich einen Preview auf VS-2013

Das Update 3 für VisualStudio 2012 wurde gestern veröffentlicht.

http://support.microsoft.com/kb/2835600/en-us
http://blogs.msdn.com/b/vcblog/archive/2013/06/27/what-s-new-for-visual-c-developers-in-vs2013-preview.aspx
http://blogs.msdn.com/b/visualstudio/archive/2013/06/26/visual-studio-2013-preview-available-now.aspx
http://visualstudiomagazine.com/articles/2013/06/26/update-3-of-visual-studio-2012-released.aspx

Damit ist die Regression aus dem Update 2 endgültig behoben. Mit Update 1 konnte man wieder Programme bauen, die auch auf Windows XP laufen. Update 2 machte dies wieder zunichte.

Siehe auch:
http://connect.microsoft.com/VisualStudio/feedback/details/783137/visual-studio-2012-update-2-rtw-breaks-xp-targeting-with-c-when-statically-linking-mfc-and-atl
http://tedwvc.wordpress.com/2013/04/14/how-to-get-visual-c-2012-update-2-statically-linked-applications-to-run-on-windows-xp/
http://blogs.msdn.com/b/vcblog/archive/2013/05/07/fix-visual-studio-2012-update-2-breaks-windows-xp-targeting-with-atl-and-or-statically-linking-mfc.aspx

Zeitgleich wurde auch ein Preview auf VS-2013 veröffentlicht.
http://blogs.msdn.com/b/visualstudio/archive/2013/06/26/visual-studio-2013-preview-available-now.aspx