Re: Other Win32 TODO items?

Claudio Natoli wrote:

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

To the best of my knowledge, only the command processor cares about
this, and you can get around it by quoting the command - see my initdb.c
for examples. (this is also why I pass PGDATA via the environment and
never via the command line - the Windows command processor is quite dumb
about multiple quoted strings). AFAIK direct library calls like stat()
or fopen() should accept forward slashes. It may be that libraries other
than MSVCRT act differently, although that would be very odd, even for M$.

What context are you using the formatted string in?

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

Regardless, you can only stat a file, and windows executables have .exe
extensions. Of course we have to program for this (again. see initdb.c
for examples).

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

For now. I suspect that threading will be wanted before too long.

cheers

andrew

>
>