> > * Directory "slashes"
> > - still quite a large number of forward slashes all over the place
> >
>
> Win32 seems to be quite happy with forward slashes. That's why I
> canonicalised all paths to use them in initdb. I tested this
> using mingw shell, cygwin shell and XPHE standard command shell.
mingw + cygwin are certainly happy with forward slashes, but windows
certainly isn't in general (I have no familiarity with XPHE, so I can't
comment here).
Let me put it another way: there are a bunch of places (mostly in sprintf's
where a file name is being formatted) where I had to change to backslashes
to stop postgres PANICking about not being able to find/open files [on Win2K
at least].
> > * stat() + extension differences
> > - execute bits returned by stat are based on file extension under
> > Win32
> > - therefore, binaries'll need to have .exe extension (ie. no symlink
> > for postmaster), and the calls to stat'll have to append ".exe".
> >
>
> In initdb I didn't even do a stat check for executable bit on
> windows, as I already knew I was stat-ing a .exe.
Perhaps I should've been more specific. The ValidateBinary call (called by
FindExec) is going to fail unless it gets passed a filename ending in
".exe", and taking these calls out of the call path for win32 is unlikely to
be an acceptable solution. :-) In any case, this isn't a big deal...
> > However, in doing so, it has become all too clear that, at least until
MingW
> > supports the __declspec(thread) directive, this is not the approach that
> > ought to be taken.
>
>
> Do we need to talk to the MinGW people about this?
Already done. Turns out it is already being worked on. It won't make the gcc
3.3 release, but perhaps gcc 3.4. In any case, it doesn't really matter, as
the approach currently advocated by core for win32 is a multi-process one.
> (waves across american continent and pacific ocean in direction of
homeland ;-)
Hey there!
Cheers,
Claudio
---
WE HAVE MOVED - PLEASE NOTE OUR NEW CONTACT DETAILS:
THE BASEMENT, 33 EWELL STREET, BALMAIN NSW 2041
TEL: +61 2 9555 1544 FAX: +61 2 9555 6911
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
http://www.memetrics.com/emailpolicy.html
