GPMI - windows support

0. Introduction

We provide a windows port of gpmi, however we (the core developers) do not use or own windows. Thus, the following conditions need to be considered: The rest of this document will discuss details about the above points.

1. Cross-compile only

We do not support compiling with native windows compilers (msvc for example) because we don't have and don't want to have proprietary softwares, this way we can not develope on them.

We provide support for corss-compiling from under UNIX systems using mingw. This means if you want to compile applications, extensions packages or modules, you need to have a UNIX shell and mingw installed.

We regurally compile win32 executables and release them. For those who do not have UNIX access, this is the preferred way to get gpmi.

This also means "make test" or "make install" makes no sense for windows target.

2. Designed for UNIX

We mainly design gpmi for UNIX. We don't change our design to give up features on unix to make the lib more portable to other systems but rather we provide alternative or more native solutions for those systems.

Unfortunately dlls are not as powerful as .so files on UNIX. The main problems are these:

Because those problems above, and because the 4th principle, we decided to have one directory that holds all the dll files and instead of packages/group/subgroup/name.dll, we refer them as packages\group_subgroup_name.dll in any depth.

However, we still use the .dep files so packages can kick in.

3. everything from 95

While coding the windows port, we often found windows API calls that could be used to have a better solution. However, many calls were limited to a specific group of windows versions, usually up from XP, but sometimes even only for versions above XP.

We did not use those calls. Instead, we used safer calls that exist on all other versions as well, from 95. This makes the code less elegant at many places. For example we could have asked the dynamic loader not to load the dependent dlls automaticly (so .dep processing would have loaded those) or we could set up dll search paths instead of changing the current directory for loading the dll.

4. the rule of the least surpries

We believe that storing the libraries in a nice directory tree is a better solution that having them in one single directory; we believe registry in windows usually goes wrong; we believe a dynamic lib should compile with unresolved symbols.

However we follow the rule of the least suprise, so the windows port is "windowsish": we accept that collecting many dlls in a single directory or storing arbitary information in the registry are expected, or at least not too surprising on windows. This allows us to implement these special, windows-only alternatives in gpmi.