Community Forums NNTP bridge

The result is a single “Community Forums NNTP Bridge” which can replace the MS NNTP Bridge. It also integrates both web services (*social*, *answers*) into a single NNTP server; so the “feeling” is like before the split

If you are interested, you can take a look (with full source code) into the alternative:
http://communitybridge.codeplex.com/

1>...Microsoft.CppBuild.targets(990,5): warning MSB8012:
  TargetPath(...LeakFinder_VC9.exe) does not match the Linker's OutputFile property value (...LeakFinder.exe).
  This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).

or

1>...Microsoft.CppBuild.targets(992,5): warning MSB8012:
  TargetName(LeakFinder_VC9) does not match the Linker's OutputFile property value (LeakFinder).
  This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).

The problem is, that the following two settings are not identical (Target Name, Target Extension):

and (Output File):

If you match those two, the warning will be gone

For example, if you have named your EXE in Debug-Builds: “MyAppd.exe” and in Release-Builds “MyApp.exe”, I suggest that your only change the “Target Name” in the General-Page to “MyAppd” (for Debug) and “MyApp” (Release) or ($(ProjectName) if it is the same name as the project).
Then you must also change the “Linker | General | Output File” to the default setting: “” or “$(OutDir)$(TargetName)$(TargetExt)”. This setting is always suggested!

If you want to change the output directory, you should the the “General | Output Directory” setting.

More info about this conversion problem can be found here:
Visual Studio 2010 - $(TargetName) macro
Visual Studio 2010 C++ Project Upgrade Guide

But you the source-code is still available! You can find it under

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Samples\1033\VC2010Samples.zip

Extract the files and build (the release version of)

C++\MFC\ole\oleview\oleview.sln

Then you have the two files: oleview.exe and iviewers.dll

Also, the same problem is with the OLE-Test Container (tstcon). This application can also be found in the samples.
See also: ActiveX Test Container Application is Still Available

• Windows XP with SP2 and later
• Windows Server 2003 with SP1 and later
• Windows Vista RTM an later
• Windows Server 2008 RTM and later
• Windows 7 and later

This restrictions comes from a security desicion to have a hard dependency on EncodePointer, which is only available in the above OSes.

For more info see: Visual Studio 2010: Windows Platforms (CRT)

Also it has a good “!Analysis” command for dump-files.

The output of “!Help” is:

-------------------------------------------------------------------------------
PSSCOR is a debugger extension DLL designed to aid in the debugging of managed
programs. Functions are listed by category, then roughly in order of
importance. Shortcut names for popular functions are listed in parenthesis.
Type "!help ” for detailed info on that function. 

Object Inspection                  Examining code and stacks
—————————–      —————————–
DumpObj (do)                       Threads
DumpArray (da)                     CLRStack
DumpStackObjects (dso)             IP2MD
DumpAllExceptions (dae)            BPMD
DumpHeap                           U
DumpVC                             DumpStack
GCRoot                             EEStack
ObjSize                            GCInfo
FinalizeQueue                      EHInfo
PrintException (pe)                COMState
TraverseHeap
DumpField (df)
DumpDynamicAssemblies (dda)
GCRef
DumpColumnNames (dcn)
DumpRequestQueues
DumpUMService

Examining CLR data structures      Diagnostic Utilities
—————————–      —————————–
DumpDomain                         VerifyHeap
EEHeap                             DumpLog
Name2EE                            FindAppDomain
SyncBlk                            SaveModule
DumpThreadConfig (dtc)             SaveAllModules (sam)
DumpMT                             GCHandles
DumpClass                          GCHandleLeaks
DumpMD                             VMMap
Token2EE                           VMStat
EEVersion                          ProcInfo
DumpModule                         StopOnException (soe)
ThreadPool                         MinidumpMode
DumpHttpRuntime                    FindDebugTrue
DumpIL                             FindDebugModules
PrintDateTime                      Analysis
DumpDataTables                     CLRUsage
DumpAssembly                       CheckCurrentException (cce)
RCWCleanupList                     CurrentExceptionName (cen)
PrintIPAddress                     VerifyObj
DumpHttpContext                    HeapStat
ASPXPages                          GCWhere
DumpASPNETCache (dac)              ListNearObj (lno)
DumpSig
DumpMethodSig                      Other
DumpRuntimeTypes                   —————————–
ConvertVTDateToDate (cvtdd)        FAQ
ConvertTicksToDate (ctd)
DumpRequestTable
DumpHistoryTable
DumpBuckets
GetWorkItems
DumpXmlDocument (dxd)
DumpCollection (dc)

Examining the GC history
—————————–
HistInit
HistStats
HistRoot
HistObj
HistObjFind
HistClear

A user reported this bug in the WinDbg newsgroup.

I now build a small repro-code, which shows the problem. You can download the code here: dbghelp_bug_6.12.2.633.zip

The problem is, that the size of the struct “IMAGEHLP_MODULE64″ has changed. They added two DWORDs at the end (the struct has now a size of 0×690 bytes). This is normally not a problem because the struct has a “SizeOfStruct” member, which must be set, prior to calling the “SymGetModuleInfo64″ function.

But the new version does not support the older version of the struct with a size of 0×688 bytes, which is commonly used because this was the last version since 2003!!! It only supports the older versions from 2002 and before.

So I hope that this major bug will soon get fixed… but after the WinDbg-Release seems to be coupled to the WDK-release, we can wait until next year…

For example, there is a bug with the DateTime-Format, which uses the current system locale… This bug was reported severaly months ago, and nothing happend… In january and february it was not a problem, because “Jan” and “Feb” are the same in english and german… but in “März” the NntpBridge started to report all postings with “01.01.1970 01:00″… because it will report the date as “Mrz” instead of “Mar”… which is somehow bad…

So I decided to make a quick fix for this behavior. You just need to add the System.Globalization.CultureInfo.InvariantCulture as parameter to the ToString method.

Here are the steps, how you can fix this by yourself:

1. Locale the directory of the Nntp-Bridge (normally “C:\Program Files (x86)\Microsoft Community Tools\Microsoft Forums NNTP Bridge”
2. Copy the file “nntp.dll” to “nntp_org.dll” so you have the original version saved
3. Copy “nntp.dll” into a temporary directory like “c:\temp\nntp_fix”
4. Open a “Visual Studio 2005/2008 Command Prompt (x86)”
5. Go to the temporary directory (cd /D c:\temp\nntp_fix)
6. Disassemble the nntp.dll

   ildasm nntp.dll /out=nntp.il

7. Now you need to change the content of the nntp.il file
8. Find the method “GetMessageFormat” and change it from

   .method public hidebysig static string  GetMessageFormat(valuetype [mscorlib]System.DateTime dateTime) cil managed
   {
     // Code size       28 (0x1c)
     .maxstack  8
     IL_0000:  ldstr      "{0} {1}"
     IL_0005:  ldarga.s   dateTime
     IL_0007:  ldstr      "ddd, d MMM yyyy HH:mm:ss"
     IL_000c:  call       instance string [mscorlib]System.DateTime::ToString(string)
     IL_0011:  ldsfld     string Nntp.NntpTimeUtility::GmtTimeZoneOffset
     IL_0016:  call       string [mscorlib]System.String::Format(string,
                                                                 object,
                                                                 object)
     IL_001b:  ret
   } // end of method NntpTimeUtility::GetMessageFormat
   

   to

   .method public hidebysig static string  GetMessageFormat(valuetype [mscorlib]System.DateTime dateTime) cil managed
   {
     // Code size       33 (0x21)
     .maxstack  8
     IL_0000:  ldstr      "{0} {1}"
     IL_0005:  ldarga.s   dateTime
     IL_0007:  ldstr      "ddd, d MMM yyyy HH:mm:ss"
     IL_000c:  call       class [mscorlib]System.Globalization.CultureInfo [mscorlib]System.Globalization.CultureInfo::get_InvariantCulture()
     IL_0011:  call       instance string [mscorlib]System.DateTime::ToString(string,
                                                                              class [mscorlib]System.IFormatProvider)
     IL_0016:  ldsfld     string Nntp.NntpTimeUtility::GmtTimeZoneOffset
     IL_001b:  call       string [mscorlib]System.String::Format(string,
                                                                 object,
                                                                 object)
     IL_0020:  ret
   } // end of method NntpTimeUtility::GetMessageFormat
   

9. Then compile the nntp.dll again (and delete the original dll before compiling (del nntp.dll)):

   ilasm /dll nntp.il /resource=nntp.res

10. Now you can copy the patched nntp.dll into the original directory (be sure, the application is not running).

Now it looks better:

That’s all! Happy NntpBridging

Starting with the new release, it seems that the Debugging Tools For Windows is now integrated in the WDK which means to download a 620 MB file.

Also it seems so, that the WDK does not install the Debugging Tools For Windows, it just installs a link to the setup…
So the question is: Why not provide the setup as a separate download as in previous version?

Here is a quote from the Debugging Tools For Windows download page:

This current version of Debugging Tools for Windows is available as part of the Windows Driver Kit (WDK). To download the WDK and install Debugging Tools for Windows:
1. Download and install the WDK.
2. Find the debugging tools link for Windows x86 version on the screen that appears and click to install the debuggers to a location of your choice.
3. After the installation is complete, you can find the debugger shortcuts by clicking Start, pointing to All Programs, and then pointing to Debugging Tools for Windows.

Conclusion: We will never understand marketing…

So I decided to dig into this almost not documented world and write a small Shim-Dumper and Exe-matching tool (whitch source code ).

Shim Database Tool (sdb) v1.0
Copyright (C) 2010 Jochen Kalmbach

Usage:  sdb.exe [-noids] [-match] [PathToShimDatabse] [PathToFileName]
 -noids  Will prevent the output of the TagIds
 -match  Will match the provided file with the installed databases
         and displays the activated shims
         In this case 'PathToFileName' is required

NOTE: If no shim database path is provided,
      the default database will be used.

You can use it either for dumping the shimdatabase like:

sdb.exe >ShimDatabase.xml

This will redirect the output to an xml-file and will look something like:

  <EXE typ="LIST">
   <NAME typ="STRINGREF">setup32.exe</NAME>
   <APP_NAME typ="STRINGREF">WordPerfect Office 2000</APP_NAME>
   <VENDOR typ="STRINGREF">Corel</VENDOR>
   <EXE_ID typ="BINARY" len="0x10" guid="BC47CDF2-14B4-3040-B4E7B72C01DF2482" />
   <APP_ID typ="BINARY" len="0x10" guid="0FB56022-BF5C-7445-A5CCA93B5C443E6A" />
   <MATCH_MODE typ="WORD" />
   <MATCHING_FILE typ="LIST">
    <NAME typ="STRINGREF">*</NAME>
    <COMPANY_NAME typ="STRINGREF">Corel Corporation</COMPANY_NAME>
    <PRODUCT_NAME typ="STRINGREF">Corel Setup Wizard</PRODUCT_NAME>
   </MATCHING_FILE>
   <MATCHING_FILE typ="LIST">
    <NAME typ="STRINGREF">programs\wpwin9.exe</NAME>
    <COMPANY_NAME typ="STRINGREF">Corel Corporation Limited</COMPANY_NAME>
    <PRODUCT_NAME typ="STRINGREF">WordPerfect&#174; 9</PRODUCT_NAME>
   </MATCHING_FILE>
   <MATCHING_FILE typ="LIST">
    <NAME typ="STRINGREF">appman\tools\cset90.exe</NAME>
   </MATCHING_FILE>
   <SHIM_REF typ="LIST">
    <NAME typ="STRINGREF">WinXPSP1VersionLie</NAME>
    <SHIM_TAGID typ="DWORD">0x284e0</SHIM_TAGID>
    <INEXCLUDE typ="LIST">
     <INCLUDE typ="NULL" />
     <MODULE typ="STRINGREF">$</MODULE>
    </INEXCLUDE>
    <INEXCLUDE typ="LIST">
     <MODULE typ="STRINGREF">*</MODULE>
    </INEXCLUDE>
   </SHIM_REF>
  </EXE>

(be aware: the current Win7 database is about 17 MB!)

You also can use this tool to find out, if an application has a shim applied:

C:>sdb -match MyInstaller.exe
Shim found for file: MyInstaller.exe
Flags: 0x0:
Exe-Shim: 0x35472, Flags: 0x0:
Layer-Flags: 0x0:
Shim-Database: 11111111-1111-1111-1111111111111111

Currently it just displays the TagId of the Shim. You can use this to search the xml-file for the corresponding id.

Have fun, using this tool

The project (VS2008) can be found here:
http://blog.kalmbachnet.de/files/sdb_v1.zip
It will compile for x86 and x64.

Here is a simple example:

int main()
{
  array<int> ^MyArray = { 100, 200, 300, 400 };
  for each( int v in MyArray )
  {
    System::Console::WriteLine(v.ToString() + " " + $I);
  }
  return 0;
}

As you can see, it uses a variable “$I” which was never decalred!
And it will output the following:

100 0
200 1
300 2
400 3

If you debug a normal for each loop and take a look in the “local-watch-window”, you will see the following variables, while you are inside the for each loop:

You can see two “hidden” variables “$I” and “$S1″. And if you step through the loop, you will see that the “$I” variable is incremented for each iteration. “$S1″ is a reference to the array.

If you dig further into this issue, you will find out, that for each and the normal “for” loop will result in the identical IL code! This is also true for C#!
See also:
FOREACH Vs. FOR (C#)
To foreach or not to foreach that is the question.

As we can see, the “$I” variable is just a side-effect of the for each loop. It is a compiler generated variable which is used to transform the “for each” into a normal for-loop!

Of course, this is only true in special cases like arrays.
If you have a list which only implements the “IEnumerable” interface and is not an array (like “System::Collections::Generic::List”), then the mistic variable “$I” is gone, because now the compiler uses the “IEnumerable” interface to gbuild a “real” “for each” loop:

In this case “$I” is gone but “$S1″ is still there. And “S1″ is the enumerator of the list (in this case

System::Collections::Generic::List::Enumerator<int>

).

The conclusion is:
Do not rely on the compiler generated variable “$I”, and do not use “for each” if you need a index-variable, just use a normal for loop.

Therefor this post

In VC6, by default the “/EHa” exception model ist activ.
In VC200x and later, by default, the “/EHsc” exception model is active. This means that if you did not explicit specify the “/EHa” model, you will now automatically use the “/EHsc” model, which only catches C++ exceptions!

For example, the following code will work as expected and will crash in VS2008:

#include <stdio.h>
#include <tchar.h>
 
int _tmain()
{
  try
  {
    printf("Now doing an AV...\n");
    char *c = NULL;
    strcpy(c, "Hello");
    printf(c);
  }
  catch(...)
  {
    printf("Catched....");
  }
}

So be aware, that if you rely on asynchonus exceptions, you need to switch the expetion model in the C/C++ project settings under “Code generation | Enabled C++ Exceptions: Yes with SEH Exceptions (/EHa)“

So today I moved at least the source code to codeplex:
http://stackwalker.codeplex.com/

It automatically embeddeds the comment from the check-in dialog into your source code.

Please feel free to post some comments in the discussion section.

See also my last post:
TFS: Automatically insert Check-In comments into source-code

While this is enough, if you always have access to the TFS. But if you work without TFS, then it would be helpfull if these comments are also included in the source-file (like in the old days, when we were using cvs (a feature called keyword-substitution)

I searched the web for any plugin for TFS which has almost the same features… but could not find any plugin….

So I wrote my own plugin, which at least puts the check-in comments into the source-file.
You just need to install this plugin and activate it in the “Check-In policy”.

Then your source-file will contai the comment, after you checked it in:

/*
 * $log$
 * 
 * Comment: And another test
 *          with a multiline
 *          comment...
 * User: xyz
 * DateTime: 2009-07-23 22:05:24
 * Change: edit
 * 
 * Comment: This is an test
 * User: xyz
 * DateTime: 2009-07-23 21:01:22
 * Change: add, edit
 *
 */

I can also customize (like templates) the position and contents of the comments…

If you are interested in this plugin-in, please let me know…

Just a small addition: Here is a post about “keyword expansion” and TFS; and possible side-effects:
http://blogs.msdn.com/buckh/archive/2007/07/07/keyword-expansion-in-tfs.aspx

EDIT: 2009-08-08:
Today I published my first release of the LogSubstPol on CodePlex.

This feature is implemented with an shim (in a separate article I will explain shims later).
In short it works like: if an application is started, it checks the shim-database (in general %SYSTEMROOT%\AppPath\sysmain.sdb) if this application matches specific conditions.

For “Installer detection”, there are several conditons. Here is a list, what is checked (Vista and Win7RC1):

• Productname contains “*instal*” or “*setup*” or “*update*”
• Companyname contains “*instal*” or “*setup*” or “*update*”
• Internalname contains “*instal*” and app is not named “TrustedInstaller.exe”
• Originalfilename contains “*instal*” and app is not named “TrustedInstaller.exe”
• Filedescription contains “*instal*” and app is not named “TrustedInstaller.exe”
• Filename contains “*instal*” and is not named “TrustedInstaller.exe”
• Exportname contains “setup.exe” or “install.exe” or “stub32″ or “stub32.exe” or “signstub.exe”
• Filename contains “*patch*” or “*setup*” or “*uninst*” or “*update*” or “lhaca*.exe”
• Filedescription contains “*instal*” or “*setup*” or “*update*” or “*uninst*”
• Originalfilename contains “*setup*” or “*update*”
• Originalfilename contains “*setup*” or “*update*”

What is the conclusion: If you want to prevent the message box, just name your installer “TrustedInstaller.exe”

You can simple test this by renaming any EXE to “abcinstaldef.exe” and try to execute it and the rename it to “TrustedInstaller.exe”

On the other hand: Never name your app anything of the above!

The problem is that by default VC2008 uses the DLL-version of the CRT/MFC. These DLLs are not pre-installed on any OS.
To overcome this problem, you have tree options:

1. Statically link to the CRT/MFC
2. Use vcredist_x86.exe / vcredist_x64.exe to install the DLLs in the system
3. Deploy the CRT/MFC DLLs with your application (in the same directory)

In the following I will explain the last option. Especially in conjunction with VS2008 service pack 1 (SP1). Because this leads to a little bit more compications in ApppLocal deployment.

In general, it is very easy to deploy your application with the needed CRT/MFC DLLs.
Just copy the contents of the directory

• C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT
• C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.MFC

into the same directory as your application. Then you should have the following files in your app-folder:

Microsoft.VC90.CRT.manifest
msvcr90.dll
msvcp90.dll
msvcm90.dll
Microsoft.VC90.MFC.manifest
mfc90.dll
mfc90u.dll
mfcm90.dll
mfcm90u.dll

Then your application works on an other computer!

BUT: This does not work, if you installed VS2008-SP1

The problem with VS2008 SP1 is: It overwrites all files in the “VC\redist” directory with the new version. This is not really bad. The problem is: It has a newer version number inside the manifest files. But if you compile your application with VS2008-SP1 it write the RTM-version into the application manifest! Now the version number in your application manifest does not match the version in the “new” CRT/MFC manifest. Therefore it will refuse to load these DLLs and your application cannot start.

The simplest way to overcome this problem is by changing the “Microsoft.VC90.CRT.manifest” and “Microsoft.VC90.MFC.manifest” files. Replace the version attribute in both Microfot.*.manifest files from “9.0.30729.1″ (or whatever version/SP you have) to the version number in your applications-manifest (which is normally “9.0.21022.8″ (RTM)).
Old:

version="9.0.30729.1"

New:

version="9.0.21022.8"

Then your application will work on an OS without installing anything.

Alternatively, you can change your applications manifest, so that it uses the new version number. This can easily done by defining

#define _BIND_TO_CURRENT_VCLIBS_VERSION 1

in stdafx.h (at the top) or in your project settings. This will embed the actual CRT/MFC-version into your applications manifest (works starting with VS2008-SP1).
Also, if you use new features from the MFC-feature-pack, you should always define this!

Just a small note: You should be aware, that this “AppLocal” installation is not really “AppLocal”… it is only AppLocal, if the vcredist_*.exe was not installed. If the vcredist_*.exe is installed, then the DLLs from the WinSxS directory will be used. If you want to prevent this, you can do a really AppLocal deployment.

A small addition: If you write .NET-apps (/clr) you still must install the .NET Framework redistributable.

But the goood news is: Starting with VC2010, the manifest (WinSxS) is gone

• “auto” is now a keyword
• “static_assert” is now a keyword
• Lambda support excludes support for unquoted GUID in an IDL (it uses the same […] syntax)
• Some “.NET-Exceptions” can now only be caught with __try __except
• /GS checks might decrease performance
• Project files are automatically converted to the new .vcxproj
• CRT/MFC/ATL/OpenMP-DLLs no longer use fusion (huray!); it uses plan old dll-hell
• Support for environmentvariable __MSVCRT_HEAP_SELECT was removed
• New _ITERATOR_DEBUG_LEVEL macro (replaces _SECURE_SCL and _HAS_ITERATOR_DEBUGGING)
• hash_map and hash_set are now in the std namespace (previously in stdext)
• SafeInt is included