Re: Roadmap for a Win32 port - Mailing list pgsql-hackers

> -----Original Message-----
> From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> Sent: Tuesday, June 04, 2002 9:34 PM
> To: PostgreSQL-development
> Subject: [HACKERS] Roadmap for a Win32 port
>
>
> OK, I think I am now caught up on the Win32/cygwin
> discussion, and would
> like to make some remarks.
>
> First, are we doing enough to support the Win32 platform?  I think the
> answer is clearly "no".  There are 3-5 groups/companies
> working on Win32
> ports of PostgreSQL.  We always said there would not be
> PostgreSQL forks
> if we were doing our job to meet user needs.  Well,
> obviously, a number
> of groups see a need for a better Win32 port and we aren't
> meeting that
> need, so they are.  I believe this is one of the few cases
> where groups
> are going out on their own because we are falling behind.
>
> So, there is no question in my mind we need to do more to encourage
> Win32 ports.  Now, on to the details.
>
> INSTALLER
> ---------
>
> We clearly need an installer that is zero-hassle for users.
> We need to
> decide on a direction for this.
>
> GUI
> ---
>
> We need a slick GUI.  pgadmin2 seems to be everyone's favorite, with
> pgaccess on Win32 also an option.  What else do we need here?

Nothing else.  It is better than any commercial tools in current use.
An excellent piece of work.
> BINARY
> ------
>
> This is the big daddy.   It is broken down into several sections:
>
> FORK()
>
> How do we handle fork()?  Do we use the cygwin method that copies the
> whole data segment, or put the global data in shared memory and copy
> that small part manually after we create a new process?

Do not try to do a fork() on Win32.  The one at PW32 is better, but
still awful.  Win32 just does not have fascilities for fork().

If you use Cygwin, it will kill the project for commercial use (at least
for many institutions).  That's fine, but it will become an academic
exercise instead of a viable commercial tool.  If they are comfortable
in that [Cygwin] environment, it makes no sense to use Cygwin instead of
Redhat.  The Redhat version will fork() 100 times faster.  After all, if
they are going to use unix tools in a unix interface with Unix scripts
you might as well use UNIX.  And Cygwin requires a license for
commercial use.
http://cygwin.com/licensing.html
> THREADING
>
> Related to fork(), do we implement an optionally threaded postmaster,
> which eliminates CreateProcess() entirely?  I don't think we will have
> superior performance on Win32 without it.  (This would greatly help
> Solaris as well.)

CreateProcess() works well for Win32.  That is the approach that we used
and also the approach used by the Japanese team.
It is very simple.  Simply do a create process call and then perform the
same operations that were done up to that point.  It isn't difficult.
Threading is another possibility.  I think create process is better,
because you can clone the rights of the one who attaches for the spawned
server (if you want to do that).

>
> IPC
>
> We can use Cygwin, MinGW, Apache, or our own code for this. Are there
> other options?

We wrote our own from scratch.  Cygwin will kill it.  If there is a
MinGW version it might be OK, but if MinGW is GPL, that will kill it.
Have a look at ACE:
http://www.cs.wustl.edu/~schmidt/ACE.html
Their license is on the same level as a BSD license.  Now, they use C++,
but you can always write:
extern "C" {
}
wrappers for stuff and keep PostgreSQL itself in pure, vanilla C.  GCC
does come with a C++ compiler, so it isn't going to cut anyone off.
> ENVIRONMENT
>
> Lots of our code requires a Unix shell and utilities.  Will
> we continue
> using cygwin for this?

We wrote our own utilities from scratch (e.g. initdb).  The Japanese
group that did the port did the same thing.
> --------------------------------------------------------------
> -------------
>
> As a roadmap, it would be good to get consensus on as many of these
> items as possible so people can start working in these areas.  We can
> keep a web page of decisions we have made to help rally developers to
> the project.

If you want a roadmap, the Japanese group laid it out for you.   They
did the exact same steps as we did.  Now, I don't know if we will be
able to contribute or not (it is very much up in the air).  And we had
to do a lot of hacking of the source, so you might not want it if we
volunteered.

Suggestion:
Ask the Japanese group if they would like to post their changes back or
expose them so that the programming team can get ideas form it.

I actually like what they did better than what we did (A giant DLL and
all the binaries are microscopic -- it was how I suggested to do it here
but it was vetoed).

Anyway, here is a roadmap laid out for you exactly.  Just do what it
says and you will be fine:
http://hp.vector.co.jp/authors/VA023283/PostgreSQLe.html

Look at where it says "Gists for patch" and do that.