Re: Win32 port

Started by Hannu Krosingover 23 years ago34 messageshackers
Jump to latest
#1Hannu Krosing
hannu@tm.ee

Bruce Momjian kirjutas K, 06.11.2002 kell 08:19:

I have copies of Peer Direct's (Jan's company) port of PostgreSQL to
Win32, and SRA's port to Win32, and permission to generate a merged
patch that can be applied to 7.4.

Great!

Now that 7.3 is almost complete, I am going to start work on that. I
will post patches that deal with specific portability issues, like
fork/exec and path separator handling, and once reviewed, apply them to
the main CVS tree for 7.4.

What C compiler will you be working with ?

I hope that at least MingW should be supported ?

-------------
Hannu

#2Bruce Momjian
bruce@momjian.us
In reply to: Hannu Krosing (#1)

Hannu Krosing wrote:

Bruce Momjian kirjutas K, 06.11.2002 kell 08:19:

I have copies of Peer Direct's (Jan's company) port of PostgreSQL to
Win32, and SRA's port to Win32, and permission to generate a merged
patch that can be applied to 7.4.

Great!

Now that 7.3 is almost complete, I am going to start work on that. I
will post patches that deal with specific portability issues, like
fork/exec and path separator handling, and once reviewed, apply them to
the main CVS tree for 7.4.

What C compiler will you be working with ?

I hope that at least MingW should be supported ?

Actually, I will be doing all the coding on BSD/OS. I am more merging
patches than actual coding, though. This will guarantee that the
patches will not affect the Unix platforms. I will need help from
others to check the various Win32 compilers.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#3Jan Wieck
JanWieck@Yahoo.com
In reply to: Bruce Momjian (#2)

Bruce Momjian wrote:

Hannu Krosing wrote:

Bruce Momjian kirjutas K, 06.11.2002 kell 08:19:

I have copies of Peer Direct's (Jan's company) port of PostgreSQL to
Win32, and SRA's port to Win32, and permission to generate a merged
patch that can be applied to 7.4.

Great!

Now that 7.3 is almost complete, I am going to start work on that. I
will post patches that deal with specific portability issues, like
fork/exec and path separator handling, and once reviewed, apply them to
the main CVS tree for 7.4.

What C compiler will you be working with ?

I hope that at least MingW should be supported ?

Actually, I will be doing all the coding on BSD/OS. I am more merging
patches than actual coding, though. This will guarantee that the
patches will not affect the Unix platforms. I will need help from
others to check the various Win32 compilers.

I was wondering about that. How will you be able to verify that you got
a Win32 port that at least compiles, if you're merging two different
Win32 approaches into the code on BSD? I don't expect that to work at
all.

To Hannu: the Windows port we did here depends on MS VC++ features like
the ability to specify in the project to substitute header files. I
don't know much about MingW and if you can do things like that with it.
Our port is a real 100% pure Win32 one without any portability crap like
cygwin. I don't think that's a big problem, since the binary results of
a MS VC compile are redistributable AFAIK. And you'd need VC++ only if
you want to do backend development under Windows, and who want's that
(Katie for sure, but that's another story ;-P )

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

#4Bruce Momjian
bruce@momjian.us
In reply to: Jan Wieck (#3)

Jan Wieck wrote:

Actually, I will be doing all the coding on BSD/OS. I am more merging
patches than actual coding, though. This will guarantee that the
patches will not affect the Unix platforms. I will need help from
others to check the various Win32 compilers.

I was wondering about that. How will you be able to verify that you got
a Win32 port that at least compiles, if you're merging two different
Win32 approaches into the code on BSD? I don't expect that to work at
all.

It doesn't have to work on Win32 day 1. I will do all the work I can.
I will also be buying a machine that can compile this but right now I
want to get most of it in.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#5Joe Conway
mail@joeconway.com
In reply to: Bruce Momjian (#4)

Bruce Momjian wrote:

Jan Wieck wrote:

Actually, I will be doing all the coding on BSD/OS. I am more merging
patches than actual coding, though. This will guarantee that the
patches will not affect the Unix platforms. I will need help from
others to check the various Win32 compilers.

I was wondering about that. How will you be able to verify that you got
a Win32 port that at least compiles, if you're merging two different
Win32 approaches into the code on BSD? I don't expect that to work at
all.

It doesn't have to work on Win32 day 1. I will do all the work I can.
I will also be buying a machine that can compile this but right now I
want to get most of it in.

Bruce, I can compile on VC++ (VS .Net) for you. Let me know when you're ready
with a patch.

Joe

#6Bruce Momjian
bruce@momjian.us
In reply to: Joe Conway (#5)

Joe Conway wrote:

Bruce Momjian wrote:

Jan Wieck wrote:

Actually, I will be doing all the coding on BSD/OS. I am more merging
patches than actual coding, though. This will guarantee that the
patches will not affect the Unix platforms. I will need help from
others to check the various Win32 compilers.

I was wondering about that. How will you be able to verify that you got
a Win32 port that at least compiles, if you're merging two different
Win32 approaches into the code on BSD? I don't expect that to work at
all.

It doesn't have to work on Win32 day 1. I will do all the work I can.
I will also be buying a machine that can compile this but right now I
want to get most of it in.

Bruce, I can compile on VC++ (VS .Net) for you. Let me know when you're ready
with a patch.

Thanks. That will be a help. In fact, just running it through after I
make few commits should fix things up.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#7Peter Eisentraut
peter_e@gmx.net
In reply to: Jan Wieck (#3)

Jan Wieck writes:

To Hannu: the Windows port we did here depends on MS VC++ features like
the ability to specify in the project to substitute header files. I
don't know much about MingW and if you can do things like that with it.

Before long someone will port the Windows port to MinGW, so we should
resist attempts to use compiler-specific features in the same way that we
tend not to use vendors specific features in other ports.

--
Peter Eisentraut peter_e@gmx.net

#8Justin Clift
justin@postgresql.org
In reply to: Peter Eisentraut (#7)

Peter Eisentraut wrote:

Jan Wieck writes:

To Hannu: the Windows port we did here depends on MS VC++ features like
the ability to specify in the project to substitute header files. I
don't know much about MingW and if you can do things like that with it.

Before long someone will port the Windows port to MinGW, so we should
resist attempts to use compiler-specific features in the same way that we
tend not to use vendors specific features in other ports.

Absolutely. With the present push by over 30 governments of countries,
and other large institutions around the world for adopting Open Source
software in significant ways, we'd be kind of short-sighted to do things
in a way that mostly limits people to using M$ products.

:-)

Regards and best wishes,

Justin Clift

--
Peter Eisentraut peter_e@gmx.net

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

#9Dave Page
dpage@pgadmin.org
In reply to: Justin Clift (#8)

-----Original Message-----
From: Joe Conway [mailto:mail@joeconway.com]
Sent: 06 November 2002 16:16
To: Bruce Momjian
Cc: Jan Wieck; Hannu Krosing; PostgreSQL-development; Tatsuo Ishii
Subject: Re: [HACKERS] Win32 port

Bruce, I can compile on VC++ (VS .Net) for you. Let me know
when you're ready
with a patch.

Joe

I can also help with VC++ 6, and .NET.

Regards, Dave.

#10Bruce Momjian
bruce@momjian.us
In reply to: Peter Eisentraut (#7)

Peter Eisentraut wrote:

Jan Wieck writes:

To Hannu: the Windows port we did here depends on MS VC++ features like
the ability to specify in the project to substitute header files. I
don't know much about MingW and if you can do things like that with it.

Before long someone will port the Windows port to MinGW, so we should
resist attempts to use compiler-specific features in the same way that we
tend not to use vendors specific features in other ports.

Agreed. I will make as clean a patch as possible. I think it is
doable.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#11Bruce Momjian
bruce@momjian.us
In reply to: Jan Wieck (#3)

Here is a list of patch areas that I will address with the Win32 port:

fork/exec
loop rename test
handle \r in COPY
copydir for cp -r
backslash tests
rmdir not recursive for rm -r
shared memory could map to new address in exec child
compatibility defines
file path separators
root directory
rename atomicity
spinlock changes
str[r]chr
timeval for psql
DWORD in help.c
initdb

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#12Jan Wieck
JanWieck@Yahoo.com
In reply to: Bruce Momjian (#10)

Bruce Momjian wrote:

Peter Eisentraut wrote:

Jan Wieck writes:

To Hannu: the Windows port we did here depends on MS VC++ features like
the ability to specify in the project to substitute header files. I
don't know much about MingW and if you can do things like that with it.

Before long someone will port the Windows port to MinGW, so we should
resist attempts to use compiler-specific features in the same way that we
tend not to use vendors specific features in other ports.

Agreed. I will make as clean a patch as possible. I think it is
doable.

The thing with this particular feature was not to touch almost every
source file in the whole tree. The headers to #include in a clean Win32
world are totally different from what you #include in Unix.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

#13Jan Wieck
JanWieck@Yahoo.com
In reply to: Bruce Momjian (#11)

Bruce Momjian wrote:

Here is a list of patch areas that I will address with the Win32 port:

fork/exec
loop rename test
handle \r in COPY
copydir for cp -r
backslash tests
rmdir not recursive for rm -r
shared memory could map to new address in exec child

That's actually not done in the port yet. Thomas once overhauled the
hashtable code and changed it from using offsets to pointers. This code
is used for shared hashtables, so the mapping has to be done at a fixed
address for now.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

#14Bruce Momjian
bruce@momjian.us
In reply to: Jan Wieck (#13)

Jan Wieck wrote:

Bruce Momjian wrote:

Here is a list of patch areas that I will address with the Win32 port:

fork/exec
loop rename test
handle \r in COPY
copydir for cp -r
backslash tests
rmdir not recursive for rm -r
shared memory could map to new address in exec child

That's actually not done in the port yet. Thomas once overhauled the
hashtable code and changed it from using offsets to pointers. This code
is used for shared hashtables, so the mapping has to be done at a fixed
address for now.

OK, can we guarantee that fixed mapping will happen?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#15Bruce Momjian
bruce@momjian.us
In reply to: Jan Wieck (#12)

Jan Wieck wrote:

Bruce Momjian wrote:

Peter Eisentraut wrote:

Jan Wieck writes:

To Hannu: the Windows port we did here depends on MS VC++ features like
the ability to specify in the project to substitute header files. I
don't know much about MingW and if you can do things like that with it.

Before long someone will port the Windows port to MinGW, so we should
resist attempts to use compiler-specific features in the same way that we
tend not to use vendors specific features in other ports.

Agreed. I will make as clean a patch as possible. I think it is
doable.

The thing with this particular feature was not to touch almost every
source file in the whole tree. The headers to #include in a clean Win32
world are totally different from what you #include in Unix.

OK, I am looking at the SRA patch and I don't see a huge number of
#include changes. Can you give an example? Also, isn't there a way to
do this in a more centralized way, perhaps in c.h?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#16Bruce Momjian
bruce@momjian.us
In reply to: Bruce Momjian (#15)

Steve Howe wrote:

Hello Bruce,

Wednesday, November 6, 2002, 3:19:35 AM, you wrote:

BM> I have copies of Peer Direct's (Jan's company) port of PostgreSQL to
BM> Win32, and SRA's port to Win32, and permission to generate a merged
BM> patch that can be applied to 7.4.

BM> Now that 7.3 is almost complete, I am going to start work on that. I
BM> will post patches that deal with specific portability issues, like
BM> fork/exec and path separator handling, and once reviewed, apply them to
BM> the main CVS tree for 7.4.
Just wondering, what compiler are they using ?
Will it compile using Mingw ?

I think the two projects are using MS C++, but it would be nice for
Mingw to work too.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#17Steve Howe
howe@carcass.dhs.org
In reply to: Bruce Momjian (#16)

Hello Bruce,

Wednesday, November 6, 2002, 8:33:32 PM, you wrote:

BM> Steve Howe wrote:

Hello Bruce,

Wednesday, November 6, 2002, 3:19:35 AM, you wrote:

BM> I have copies of Peer Direct's (Jan's company) port of PostgreSQL to
BM> Win32, and SRA's port to Win32, and permission to generate a merged
BM> patch that can be applied to 7.4.

BM> Now that 7.3 is almost complete, I am going to start work on that. I
BM> will post patches that deal with specific portability issues, like
BM> fork/exec and path separator handling, and once reviewed, apply them to
BM> the main CVS tree for 7.4.
Just wondering, what compiler are they using ?
Will it compile using Mingw ?

BM> I think the two projects are using MS C++, but it would be nice for
BM> Mingw to work too.
Or even (free) Borland C++ compiler, but I would be glad just to see
it working with Mingw...
It just makes no sense a free project like
PostgreSQL to be compiled only with a commercial compiler.

-------------
Best regards,
Steve Howe mailto:howe@carcass.dhs.org

#18Bruce Momjian
bruce@momjian.us
In reply to: Steve Howe (#17)

pgman wrote:

I have copies of Peer Direct's (Jan's company) port of PostgreSQL to
Win32, and SRA's port to Win32, and permission to generate a merged
patch that can be applied to 7.4.

Now that 7.3 is almost complete, I am going to start work on that. I
will post patches that deal with specific portability issues, like
fork/exec and path separator handling, and once reviewed, apply them to
the main CVS tree for 7.4.

I have talked to Jan, and PeerDirect wants to submit a complete working
Win32 patch, rather than the piece-by-piece merged patch I was working
on. They also have a newer version than the one they shared with me.
They realize that their patch is very unlikely to be accepted in whole,
but rather merged in and reworked to fit into our code cleanly. They
also realize 7.4 will be a moving target as people make changes to CVS.

Part of my goal was to get this in quickly while CVS was relatively
stable, particularly hitting the portability issues that are spread
throughout the code, and dealing with sticky issues like rename().

I believe they are in their right to determine how the patch is released
to the community, so it seems we either have to wait for them to
complete their mega-patch, which could take one month or more, or start
working on a patch ourselves.

Let me map out the calendar. I think we are very close on the
point-in-time recovery patch. I am hoping to get that in during
November, and I _was_ hoping for the Win32 port too, so we could have
another two months of development, then start beta for 7.4. As it
stands now, we could be adding Win32 at the end of December, pushing
back 7.4.

Comments?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#19Alvaro Herrera
alvherre@dcc.uchile.cl
In reply to: Bruce Momjian (#18)

On Wed, Nov 06, 2002 at 08:20:16PM -0500, Bruce Momjian wrote:

Let me map out the calendar. I think we are very close on the
point-in-time recovery patch. I am hoping to get that in during
November, and I _was_ hoping for the Win32 port too, so we could have
another two months of development, then start beta for 7.4. As it
stands now, we could be adding Win32 at the end of December, pushing
back 7.4.

What about patches that are in the pgpatches2 list? Are you going to
merge that right now, or wait for each item to be reviewed?

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Pido que me den el Nobel por razones humanitarias" (Nicanor Parra)

#20Bruce Momjian
bruce@momjian.us
In reply to: Alvaro Herrera (#19)

Alvaro Herrera wrote:

On Wed, Nov 06, 2002 at 08:20:16PM -0500, Bruce Momjian wrote:

Let me map out the calendar. I think we are very close on the
point-in-time recovery patch. I am hoping to get that in during
November, and I _was_ hoping for the Win32 port too, so we could have
another two months of development, then start beta for 7.4. As it
stands now, we could be adding Win32 at the end of December, pushing
back 7.4.

What about patches that are in the pgpatches2 list? Are you going to
merge that right now, or wait for each item to be reviewed?

Good question. Let's say I will apply them in two days unless someone
objects to them. They all look pretty safe to me.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#21Neil Conway
neilc@samurai.com
In reply to: Bruce Momjian (#18)
#22Bruce Momjian
bruce@momjian.us
In reply to: Neil Conway (#21)
#23Justin Clift
justin@postgresql.org
In reply to: Bruce Momjian (#22)
#24Tom Lane
tgl@sss.pgh.pa.us
In reply to: Justin Clift (#23)
#25Steve Howe
howe@carcass.dhs.org
In reply to: Bruce Momjian (#22)
#26Katie Ward
kward@peerdirect.com
In reply to: Bruce Momjian (#18)
#27Katie Ward
kward@peerdirect.com
In reply to: Bruce Momjian (#18)
#28Bruce Momjian
bruce@momjian.us
In reply to: Katie Ward (#27)
#29Steve Howe
howe@carcass.dhs.org
In reply to: Katie Ward (#27)
#30Dave Page
dpage@pgadmin.org
In reply to: Steve Howe (#29)
#31Katie Ward
kward@peerdirect.com
In reply to: Steve Howe (#29)
#32Bruce Momjian
bruce@momjian.us
In reply to: Dave Page (#30)
#33Dave Page
dpage@pgadmin.org
In reply to: Bruce Momjian (#32)
#34Peter Eisentraut
peter_e@gmx.net
In reply to: Bruce Momjian (#28)