Phew, it’s been a long road to getting this version of West Wind Web Connection for Visual FoxPro out the door. Features and functionality had been done for weeks, but I’ve been putting off the last bit which is a huge bear – building the setups and distribution pieces.

 

The reason for this is that Web Connection now supports 4 versions of Visual FoxPro and in this version I actually went all out to make sure that most of the functionality works in all 4 of them. As you can imagine that’s a lot of testing. I must have done over 100 installs over last 4 days or so, wiping out Web sites and re-creating and testing etc.

 

To work with these 4 different versions Web Connection actually ships with 4 sets of binaries for the management console and 4 more for the compiled framework for the shareware version. Just keeping the filenames straight and running the right version of VFP is a chore all by itself <g>… I had previously experimented with just using one set of binaries and shipping runtimes, but this turns out to be non-workable because some of this stuff needs to run inside of Visual FoxPro. There’s lots of bracketed code inside of WWWC and most of it using #define conditionals which require recompiles.

 

As you can imagine this is messy as hell and I think this version is likely the last one where I will ship this much stuff. I’m hoping to move on to the next major release (5.0) which I’m reducing down to VFP 8 and later. VFP 9 and 8 are not that different but there are too many important features added with 8.0 that have made it increasingly more difficult to keep coding to keep code compatible with 6.0.

 

Even with all that, there is a bit of  stuff that doesn’t work with 6.0 and some that doesn’t work with 7.0, and almost everything (short of the new Unicode wwADOSQL stuff) works with 8.0. With 6.0 people will see some errors in the various demos for stuff that doesn’t work. <shrug>

 

So here I am bleary eyed but somewhat relieved. I think WWWC 4.65 has a ton of cool feature enhancements most of them user requested. A lot of effort has actually gone into beefing up the Apache support in Web Connection and I’ve created a custom Apache Module and made a number of changes to the Web Connection ISAPI handler to deal with some of Apache’s oddities. In the process there have been some nice additions to the ISAPI DLL’s header management which now automatically injects content size and a number of other headers that IIS automatically inserts on certain commands. The end result is that we now get more compliant HTTP headers that are actually checked and possibly fixed up by IIS. This may sound heavy handed but this is actually how ASP and ASP. Net do this as well, so this is standard fare for IIS. Incidentally, IIS allows bypassing this mechanism while Apache requires this (calling of ServerSupportFunction for headers).

 

I’ve also spent quite a bit of time cleaning up some of the PDF generation routines in Web Connection. Web Connection can work with a number of PDF generation tools include Acrobat, AmyUni and ActivePDF. I’ve now added support for GhostScript and the wonderful XFRX tool from Eqeus. Both of these are significant IMHO. GhostScript is nice because it is free and compared to Distiller quite quick at converting PostScript to PDF (like Distiller this mechanism prints to file using a PostScript printer and then converts the file to PDF). XFRX is perfect if you are dealing with FoxPro reports. The cool thing about it is that it doesn’t use the printer at all so there are no Pinter Spooler access issues which requires elevated rights and is a scalability issue because the Printer Spooler allows only one print job at a time. You can work around this with configuration, but it’s not obvious and has to be configured. Finally XFRX is self-contained – you just add an APP file and a couple of DLLs and there’s nothing else to install.  Very cool – the one downside is that it’s focused purely on VFP reports…

 

Also new is TransmitFile () functionality which is also significant. Web Connection MVP Randy Pearson actually brought this up in passing and I added support for this new feature to work around the problem. Web Connection in COM mode batches all output and sends this output back as a string. Because it’s a VFP application it’s limited to 16 megs per variable, which seems like a huge amount, but in some applications this is not enough. In reality the limits would likely be reached quite a bit sooner as string concatenation might actually have more than one copy of the string in memory. Natively there’s no way around this…

 

What TransmitFile() does is allow Web Connection to send a file pointer rather than the actual file. It’s a special directive in the output that points the ISAPI DLL at a file to read and write out to the client. This is much more efficient because now the ISAPI extension is doing all the work of reading and writing the file which is much more efficient. Further there are no large memory buffers used at all – you can output your content directly using a wwResponseFile object in small chunks and then simply close the file. The ISAPI extension simply opens the file and reads small chunks of and writes it back to the client. This is a huge bonus compared to returning large output in string format, which must pass over COM boundaries, be converted etc. Not a very obvious feature, but it’s very useful in many situations and always when you’re sending output back from a file on disk!

 

The other thing I did is do a bunch of cleanup with the installer and configuration managers. Web Connection now includes built in support for end to end IIS Web site configuration through internal tools both through the Web Connection Management Console and through code. All the features used in the Console are exposed through classes and methods in the framework, which is very useful for building your own custom installers or for configuring Web sites in general.

 

With Web Connection you can now do the following both interactively and programmatically:

 

  • Create Virtual Directories
  • Create Scriptmaps
  • Automatically create IIS 6 Application Pools
  • Add scripts to the IIS 6 Web Service Extensions List
  • Set ACL Permissions
  • Set DCOM Persmissions
  • Create printer drivers (for PostScript output with GhostScript/Distiller)

 

All of this stuff has been available for a few versions actually, but it hadn’t been documented and not very well integrated into the various installers and configuration tools. All of this stuff above now happens automatically when you setup Web Connection, Create a new project or run the Server Configuration Wizard! I can tell you it’s made my life a lot easier – I just reinstalled my machine with a new hard disk and these tools made short work of hooking every app back up in a few minutes!

 

There’ve been many subtle enhancements in the installers and Wizards. For example, the installer checks to see if  GhostScript or Distiller is installed, and if they are asks if you want to install a PostScript driver to use the PDF classes. The Apache automatically checks for the installed default document and updates its default page names to match in the virtuals – little stuff like that.

 

All of this hopefully translates into a smoother installation process.

 

But man this is hard work and not very exciting work either. The new features were fun to do – the last four days have been pure hell <g>.

 

Hopefully this has paid off with a stable release. Let me hear about it if you have any problems with anything.