Microsoft COM – a few keywords

“COM library” vs “type library”???

I suspect most code (whether people mention COM or not) written before dotnet are probably technically COM code???

— dotnet without the dotnet context —

Client/server — A COM client is whatever code or object that gets a pointer to a COM server and uses its services. A COM server is any object that provides services to clients. In-process servers are implemented in a dynamic linked library (DLL), and out-of-process servers are implemented in an executable file (EXE). Out-of-process servers can reside either on the local computer or on a remote computer.

Registry — COM types are usually listed by GUIDs in the registry, though some COM types are RegFree

DLL — COM components are usually implemented in DLL files, and registration allows only a single version of a DLL. Dotnet classes also exist in DLL or EXE files.

MS-Office – For example COM allows Word documents to dynamically link to data in Excel spreadsheets
Bindings — COM interfaces have bindings in several languages, such as C, C++, Visual Basic

ActiveX – is part of COM

— Excel Addin —
All COM Add-ins must implement each of the five methods of this interface: OnConnection, OnStartupComplete, OnAddinsUpdate, OnBeginShutDown, and OnDisconnection.

exit code lost – Horror story on Microsoft dev environment

This is such a poorly documented feature!

If you run your exe and then echo %ERRORLEVEL% you can get the correct exit code 99. If you use WScript.Shell Exec to invoke it, then check the ExitCode property you always see 0.!topic/microsoft.public.scripting.vbscript/gR_Gi87qojU shows the solution.

Do While objExec.Status = 0
WScript.Sleep 100

WScript.Echo objExec.ExitCode

windows task scheduler tips

To view the hidden scheduler log, use DOS to list the files in c:windowstasks folder. Or use notepad++ on c:WINDOWSTasksSchedLgU.Txt

To increase the log size limit, follow

— forever running tasks

This will block subsequent reruns.

Fix: try the max run time (default 72 hours)

Fix: To kill forever-running tasks, restart the task scheduler “service” itself

Some reasons for a forever-running task

* vbs may need to use wscript.quit

non-intrusive test – if current process has admin privilege

Just run qq(openfiles) command.



Information in this message is confidential. It is intended solely for the person or the entity to whom it is addressed. If you are not the intended recipient, you are not to disseminate, distribute or copy this communication. Please notify the sender and delete the message and any other record of it from your system immediately.


window procedure in microsoft windows app, briefly explains that Every (visual) window is an instance of a window class. “Every window class has a window procedure, and every {{visual}} window created with that class uses that same window procedure to respond to messages.”

Therefore every visual window has a window procedure – a function that processes all messages sent or posted to All window instances of the class. The window procedure (i.e. callback) has the business logic.

sys instrumentation: win32 murkier than linux #c++@@

See also

I recently browsed [[inside windows debugging]]. In the past I also browsed a few *nix system programming books. I’m more afraid of windows than *nix. Windows is more dark and murky; linux is more open and consistent. As a beginner, I feel in linux the challenge is interpreting tool output but on windows it’s getting past the installation and security restrictions.

  • complication: GUI — As explained in this blog (, GUI tends to hide a lot of features in layers and compartments. Console tools provide the same amount of power features …
    • if there’s a security or registry or other issues that reduce the provided feature set to below 100%, a console tool is more likely to report it to the user but GUI tools often “intelligently” handle it as if it’s normal.
    • MSVS is the primary windows instrumentation tool – very complicated.
  • complication: tool installation – Linux tools are not easy to install, but Windows tools tend to be even harder to install.
    • ** registry.
    • ** On any platform GUI tools are, on average, harder to install. Linux tools are less likely GUI.
  • complication: security restrictions – for a novice, 1/3 of the problems with windows tools are related to security/permission. Even under an administrator account, there are many security restrictions we may need to painstakingly disable! I don’t have any example now. I feel windows was criticized as vulnerable so Microsoft added a lot of security features.
    • ** some security features seem to be controlled by the domain administrators.
  • complication: environment factors – If you run the same tool in 2 machines with different results it’s often due to environment factors. In Linux, environment variables and some utilities are the only environment factors I know. In windows there seem to be many more places to check.
    • ** registry
    • ** certificates
    • ** control panel items
    • ** secpol.msc
  • complication: tool availability – many windows tools are commercial. On windows, I generally find the open-source tools better-quality, but for some tasks there’s only one tool – shipped by Microsoft. If I feel it is often crippled. On linux the best tools are invariably open-source.
  • complication: undocumented features — Even if you follow the all documented procedures, still you may hit something unexpected, due to undocumented features. This happens more often on windows then linux.

Note undocumented features affect not only instrumentation tools, but other components of the platform, which affect our debugging.

[[inside windows debugging]]

P38 has a half-pager comparison of the 2 main debuggers

^ MSVS – dev environment, with source code available

^ windbg – production environment. For post-coding, without source code.

** script/SQL debugging – only MSVS

P38 points out the free MSVS-express lacks certain debugging features. WinDBG is Completely free.

Q: does “windows debugger” mean windbg + minor tools?

–symbol files, symbol servers, *.pdb files


P54 – “public symbols” and the microsoft online public symbol server.

##windows GTD skillset, my take

(master copy? Recrec)

Dotnet is like java, right? Dotnet developers operate in a sandbox similar to the java developer?

Wrong! I feel a windows developer team operates in an ecosystem that’s fundamentally different from a java development ecosystem. Differences lie beneath the surface.

Since all of my java servers run in linux (or unix), I also need some linux platform knowledge, but nothing in-depth.

A windows developer needs a lot of specific (platform) skills. The list below is what I feel I need to pick up. [[Inside windows debugging]] by a MS veteran points out loads of essential know-how required for dotnet (or pre-dotnet) hacking beyond the MSVS debugger. From this book i get the sense that every serious windows developer need (non-trivial) windows know-how.

As an analogy, serious sql coders need (non-trivial) knowledge of optimizer and query plan.

I feel the average windows developer don’t have the capacity to know all of these. Perhaps some guys specialize in winforms some in wpf, some specialize in web development, some specialize in VB, some specialize in c# server side… Yet it’s not inconceivable for some lead developer/architect to have some experience with all of these, and some deep experience in a few topics.

* windows TCP/IP – Microsoft has its own implementation
* windows threading – many small differences from java threading, even though the concepts match.
* windows web service (SOAP etc) – Microsoft has its own implementation
* debugger – remote debugger
* xml parsing – Microsoft has its own implementation
* office integration (COM), excel addin
* IDE – many many must-know 
* project configuration, 
* application configuration
* GUI dev – silverlight
* GUI dev – wpf
* set up WCF service and host
* c# loggers
* powershell, DOS scripting

* iis
* messaging server
* sharepoint server 
* exchange server 
* GUI dev – winforms
* GUI dev – MFC
* web development – silverlight
* web development – ASP,
* web development – vbscript, jscript etc

The blog title says “windows” because I believe a serious dotnet developer always knows windows well beyond dotnet. Many __dotnet__ dev skills require windows platform knowledge. (In java projects platform knowledge is useful but not as essential as in dotnet.) I believe a dotnet developer has to become a windows developer to be truly competent.

– COM integration
– MS-Office integration
– interop with VB, VC, both rich-history technologies retrofit into dotnet
– windows debuggers
– sysinternals tools
– registry
– application installer/uninstaller
– event viewer
– performance counters
– dotnet threading is based on win32
– WCF is based on a earlier Microsoft remoting technologies

machine-wide msg queue + per-GUI-thread msg queue

(Backgrounder — Windows GUI are event-driven. Most events, including mouse/keyboard events, come through the message pump.) shows that MSWin message queues come in 2 flavours —

1) a machine-wide msg queue

2) per-thread msg queue for each GUI thread, i.e. for each thread that creates visual window(s).

The system removes the user-generated messages, one at a time, from the machine-wide message queue, examines them to determine the destination (visual) window, and then posts them to the message queue of the thread that created the window. (Your own code on) the thread removes [1] messages from its queue and sends[2] them to the appropriate window procedure.

You usually write your own message loop to remove and send messages to window procedures. Applications with multiple threads can include a message loop in each thread that creates a window.

Only one message loop is needed for a message queue, even if an application contains many windows. DispatchMessage() always dispatches the message to the window procedure of the proper (visual) window.

[1] GetMessage() — An application can remove a message from the per-thread queue by using the GetMessage() function.

[2] DispatchMessage() — Application (your code) can use DispatchMessage()to send the message to a window procedure.

untold horror stories in Microsoft dev environment

Other horror stories:

* In my projects, logs folder can become inaccessible even though no one but my own services were touching it.
——— looks like a typical horror story about Microsoft development platform.

– too many binary files involved. In unix environments ascii is the format for most files developers need to deal with. I feel from the beginning unix favors ascii. That tradition has endured the test of time and is going strong. I feel ascii is Clean and efficient. If a platform must use so many binary files, it’s a sign of weakness and non-ideal design. Simplicity is not easy to achieve or maintain. Look at copy-paste.

– outcome depends too much on the idiosyncrasies of the IDE. In unix-like environments, all the standard dev tools are command line tools, usually more transparent than a GUI tool.

– environment dependency and esp. the Mysterious Monstrous Murky registry — the worst problem IMO. It’s a local environmental config that’s pretty invisible. That means the same source code compiled on another machine may not behave the same. Even if you copy everything to another machine it may behave inconsistently.

– The platform is not robust enough. You may say it’s all developer’s fault, being inexperienced with the platform and tools. Well, I have substantially fewer such problems on other dev platforms. I’d venture to say a unix veteran hits fewer such problems than a windows veteran. If you follow the standard procedure and hit this kind of roadblock, it’s disappointing and stressful. This platform tends to throw up too many such roadblocks. Other platforms are more consistent and robust.

Look, every dev platform has complexity under the hood. As a higher-layer app developer we shouldn’t need to know a lot under the hood. The platform should be robust and just work. When we are forced to look under the hood, usually it’s a premature, unprofessional dev platform. As a 3-year old eclipse user, I  feel eclipse is such a premature tool, but other tools in java land are simpler and very robust.

This story also reminds me of my very first programming project in Microsoft dev environment. It’s a VBA project. Some basic FTP functionality was rather hard to implement. The MS-supplied infrastructure was not fully documented. Took several false starts. I soon left the MS platform for greener pastures — LAMP, javascript, unix, java, … and never looked back. Notably, Mysql had the best documentation and no surprise.

A recent project experience is again similar. We just couldn’t get auto update to work on a SL-OOB application. Auto-update once worked but now stopped working. What changed? We checked all the known issues… mystery, opaque, hidden under the hood, undocumented.

COM interop, learning ntoes

Dotnet interop (2-way) — allows COM-based applications to use .NET components, and .NET applications to use COM components

Dotnet wrapers — Microsoft now focuses much of its marketing efforts on .NET, with .NET providing wrappers to the most commonly used COM controls. However, your own custom COM classes don't have wrappers yet. You can consider COM interop in order to use them in dotnet.

regasm – is needed when your new COM needs an existing dotnet assembly

regasm.exe, learning notes

I keep forgetting that regasm is needed when your new COM needs an existing dotnet assembly. Therefore you regasm a dotnet assembly file, not an existing COM DLL.

COM types are defined in a type library. A type lib can be a standalone *.tlb file OR embedded in a non-dotnet dll or exe file.

regasm.exe reads the metadata within a dotnet assembly and writes into the registry, which allows COM clients to create .NET Framework classes. After that COM clients can use it as though the class were a COM class. Instances of classes within the dotnet assembly can be created from within dotnet but not from COM until they are registered.

regasm.exe can optionally otuput a TLB file. Tlbexp.exe does the same. A COM client can then use the TLB file to instantiate the a dotnet class, as it instantiates a COM class.

dll hell (LoadLibrary) – solved in dotnet

Very common IV question…

[[Beginning vc++ 2010 ]] P 1178 has a good half-pager. Some pointers in my own language:
* a DLL is loaded (into mem) separately from the host app
* when you overwrite a dll on disk, the host app can load fine, which will automatically get the new dll to load. Happy scenario
* however, the same dll might be needed by another host app, which may now fail.

—-dll hell defined (circa 1998) covered pre-DLL era, good-DLL era, bad-DLL era

The reason for this issue was that the version information about the different components of an application was not recorded by the system.

The Re-install scenario: It would not be unusual to own several installers each embedding a different version of the same DLL. It is not unusual for users to reinstall software. In many cases users would install software that included an older version of commdlg.dll on a system that already contained a newer version. This would cause the more recently installed version to replace the newer version. As soon the user attempted to run the program that required the newer version, problems would occur ranging from operational difficulties to general protection faults.

Dotnet solved the problem. GAC can hold 2 versions of the same DLL. Earlier app would still use the version she likes.

I guess late binding via LoadLibrary() can also reduce dll hell.