As of the 2.10.0 version of mod_owa, I will no longer support some older Apache or OCI versions, and will no longer provide builds for older versions of Windows. Please read this notice carefully.
I'm removing the source code that supports the older UPI stack. This stack was never exposed to customers anyway, so only I am able to build executables with that code path. This code was useful many years ago when some users were still running Oracle 7 client stacks. The code was developed to run on OCI8, which became available in Oracle 8.0 and is a customer interface supported by Oracle. Going forward, this will be the only code path in mod_owa.
I'm removing the source code that supports the original Oracle 8.0 version of OCI. You'll need an 8.1 or higher OCI to build or run the module. There is only one difference, which is that after 8.0 Oracle corrected a problem with the initialization of the OCI, wherein clients were required to call OCIInitialize exactly once before any other OCI code. In newer versions, OCIEnvCreate handles this. I've not produced an older binary in over a decade, so my belief is that no users are still depending on this (but, since the module is open-source, someone might still be building them him/herself).
In the future, I may drop support for OCI libraries earlier than 10.x. The reason is that the 9.x and earlier libraries did not have LOB interfaces capable of handling LOBs larger than 2 Gbytes.
mod_owa was originally written for Apache 1.3, then ported to Apache 2.0 and 2.x versions. I used difficult-to-read macros to support all these Apaches from a single source code base. As of 2.10.0 I will be dropping the 1.3 variant of the source code, meaning it will no longer be possible to produce a 1.3 compatible build from newer source versions.
At this point, I believe I'm wasting my time producing binaries for them. Apache doesn't even make all of these available on their site anymore. It's also becoming a hassle to keep versions of Apache 1.3 around to build against. I will no longer produce these binaries, and as noted above it won't even be possible to produce a 1.3 version.
I may also stop providing binaries for Apache 2.0, though I will retain the hooks in the code supporting that version. That version isn't quite compatible with 2.2 and 2.4, and is quite old. 64-bit Windows binaries aren't available anymore to build against. 2.0 will still be supported by the code; users who need a 2.0 version will still be able to build their own versions from the source code.
I haven't produce 32-bit Linux binaries of mod_owa in some years now. For reasons explained below, I have been limited to producing 32-bit binaries on Windows. However, I will no longer produce 32-bit binaries for Windows, and will move to 64-bit builds concurrent with the move to a newer Windows build environment.
This doesn't mean 32-bit operation won't be supported; it should still be possible to build 32-bit binaries for any platform from the source code.
In theory, mod_owa on Windows is the same as on Linux - users can download the source and build a version that meets their needs on almost any version of Windows, for any version of Apache, any version of Oracle past 8.0, and in either 32-bit or 64-bit mode. In practice, I've found that most people who are running Windows lack the ability to build mod_owa from source code, and need to use the binaries I produce.
As of the 2.10.0 version, I will be moving my Windows build environment to the Vista SDK, the oldest SDK I can readily find on Microsoft's web site. This means I'll finally be able to produce 64-bit binaries for Windows. However, it also means the binaries won't work on older versions of the Windows operating system (see the table below).
As background, I have for years produced Windows binaries using an ancient version of the Visual C++ compiler, version 6.0, which appears to be the last stand-alone C compiler Microsoft produced. I've done this because some years ago I attempted to move up to Visual Studio 2003, and immediately got emails from users who reported that the resulting binaries won't work on their systems. The unfortunate symptom is that Apache just won't start if there are unsatisfied dependencies or other issues with a DLL that it can't load - there is no helpful error message to explain what was wrong. I quickly went back to VC 6.0, and I've been using it ever since, despite limitations such as the inability to produce a 64-bit executable.
I've since learned that the incompatibility is due to a number of factors:
The OS version number issue is the most annoying, because the error messages simply confuse users. It appears that the linker will write a version number that depends on the version of Visual Studio used to build the executable, the version of the so-called platform SDK used during the build, and to some extent link-time flags. This is really nothing more than a nuisance for a command-line program or pluggable DLL such as mod_owa. You can see what version numbers are baked into an executable, including a DLL, using Microsoft's DUMPBIN utility.
The C runtime library dependency is more troubling, and seems impossible to work around. mod_owa carefully avoids using any calls to functions from the C runtime library on Windows, because when I originally wrote it I feared exactly this sort of issue. Unfortunately, the compiler appears to bake in some dependencies anyway. Even using my very old VC 6.0 I see a handful of dependenices, despite strict use of WIN32 APIs on the Windows build. (You can also see these using DUMPBIN.)
The following table is my best understanding of the internal version number for Windows OSes back to Win95:
OS Name Internal Version Number Windows 95 4.0 Windows NT 4.0 4.0 Windows 98 4.1 Windows Me 4.9 Windows 2000 5.0 Windows XP 5.1 Windows XP 64-bit 5.2 Windows Server 2003 5.2 Windows Server 2003 R2 5.2 Windows Vista 6.0 Windows Server 2008 6.0 Windows Server 2008 R2 6.1 Windows 7 6.1 Windows 8 6.2 Windows Server 2012 6.2
Reluctantly, I've concluded that different releases of the compiler produce binaries that require different levels of the Microsoft OS. My ancient copy of Visual C++ 6.0 will produce binaries going back to Windows 95. However:
Windows XP appears to be the last version of Windows where VC 6.0 will install cleanly. Microsoft is desupporting XP at the end of 2013. Moreover, I really can't install XP on newer hardware. I've considered running a VM just to install XP, but the fact that it's being desupported would still be an issue. For now, I've installed VC 6.0 (with errors) on Windows 7, and it appears to work from the command line. It continues to produce 32-bit executables compatible with all older releases of Windows back to version 4.0.
Now that I understand what the nature of the compatibility issue is, and how to diagnose it, it's time to move forward. Microsoft has stopped making versions of Visual Studio and the Platform SDKs available for the oldest platforms. So, unfortunately, I can't find a build environment that supports version 5.x (i.e. XP and Windows Server 2003). The oldest SDK I've found is for Vista. This works fine and produces 64-bit executables, but I believe this will require users to be running a minimum OS level equivalent to 6.0 (i.e. Vista or Windows Server 2008).
To save myself time and trouble, I won't bother building 32-bit versions of the module anymore, even with the Vista SDK.
I can't find a 64-bit version of Apache 2.0 for Windows, so I'm unable to produce a binary for Apache 2.0. I have no reason to think it won't work though - the 32-bit build (of mod_owa 2.9.7) worked fine.
My ancient VC 6.0 setup still works, so I'm still able to produce 32-bit builds if necessary. If you absolutely have to have a 32-bit build, or need something that runs on an older OS such as XP, you can contact me and at my discretion I may try to produce a build that will work for you.