> > 3) Change to using SHGetFolderPath() linked from shfolder.dll (note
> > that this function exists in two different dlls. We'd need
> the one in
> > shfolder.dll to have any effect). And then point people who
> don't have
> > shfolder.dll to the Microsoft download site for this file (it's
> > redistributable, but only in an unmodified self-extracting
> file, so we
> > can't easily embed it in the installer. can be done, but
> not as easy
> > as one would like). It will be required on most systems
> running 95, 98
> > and
> > NT4 (without it we'll be broken on 95 and 98, which work
> today). The
> > file is included on current windows versions by default. This is
> > probably the nicest idea, but I'm not sure how much work we want to
> > throw into the NT4 support. Considering MS has stopped
> supporting it
> > even to their pay-through-the-nose-for-support customers by
> now. (and
> > we
> > *do* work on NT4 as long as the user has installed IE4)
> >
>
> I certainly understand not wanting to spend a bunch of time
> on NT support. But everything seemed fine through 8.0.0-rc1,
> so I would hate to see it go away over this one issue. I did
> not realize that 95/98 worked at all. I don't think anyone
> really wants to setup a server on 95, 98, or even NT4, but it
> would be really nice if psql would work.
I investigated this further, and have submitted a patch to use this
behaviour. Turns out that my almost-fresh-NT4-install already contains
shfolder.dll - even though I have *not* installed IE on it (it still
runs IE2). Since thw patch itself was trivial, I think this is the
acceptable solution.
Oh, and things were not fine until rc1. It read config/rc files from
different locations, and SSL files were simlpy broken.
95, 98, ME only work for the client. The server never have and never
will work on them (unless you use cygwin).
//Magnus