> -----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.

Tue, 4 Jun 2002 22:02:14 -0700
"Dann Corbit" <DCorbit@connx.com>
Re: Roadmap for a Win32 port
Dan,

The following is to help keep the archives accurate and should not be
construed as an argument against the native Win32 port.

On Tue, Jun 04, 2002 at 10:02:14PM -0700, Dann Corbit wrote:
> And Cygwin requires a license for commercial use.
> http://cygwin.com/licensing.html

The above is not necessarily true:

    Red Hat sells a special Cygwin License for customers who are unable
    to provide their application in open source code form.

Note that the above only comes into play if your application links
with the Cygwin DLL.  This is easily avoidable by using JDBC, ODBC,
Win32 libpq, etc.  Hence, most people will not be required to purchase
this license from Red Hat.

Jason

Wed, 05 Jun 2002 08:07:06 -0400
Jason Tishler <jason@tishler.net>
Re: Roadmap for a Win32 port
Jason Tishler wrote:
> Dan,
> 
> The following is to help keep the archives accurate and should not be
> construed as an argument against the native Win32 port.
> 
> On Tue, Jun 04, 2002 at 10:02:14PM -0700, Dann Corbit wrote:
> > And Cygwin requires a license for commercial use.
> > http://cygwin.com/licensing.html
> 
> The above is not necessarily true:
> 
>     Red Hat sells a special Cygwin License for customers who are unable
>     to provide their application in open source code form.
> 
> Note that the above only comes into play if your application links
> with the Cygwin DLL.  This is easily avoidable by using JDBC, ODBC,
> Win32 libpq, etc.  Hence, most people will not be required to purchase
> this license from Red Hat.

So apps written using client libraries are BSD, while server-side
changes would have to release source.  Makes sense, though we have never
had this distinction before.  I assume plpgsql stored procedures would
have be open source, but of course those are stored in plaintext on the
server so that isn't a problem.  If companies created custom C stored
procedures, those would have to be open source if using cygwin.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 5 Jun 2002 11:17:09 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Roadmap for a Win32 port