Win32 Technical Questions

Peter Eisentraut wrote:

I have prepared a little patch that makes room for a native Windows build
in our existing build framework. The Cygwin port would be renamed to
"cygwin" and the new port takes over the "win" name. I have prepared the
port specific template and makefile and extracted the dynaloader from your
patch, so that you can at least run configure under Cygwin or MinGW
successfully.

<kew>Great! Configuration was sorely needed.

Then I suggest we merge in the obvious parts of your patch, especially the
renaming of various token constants, the shmem implementation, some
library function reimplementations. In some cases I would like a bit more
abstraction so that we don't have so many #ifdef's. (For example, we
could have a IsAbsolutePath() that works magically for all platforms.)

<kew>I agree -- good first step.

Then there are the hairy pieces. You add a bunch of command-line options
that interact in puzzling way to communicate information about the fake
fork. I think some of these are redundant, but it's hard to tell.

<kew>I don't remember why all of the options were needed. Some of them
might be more historical than others. The good news is that the fork/exec
stuff can be compiled and tested on Linux. Just run with -x on the command
line.

The reimplementation of various shell scripts in C is something that would
be a good idea on Unix as well for a number of reasons. Unfortunately,
the ones you wrote have no chance of compiling under Unix, so we'll have
to do it again. But that can happen in parallel to the other stuff.

<kew>The ones I wrote should be portable to *nix (by replacing CopyFile,
etc). However, I've heard others talk about it being a good idea to
re-write the scripts in c to use libpq directly. Mine mimic the shell
scripts without attempting to improve on the functionality.

Two quick questions: Why PG_WIN32 and not just WIN32?

<kew>To differentiate from the #ifdef WIN32's that were already in the code
(psql is an example). I didn't want to break existing code in any way by
adding my stuff.

Can the ConsoleApp thing be written in C so we don't have to get an
extra C++ compiler for one file (for those who don't want to use the
Microsoft toolchain)?

<kew>
ConsoleApp is written in C++ for two reasons:
1) By instantiating a class inheriting from CWinApp, we get a lot of
initialization for free. This is especially important when the windows are
created. (The window is so we have a target to which messages (i.e.
signals) are sent intra- and inter-process.)

2) Critical Sections (mutex's in the *nix world). By implementing the use
of critical sections within the constructor/destructor of a stack variable,
I am ensuring that there is no way to exit a scope without unlocking what
was locked. This includes sigjmp, breaks, and early returns. Without this,
the chances are pretty good that the proceess will hang on an error because
something will stay locked when it shouldn't.

Hope this answers your questions,
Katie