Thread: Native Win32, How about this?
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?
On Sat, 2002-05-11 at 02:25, mlw wrote: > 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. ... > 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. It seems that mingw (http://www.mingw.org/) does exactly this and provides needed headers/libs. And they have also non-cycwin minimal build environment (MSYS) that supplies make,sh and other stuff we might use for running initdb and other shell scripts. > 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? Probably not. >> > 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. dev-c++ has also wizards for easy making of trivial user interfaces http://sourceforge.net/projects/dev-cpp/ -------------- Hannu
> 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. That may ultimately be desirable. In the short term, it is likely preferable to use cygwin. It is only necessary to point at MySQL for an example. Cygwin is used there. <http://www.mysql.com/downloads/mysql-3.23.html> It is being used widely, "crap" or not. Cygwin may not ultimately be the ideal thing to use; we don't yet live in Pangloss' "Best of All Possible Worlds," and thus have to live with some things not being ideal. If having the installer install Cygwin as well as the DBMS makes it easy to have something usable soon, and this allows 100,000 WinFolk to try out PostgreSQL, then that's a Big Win. Out of 100K users, surely two or three may be attracted into working on a more Panglossian solution. It may be fair to say that none of those 100K folk would be using PostgreSQL to support HA applications involving hundreds of GB of data. That's _fine_. If there are new 100K folk using PostgreSQL/cygwin, _some_ of them will outgrow its capabilities, and come looking for improvements. And as they're Windows users, accustomed to having to pay hefty amounts to Microsoft to get support no better than that provided by the Psychic Friends Network (see <http://www.bmug.org/news/articles/MSvsPF.html>), they'll doubtless be prepared to have to pay _something_ in order for "PostgreSQL/Win3K-Enterprise Edition" to become available. That seems a not too unreasonable path towards the "Best of All Possible Worlds." There may be a bit of hyperbole in the above, but any time Voltaire gets quoted, that's likely to happen :-). -- (reverse (concatenate 'string "gro.gultn@" "enworbbc")) http://www.cbbrowne.com/info/wp.html Eagles may soar, but weasels don't get sucked into jet engines. -- (concatenate 'string "cbbrowne" "@ntlug.org") http://www.cbbrowne.com/info/multiplexor.html It's a little known fact that the Dark Ages were caused by the Y1K problem.
mlw, On Fri, May 10, 2002 at 05:25:02PM -0400, mlw wrote: > 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. Sorry, but I'm not going to touch the above -- even with a ten foot pole. Or, at least try not to... :,) > 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. Yes, the above mentioned option is "-mno-cygwin". > Some of the hits will be file path manipulation, '/' vs '\', the notion of > drive letters, and case insensitivity in file names. Case insensitivity is typically "enabled" regardless. Unless you are referring to CYGWIN=check_case:strict, but almost no one uses this setting. Just to be explicit, another hit will be the loss of Posix. > [snip] > > I think a huge time savings can be had by avoiding rewriting everything > for the Microsoft build environment. Yes, you should use Cygwin and gcc -mno-cygwin or MSYS and Mingw. > 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. The above is true only with gcc -mno-cygwin or Mingw code. Any code produced by the normal Cygwin gcc (and hence, linked against cygwin1.dll) is effectively GPL'd or at least required to be open source. > [snip] Jason