GoingNative 2012: Wonderful sessions on C++11

Are you a C++ developer? Then, its for you. Recently I was watching Channel9, “GoingNative 2012” – wonderful sessions on C++. Please find the related links for your reference:

• Bjarne Stroustrup: C++11 Style
• Hans Boehm: Threads and Shared Variables in C++11
• Stephan T. Lavavej: STL11 – Magic && Secrets
• Andrei Alexandrescu: Variadic Templates are Funadic
• Panel: The Importance of Being Native (Bjarne, Andrei, Herb, Hans)

• Herb Sutter: C++11, VC++11 and Beyond
• Chandler Carruth: Clang – Defending C++ from Murphy’s Million Monkeys
• Andrei Alexandrescu: Static If I Had a Hammer
• Bjarne Stroustrup and Andrew Sutton: A Concept Design for C++
• Panel: Ask Us Anything! (all speakers)

Happy programming!!

Click to connect MSDN/TechNet forums from your desktop

http://www.facebook.com/widgets/like.php?href=http://blogs.msdn.com/b/deva/archive/2011/12/13/click-to-connect-msdn-technet-forums-from-your-desktop.aspx

Using MSDN Forum Assistant and TechNet Forum Assistant gadgets offer a convenient way for the forum users to read the forum recent threads and your own threads, it also make it easy to create new threads and search in the forum.

How is simple is that…. I tried the gadgets at my Windows 7 machine in 3 simple steps

1. Double-click the gadget installation package.

2. On the popup window, click “Install” to finish the installation.

  

3. The gadget usually will be automatically located on the desktop. If not, look it up from the Gadget Gallery and add it to the desktop

Development : Threading with Outlook Object Model?

Developers do complain when they use multi-threading the Outlook Object Model (OOM) API, it fails or hangs inside and outside of Outlook?  The reason behind this is the Outlook Object Model is not thread safe which means that COM will never allow multiple threads to enter concurrently.  Instead, it will serialize all calls using a message-based protocol which, in turn, means that the user will not be able to interact with Outlook while your background thread is being serviced and vice-versa.

If your COM object needs to believe that it is in a single-threaded environment, use STA. You are guaranteed that the creation and all calls will be made by the same thread. You can safely use Thread local storage and you don’t need to use critical sections.

In general, rules for single-threaded apartments are simple, but it is important to follow them carefully:

• Every object should live on only one thread (within a single-threaded apartment).
• Initialize the COM library for each thread.
• Marshal all pointers to objects when passing them between apartments.
• Each single-threaded apartment must have a message loop to handle calls from other processes and apartments within the same process. Single-threaded apartments without objects (client only) also need a message loop to dispatch the broadcast messages that some applications use.
• DLL-based or in-process objects do not call the COM initialization functions; instead, they register their threading model with the ThreadingModel named-value under the InprocServer32 key in the registry. Apartment-aware objects must also write DLL entry points carefully. There are special considerations that apply to threading in-process servers. For more information, see In-Process Server Threading Issues.

To isolate the issue, you can try running two instances of Outlook in same machine? Can you do that. The answer is No, you can’t do that. So all calls to the Outlook object model execute on Outlook’s main foreground thread. When you design or develop application, the only threading model supported by Outlook object model is single-threaded apartment (STA). Calling the Outlook object model from a background thread is not supported.

I recommend you also to refer pcreehan’s blogpost regarding this.

Monitoring Event Sink # 32 – Best Practices: Performance related issues with Event sinks

I would like to share certain best practices – in order to improve the performance or overcome performance related issues associated with event sink and Programming guidelines for event sinks before you develop for your reference.

• Exchange store events do not by themselves generate Windows Event Log entries. The underlying ExOLEDB provider generates performance counters for each event sink. The code that executes in response to an Exchange store event code can also generate Windows Event Log events and information for Windows Performance Counters.
• Exchange store events that can be misused, or that can cause problems if installed incorrectly, should implement the ICreateRegistration interface, and programmatically prevent the event sink from being improperly registered. Cross-store access from within an event sink is not possible. Once registered and wrapped as COM+ applications, any user who knows the name of the event sink can register it in a folder to which they have write permissions.
• If you have to register an event sink for all mailboxes in a store, you should register the event sink for store-wide events.
• When Exchange starts up, it looks for and loads all registered event sinks, which takes some time.
• Using many individual event sink registrations instead of a single store-wide event registration item significantly increases server startup time.
• Always use care when running store event sinks, especially when using synchronous event sinks.
• A synchronous event sink is triggered after a data request to the Exchange store but before the item is committed to the store.
• The synchronous event sink has exclusive control over the item while it is processing. Therefore, a complex or poorly written sink can lock a resource for some time, or even bring an Exchange server to its knees.
• But, I would recommend you to go through the Programming guidelines for event sinks before you develop:
  
  • For optimal performance, create an in-process Component Object Model (COM) class that supports execution in a multi-threaded apartment (MTA). The event dispatcher threads execute from within the Microsoft Internet Information Services (IIS) MTA. If your sink supports the single-threaded apartment (STA) only, then all interfaces will be marshaled across the MTA apartment and STA apartment boundaries.
  • Provide an implementation of the IEventIsCacheable interface by your sink. If you implement the IEventIsCacheable interface and the IsCacheable method returns S_OK, the event dispatcher will cache the sink and will use the same object for subsequent events; otherwise, each event will create a new instance of the sink.
  • Never install an untested sink on a production server, especially a sink that runs in- process. Exceptions thrown from within these in-process sinks may disable the IIS (inetinfo.exe) process or cause it to stop responding.
  • Do not place Microsoft Collaboration Data Objects (CDO) interface definitions in your sink’s interface definition language (IDL) file (if you use one directly) when working in C or C++. Information about CDO types—including all classes, interfaces, enumerations, and modules—can be found in the supplied headers. If you do place IDL information in your IDL file, and any of these types are referenced from within your library statement, you will re-map various Interface IDs (IIDs) from the CDO dynamically link library (DLL) to your DLL. This will not cause immediate harm because your DLL contains the necessary type library information required for the universal marshaller to function properly; however, if you subsequently remove the sink from the registry, the CDO libraries will function improperly.

Happy programming !!