CLR-COM Interop

[This is a very old article I wrote back in 2002 when I worked for a company which built MRI scanners and was subsequently bought by Oxford Instruments. With COM being once again relevant with the introduction of WinRT, I thought it might be useful to revisit some core COM and .NET concepts.]

Details

CLR-to-Native Win32

The CLR subsystem responsible for managing access to the native platform is known as P/Invoke. These services are included in an application by use of the namespace System.Runtime.InteropServices, and the [DllImport(“<DLL_NAME>”)] attribute prepended to the function prototype.

When a call goes out to a piece of Unmanaged code from Managed code (CLR), a flag is set on the application’s CLR (pseudo-) stack. This causes the GC not to collect during the duration of the Unmanaged call. The Security Subsystem responds to the flag by searching up the stack for permissions to enter Unmanaged code. The security check can be suppressed by a call to System.Security.SuppressUnmanagedCodeSecurity, which prevents stack crawling by the Security Subsystem beyond the point at which the call was made.

Continue reading CLR-COM Interop

Advanced Call Processing in the CLR

[This is a very old article I wrote back in 2002 when I worked for a company which built MRI scanners and was subsequently bought by Oxford Instruments. With COM being once again relevant with the introduction of WinRT, I thought it might be useful to revisit some core COM and .NET concepts.]

Details

Method Calls

Every object in the CLR has type information associated with it, in the form of a 36-byte header:

Advanced-Call-Processing-in-the-CLR-1

Every method on the object has an entry in the method table (which acts in a similar way to a vtable in C++). Each entry is in effect a function pointer, and all method calls on the object come via the method table.

Immediately following object construction (using the .ctor or .cctor method) the objects method table appears thus:

Advanced-Call-Processing-in-the-CLR-2

Continue reading Advanced Call Processing in the CLR

CLR Contexts

[This is a very old article I wrote back in 2002 when I worked for a company which built MRI scanners and was subsequently bought by Oxford Instruments. With COM being once again relevant with the introduction of WinRT, I thought it might be useful to revisit some core COM concepts.]

Details

Definitions

A Context is a way to group together CLR objects having similar runtime (execution) requirements. Contexts are created as needed by the CLR. Cross-context calls require proxies, in a similar manner to cross-Apartment calls in COM.

Execution requirements could include:

  • Synchronisation
  • Transactional support
  • Database updates

Contexts also allow arbitrary message processing to be ‘plugged-in’ to the method-processing architecture by the use of Proxies.

Continue reading CLR Contexts

Assert-based Error Reporting in Delphi

[This is a very old article I wrote back in 2002 when I worked for a company which built MRI scanners and was subsequently bought by Oxford Instruments. The driver for this was “…Until Delphi acquires native functions equivalent to the C [__LINE__ and __FILE__] macros, … the need for this Assert-based framework … will remain” The need to trace errors to a specific class and line number, especially in production code, has only become stronger since then.]

Summary

This note describes a simple but flexible error-reporting and tracing framework for Delphi 4 and above based on Assert, which provides the unit name and line number at which errors were trapped and traces made.

Details

Background

Under the Delphi Language there is no simple way of replicating the C/C’++ macros FILE and _LINE_ to obtain the unit name and line number of memory address at runtime. However, in his paper “Non-Obvious Debugging Techniques” Brian Long points out that the Delphi compiler provides both unit name and line number during a call to Assert, and describes how assertions can be exploited to provide detailed execution tracing.

The framework described here extends this idea to allow flexibility in the processing of assertions. Assertion processing can be switched on and off at runtime; arbitrary filtering can be applied to any assertion; and both execution tracing and ‘standard’ assertion behaviour (i.e. raising an exception) can be effected. Assertions can therefore be left enabled in production code, at the expense of a slightly larger binary executable.

Continue reading Assert-based Error Reporting in Delphi

Test automation tools for WinForms desktop applications

For a client in the financial services sector, I recently had to identify some candidate products for use in automating the testing their WinForms and VC++/MFC Windows desktop applications. The applications are used for trading financial instruments, so correct operation is absolutely essential.

UPDATE: this 2019 post from Joe Colantonio has a newer list of testing tools for Windows Desktop apps. WinAppDriver, Winium, and White Framework seem to be the best options.

Drop Test by Christoph Bauer - http://www.flickr.com/photos/h34dy/
After a bit of investigation and digging round in the more murky reaches of my memory, I came up with the following list of  test automation tools for Windows desktop  applications:

Continue reading Test automation tools for WinForms desktop applications