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:
- 1. We support cross-compile using mingw
- 2. Our design is mainly for UNIX
- 3. we try to support everything from windows 95
- 4. we try to follow the rule of the least surpries
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:
- a dll can't have unresolved symbols after compiling
- a dll tries to load all the other dlls it was compiled against (and we need to compile against other dlls because the previous point)
- we don't have an elegant way to tell windows where to look for those dlls (see next point)
- we can't tell windows to link against dlls with full pahts (see next point)
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.