Native Win32, How about this? - Mailing list pgsql-hackers

A binary version of PostgreSQL for Windows should not use the cygwin dll. I
know and understand there is some disagreement with this position, but in this
I'm sure about this.

The tools used to create the binary need not be Microsoft, many venders have
used Borland or Watcom, the run of the mill user/developer does not care. The
developers who do care won't mind the cygwin development environment as long as
it produces a native Windows binary that does not play tricks such as fork().

Windows developers don't care too much about source code. The build environment
will not be a problem.

The issue is that the system must perform well and must be stable. I do not
believe that cygwin can meet this requirement. Having done some research for
these discussions, I think we know it has startup performance issues and
unknown operational issues.

FYI: My PHP project msession, can produce both a Windows version and a Cygwin
version. It is threaded C++, but I have measured a performance improvements
using the native Windows version over the cygwin version. I have since
abandoned the cygwin version.

I believe we can use the cygwin development environment, and direct gcc not to
link with the cygwin dll. Last time I looked it was a command line option. This
will produce a native windows application. No emulation, just a standard C
runtime.

Some of the hits will be file path manipulation, '/' vs '\', the notion of
drive letters, and case insensitivity in file names. 

Unicode may be an issue, I haven't looked at that yet. Is that a must for the
initial release?

There will be a need for some emulation/api specification of things like
semaphores, shared memory, file API (I would like to use Windows native
CreateFile routines, as these should be pretty fast.), and so on.

We will also have to breakup postgres and postmaster, and for the Windows
version use CreateProcess. There are a number of ways to attack this, globals
in a structure based in shared memory, globals in a .DLL exported to processes
and shared, and so on.

I think a huge time savings can be had by avoiding rewriting everything for the
Microsoft build environment. As far as I know, and please correct me if I'm
wrong, code produced by the cygwin gcc is freely distributable and need not be
GPL.

Once we have it working without fork() using the cygwin build environment, we
will have a native Windows application, we can then further evaluate whether or
not we want to expend the work to make a MSC version. 

Once the backend and most of the tools are built without requiring the
cygwin.dll, installation is a breeze. Just dump it somewhere and run it.

A couple simple programs can be written using msvc to monitor, start and stop
PostgreSQL. The programs will be simple using the application wizard, just make
a small dialog box application.

Pgaccess will provide all the GUI stuff, and we may even be able to wrap the
monitor code into pgaccess.

The server install can be done with install shield.

There is code that will run any program as an NT service. We can use that for
server installations. We can use the MSVC wizard application to pop-up in the
tool bar.

Have I missed anything?
Is this a realistic and attainable plan?