DCOM Explained
by Rosemary Rock-Evans
Digital Press
ISBN: 1555582168   Pub Date: 09/01/98

Previous Table of Contents Next


Chapter 6
ActiveX

  Written in Java, C++, C, Visual Basic, OOCOBOL
  Can be developed using ...
  Visual Studio 97

  Delphi - Borland
  Micro Focus - Object COBOL
  Obsydian - Synon
  Fujitsu COBOL

  All Windows tools (NT, 95)
  Work underway to get Win32 APIs to work on other platforms
  Active Group work relevant here

The generic term for any piece of code that can be invoked via methods and interfaces is termed a component, and we have seen that automation servers are one form of component capable of being run on many platforms. Clearly, they might need to be recompiled to get them to work on other platforms using native compilers (we will see why I have said “might” later on in this chapter), but in essence the same component source code should be capable of being compiled to run on any platform supporting DCOM without needing to be changed (ActiveX components, however, are of special importance to DCOM because they work over the Internet and are intended to be portable).


Figure 6.1  ActiveX

About ActiveX

ActiveX components are a key part of Microsoft’s strategy. ActiveX components are like normal components in all respects, but as we have seen, they can be distinguished from normal components because they are intended to be portable.

In the future it should be possible to run ActiveX components on any platform supporting DCOM, as long as they use the COM model, communicate using DCOM services, and use the Microsoft Interface Definition Language to describe the interfaces.

A developer should be able to describe the interfaces and generate the source code for the stubs and proxies, write the component in his language of choice, then deploy it on the platform of choice by using the native compiler to convert the source code to executable code.


Figure 6.2  ActiveX components can be deployed on many platforms

Thus a client on a Windows platforms should be able to invoke ActiveX components on a Solaris platform, for example, or a Digital Unix platform. Similarly, a client using a web browser should be able to download ActiveX components for use on a Windows machine.

The ideal, of course, would be a “Java” type model whereby the developer wrote the code once and then could deploy it on any platform with no changes, but there are four main blocks to the complete portability of ActiveX components at the moment:

  Win32 APIs
  Compilers and language differences
  Underlying thread support
  Memory management

Win32 APIs - Where an ActiveX component uses the Windows GUI, clearly other platforms such as the OpenVMS or Digital Unix platform do not—they use the Motif GUL. Where an ActiveX component needs to be run on Unix platforms there thus needs to be some form of translation software which takes the Windows calls and either turns them into native Motif calls or alternatively emulation of the Windows GUI on other platforms.

The approach taken has been the latter with emphasis placed upon the same look and feel for the user (the Windows look and feel) on all supported platforms. In order to achieve this commonality of user interface, the Win32 API is being ported to other platforms. By the time you read this it could be complete with companies such as MainSoft and Bristol working on the ports.

Software AG and MainSoft formed a partnership to trade technologies in December 1996. Digital, on the other hand, is working closely with Bristol to port the Win32 API onto their platforms.

Compilers-ActiveX source code needs to be compiled for the platform on which it is to be deployed using the native compiler of that platform. Clearly, this does not stop any ActiveX component developer distributing binary executables to potential end users, but it does mean he will have to send out versions of the component for each platform.

It also means that to get each ActiveX component to work on each platform, some changes may have to be made to the source code before it is compiled. As we all know, compilers are different and versions of the languages—even so-called standard languages are also different—so a developer needs to ensure that that version of the ActiveX source code—destined for a particular platform—will actually work on that platform.

Even this hurdle may start to become less of a sticking point as companies start to provide direct support for Microsoft’s languages of development. Digital, for example, is currently working on providing native Digital Unix compiler support for both Microsoft C and Microsoft C++.

In the future, ActiveX components written in Visual Basic may be totally portable, as Microsoft is toying with the idea of developing a Visual Basic Virtual machine.


Previous Table of Contents Next