Re: Windows Build System - My final thoughts

> -----Original Message-----
> From: Bruce Momjian [mailto:pgman(at)candle(dot)pha(dot)pa(dot)us]
> Sent: Friday, January 31, 2003 12:21 AM
> To: Lamar Owen
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] Windows Build System - My final thoughts
>
>
> Man, I go away for one day, and look what you guys get into. :-)
>
> Let me shoot out some comments on this.
>
> First, clearly the Win32 port is going to have more
> port-specific code paths than any other port, so it is going
> to require extra testing even if it wasn't our first non-Unix
> port. You can expect it to take some extra effort even after
> the port has stabalized because when we add something that
> works only on Unix, we will need to code some workaround in Win32.

No question. We had to customize the following files:
backend\access\transam\xlog.c
backend\catalog\aclchk.c
backend\commands\command.c
backend\commands\comment.c
backend\commands\copy.c
backend\commands\creatinh.c
backend\commands\dbcommands.c
backend\commands\define.c
backend\commands\rename.c
backend\commands\user.c
backend\customize\timelib\zic.c
backend\lib\dllist.c
backend\libpq\hba.c
backend\libpq\pqcomm.c
backend\main\main.c
backend\postmaster\pgstat.c
backend\postmaster\postmaster.c
backend\storage\file\fd.c
backend\storage\ipc\ipc.c
backend\storage\smgr\md.c
backend\tcop\utility.c
backend\utils\adt\acl.c
backend\utils\adt\nabstime.c
backend\utils\error\elog.c
backend\utils\fmgr\dfmgr.c
backend\utils\init\findbe.c
backend\utils\init\miscinit.c
backend\utils\misc\guc-file.c
backend\utils\misc\guc.c
backend\utils\misc\superuser.c
bin\pg_dump\common.c
bin\psql\common.c
bin\psql\print.c
bin\psql\startup.c
interfaces\ecpg\preproc\ecpg.c
interfaces\libpgeasy\halt.c

Before each customization, we put:
#ifdef ICKY_WIN32_KLUDGE
{icky fix goes here"
#else
{UNIX code goes here}
#endif

> Second, there are going to be new error cases on this
> platform that we can't anticipate, and some of that isn't
> going to show until we get it released. Documenting those
> pitfalls, like only using NTFS, is a good start.

It works on FAT32, but you don't have security.

> Third, I suspect folks running Win32 aren't as particular
> about stability/reliability, or they would have left MS
> products already.

Typical Anti-MS rhetoric. That's right. The companies with billions of
dollars at stake don't care about stability or reliability. In fact,
they are stupid. They are using MS products after all. Or (perhaps)
they really are concerned about things like that.

> Fourth, some say Win32 isn't an acceptable platform. It may
> or may not be for specific people, but Linux may be an
> unacceptable platform for some people too. I don't think we
> can second guess the users. We will do our best and see how it goes.

Most of the machines in the world run Win32. That's a fact. That may
not be the ideal world, but that's reality.

> Also, I have heard from several people that XP is the first
> OS MS got right. That may or may not be true, but some feel
> things are getting better. It is all a continuim with these
> OS's. Some are great, some mediocre, some really bad, but
> people make decisions and choose bad ones all the time.
> PostgreSQL just needs to be there, if only to migrate them to
> a better platform later. If we aren't there, we can't show
> them how good we are.

I despise:
Windows 95 (bad)
Windows 98 (bad)
WinME (worst of all) is a bletcherous, buggy hack and not suitable for
any use. It should never have been released.

But I like:
Windows NT
Windows 2000
Windows XP

All are reliable and easy to use.

> As for build environment, we have two audiences --- those
> using binaries, and those compiling from source. Clearly we
> are going to have more binary users vs. source users on Win32
> than on any other platform, so at this stage I think making
> thing easier for the majority of our Unix developers is the
> priority, meaning we should use our existing Makefiles and
> cygwin to compile. Later, if things warrant it, we can do
> VC++ project files somehow.

MINGW does not require royalties like Cygwin does and emulates the
Windows environments. Perhaps a single, consistent build environment
can be created using MINGW as a basis for Win32 platforms.

> Lastly, SRA just released _today_ their first Win32 port of
> PostgreSQL, and it is _threaded_:
>
http://osb.sra.co.jp/PowerGres/

> Now, that's a port!

Soulds like it is possible to do then.

> Also, when I am back home for an extended period starting in March,
> I will going through Jan's patch (if no one does it first) and
> submit/apply it in pieces that address specific Win32 issues,
> like path names or carriage returns. Once those are in, we can
> look at the more complex issues of build handling.

I will be willing to help on the Win32 port

> So, as far as I am concerned, we will have a Win32 port in 7.4.
> It will not be perfect, but it will be as good as we can do.
> We are also getting point-in-time recovery in 7.4, so that may
> help us with Win32 port failures too.

The existance of a Win32 port will be good news. The bad news is that
it will introduce literally hundreds of thousands of new users to
PostgreSQL in a very short time. And the worse news is that the
majority of them will be totally clueless. Even at that, PostgreSQL
will enjoy an enormous increase in popularity. I see it becoming the
database of choice for distributed applications all over the world. At
some point, it will become an object of real fear for Oracle, DB/2 and
SQL*Server.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania
19073

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html