Chapters 26, 27, and 28 cover building Netscape Navigator plug-ins with the Borland, Microsoft, and Watcom C++ compilers. As with the rest of this book's samples, all plug-ins are targeted for Windows 95/NT.
For these examples, source code is used from the previous plug-in samples, which means that there is no source code on the CD-ROM for the Borland or Watcom environments. If you are a Borland or Watcom developer, don't worry. The next chapters give very detailed instructions on building a plug-in with these environments using Microsoft source code as a base.
A few anomalies are involved when writing plug-ins using different development environments. Resources, routine exporting, function declarations, and calling conventions can give a plug-in developer premature gray hair.
As you probably already know, Navigator looks for the MIMEType, FileExtents, and FileOpenName resources in your plug-in. These resource values are defined with a version block in the .rc file.
Borland and Microsoft enable you to create a version resource with their respective resource editors. In Chapters 26, 27, and 28, you'll see how to do this. With Microsoft, the version block header must be changed to Windows Multilingual. Borland defaults to this.
Watcom's resource editor cannot create a version resource. However, its resource compiler can compile one. Just copy one of the .rc files from the CD-ROM for use with Watcom.
Calling conventions tend to change for different compilers. Stack argument order and register versus stack calling must be properly defined for each compiler. Because the plug-in API bypasses standard Windows DLL calling conventions in the interest of cross-platform support, special attention must be paid to calling conventions for each compiler. Additionally, changes need to be made to the Windows DLL calling conventions in order for the Borland and Watcom compilers to work properly.
If you remember from Chapter 8, API mapping was discussed. API mapping hides the Windows plug-in DLL interface from Netscape's Navigator, making both the Navigator and plug-in code portable across the Macintosh, UNIX, and Windows platforms. Navigator gets pointers to NPP type plug-in methods and gives the plug-ins pointers to NPN type methods. After this is done, the Navigator and plug-in call each other directly through the use of these function pointers.
All of this works great until you try to use a compiler with the wrong default calling convention, which results in a serious trap! Navigator calls your plug-in methods using the _cdecl calling convention. This convention is used by the Microsoft compiler in which Netscape's Navigator was written. The _cdecl calling convention passes arguments on the stack from right to left, with the last argument pushed first. Some compilers use a register-based calling convention as the default. Passing function parameters through registers is faster than using the stack.
If you have a compiler that uses a register-based calling convention (most notably, the Watcom compiler), you can either define all the plug-in methods as _cdecl or simply change the compiler switches to use a stack-based convention as default.
Another difference that you should be aware of is the calling convention for your plug-in's DLL entry points. For example, in Windows 95 the DLL entry points are defined as WINAPI. This boils down to _stdcall. In _stdcall, arguments are pushed from right to left, with the last argument first, such as _cdecl. This is very different from Windows 3.1 DLLs, which use the _pascal convention. In _pascal, arguments are pushed on the stack in reverse order, with the first argument pushed first.
With the Microsoft compiler, it is enough to declare the DLL entry points as external C in the header. The Watcom and Borland compilers need an additional extern "C" before the actual routine.
Both Borland and Microsoft use a module definition, or .DEF, file to export the DLL routines. Watcom has something called a librarian command file that is similar to a .DEF file. Creating this file is covered in detail in Chapter 28, "Writing a Plug-In with Watcom C++ 10.x."
Both Microsoft and Watcom come with the Microsoft Foundation Class Library (MFC). Borland ships with the Object Windows Library (OWL). Although the Microsoft example uses a class library, the Watcom and Borland examples do not. Adding class library support to Borland and Watcom is left to the reader as an exercise, because it is beyond the scope of this book.
With a few tweaks, the Borland and Watcom C++ compilers are acceptable alternatives for Netscape Navigator plug-in development. If your Borland or Watcom plug-in produces either compile or runtime errors, be sure to check your resources and calling conventions.
Read on to learn how to build a plug-in from scratch with the Borland, Microsoft, and Watcom compilers. The next three chapters include plenty of screen shots taken with Borland C++ 5.0, Microsoft Visual C++ 4.0, and Watcom C/C++ 10.6.