dll late binding via LoadLibrary()

[[beginning vc++2010]] P1179 — a host app can run for a while before loading a dll. I guess in the interim a user can replace the dll.

benefit — smaller app footprint . All those large DLLs will only load into memory when needed, on-demand.

Advertisements

window procedure in microsoft windows app, briefly

http://msdn.microsoft.com/en-us/library/ms644927(v=vs.85).aspx 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 (http://bigblog.tanbin.com/2013/04/for-administration-prefer-command-line.html), 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.

##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
* MSSQL

———
* iis
* messaging server
* sharepoint server 
* exchange server 
* GUI dev – winforms
* GUI dev – MFC
* web development – silverlight
* web development – ASP, ASP.net
* 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.)

http://msdn.microsoft.com/en-us/library/ms644927(v=vs.85).aspx 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.

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
http://msdn.microsoft.com/en-us/library/ms973843.aspx
http://www.desaware.com/tech/dllhell.aspx (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.