Weekly report (July 21)

Here is the status report for July 21st.

It has been quite a productive week during which I worked mainly on creating the infrastructure for an automated test suite and on implementing memory management for the COM objects. The test suite is a little tricky – it is meant to be executed using makefiles generated by autoconf/automake; this means that a POSIX-like environment is needed. On the other hand COM is mainly a Win32 technology, so some kind of a hybrid system is needed. My goal is to support the following configurations:

– Unix system using winegcc for compilation and wine for execution,
– Unix system using MinGW for compilation and wine for execution,
– MinGW/Cygwin using their own compilers,
– MinGW/Cygwin using MSVC.

Support for all these configurations has been added to the autoconf/automake scripts, but winegcc is the only one that has really been tested. The others will be tested after the infrastructure is reasonably complete and I write a few meaningful test cases.
The execution of a single test case consists of calling SWIG on an .i file, building the component based on the output, registering it, building an executable that makes use of the component through COM and unregistering the component. The goal is for the test case to have as few side effects as possible; this is harder to do in COM than in Java and C# because the component needs to write its entries to the registry. Currently there is only one test case in SVN, and it only writes “Hello world” :), but I’ve mainly been busy with the infrastructure.

Some other things I have been working on:
– DllUnregisterServer is implemented,
– the wrapper file can now be compiled and run in Unicode mode; does not seem extremely useful, but who knows :),
– reference counting has been made thread-safe; it now uses InterlockedIncrement/Decrement. The goal is for the wrapper to be thread-safe as long as the underlying module is,
– a global reference count has been created and DllCanUnloadNow has been implemented,
– objects are now properly disposed if their reference count reaches 0; this means that if a proxy ‘owns’ an underlying C++ object (i.e. it has been created using a wrapper around a constructor or using a function marked as %newobject) it is deleted (calling the proper destructor). Then the proxy itself is deleted,
– as already mentioned object ownership has been implemented – this allows to distinguish objects that should be deallocated together with their proxies from the ones that are deallocated in the wrapped C++ code,
– constructors are now exposed as member functions of the module class (in a similar way like global functions and static member functions). I have described the motivation behind this in an earlier message; in short a constructor does not make sense as a virtual function (and all functions in a proxy are virtual, and thus inherited by its descendants) and so they are implemented just like they were global functions returning a pointer to the constructed object. Objects can also be created using CoCreateInstance for convenience, as long as they have a default constructor (if they don’t then there will be a compiler error – I will need to fix this).

For the next week I plan to make sure that the test suite infrastructure is fully functional and to write some tests. Afterwards I will try to tackle the missing language constructs that still haunt me – enums and constants.

As always feel free to contact me with any comments/suggestions/critique.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: