FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

2010/5/13 James K. Lowden <jklowden AT freetds.org>:
> Paul Thurston wrote:
>>
>> I reported this bug in the v0.82 last year (May 2009). Would someone
>> please patch this, or provide me with CVS access ( and I'll do it)?
>
> Hi Paul,
>
> I want to alleviate some confusion and welcome your participation. If,
> unlike me, you care about the Win32 builds and have a continuing need to
> keep them working, I will absolutely give you CVS access.
>
> It's true that the Win32/64 build is a something of a stepchild.  After
> all, the vendors provided Windows libraries.  But it's no secret that
> DB-Library is not their priority, witness the the lack of a new version is
> ~10 years.  FreeTDS is arguably the best DB-Library implementation
> currently available (even if that's not saying much).
>
> Windows and I go way back.  I attended the first conference in New York,
> in 1985.  I have the manuals for 1.0.3.  I remember the excitement over
> Daytona and Cairo, and the dismay at moving the video driver into the
> kernel.  More recently I had need for a 64-bit db-lib, and got FreeTDS
> working there in a few days.  I also added the Nmakefile and a bunch of
> Win64 fixes at that time.
>
> The challenge -- one I don't take up -- for anyone trying to support an
> open-source Windows library is to cope with the ever-changing
> standards-free rules.  dsw or sln?  strcpy(3) or _CRT_SECURE_NO_WARNINGS?
> WIN32_LEAN_AND_MEAN?  There's more Win32 gadgetry in FreeTDS than for any
> other OS, and it's very fragile because it's impossible to interrogate the
> system about its requirements, let alone foresee what Microsoft will do
> next.
>

Yes, the problem with Windows is standards... there is no standards
projects/makefile... nothing... We can compile autoconf/automake under
dozen of different systems but you cannot even port between different
Visual C++ versions... and what about MingW, Borland, Intel and others
compilers? Currently FreeTDS containg files for dev-c++, msvc6, vs2005
and Nmakefile but who maintains consistently all that files ?? There
are some projects which generate different project files (like CMake
or SCons) but I have no much experience (and not that time to get to).
One "stable" thing (which does not exclude adding project files) we
could make is build a guide on how to adapt files and projects in
order to compile FreeTDS sources (at the end is a bunch of standard C
code... one of the more portable languages I know...).

> Your original patch wasn't applied because IMHO it's not right.  It
> initializes the Winsock library before every connection; the documentation
> says that should be done only once, which is what CVS HEAD does.  The
> documentation does not say what happens if WSAStartup() is called twice.
> Even if it works (or seems to), I'd rather not try.
>
> fake_poll() is mine.  The idea is to remove any call to select(2) in the
> main code, and always call poll(2) even if it's the fake one.  HAVE_POLL
> will disappear.  If that's not working for you, let's make it work.  (It
> worked for me with Win32/64 and VS 2005.  I use the Nmakefile, though.)
>

I think the problem was (yesterday I changed header/source to fix
problems) related to sdk header updates (due to new WSAPoll function).
Some defines collided. Now constants are defined consistently to
Windows ones and fakepoll use WSAPoll where available.

> My priority is the next release, not 0.82.  I can see Frediano rolling his
> eyes, because he's been waiting for a long time.  If you want to patch up
> 0.82, that's fine with me, but I want to encourage you to think of CVS
> HEAD as the latest version.  It will be, just as soon as I finish the
> documentation.
>

Mine too! After years of development backporting is too much expensive.

freddy77