FreeTDS Development Group

[Paul Thurston <pthurston AT netegrate.com>]

James:

Thanks for the insight (or should I say 'window' ?) into your Win32/Win64 
viewpoint.

The Win32/Win64 builds are important to me, ironically enough, because Linux 
is our primary platform here.
I spend a lot of time and energy developing and testing our system on RedHat 
Linux.
The Windows port of several components of our main system, although 
necessary, is something of an after-thought as well.
The last thing in the world I want to do is replace the utility libraries 
(database, XML, XSLT) on Linux with windows-specific libraries.
The maintenance of Windows-specific wrapper code, Windows-specific data 
translation and all of the rest is too much of a time commitment, given our 
extremely tight deadlines.

Another freeware library that I  frequently use is the libxml2 from the kind 
folks at the XMLSoft project (http://xmlsoft.org )
Although there are other freeware XML Libraries around (Xalan, Xerces), 
libxml2 and libxslt are the only one I've been able to prove successful both 
on Linux and Windows.
(Xalan/Xerces have several issues, including poor performance in the C++ 
variant. The Java version seems be much more successful.)
Despite the lack of standards on the Windows Platform, the folks at 
XMLSoft.org have managed to come up with a workable solution for Unix & 
Windows releases.
At XMLSoft.org, they've taken the approach of adopting a "standard" by 
releasing a set of Windows Binaries (see 
http://www.zlatkovic.com/libxml.en.html ).
If the XMLSoft folks can do it in the face of Windows-based ambiguity, then 
I'm certain we can come up with a workable solution here at FreeTDS.

FreeTDS is very important to me professionally.
The combination of Linux-based computing platform with a SQL Server-based 
RDMS provides the most cost-effective, yet feature-rich platform currently 
available in the marketplace.
However, Unix to Windows portability is, in my opinion, an important feature 
of the FreeTDS library.
Also, IMHO, the FreeTDS interface is much cleaner and more intuitive than the 
standard C++ SQL Server API provided by Microsoft.

I'm definitely willing to commit personal time and energy to support FreeTDS 
on Windows. Let's talk off-line about getting this set-up.

Thanks,

Paul

P.S. In defense of the patch, Winsock itself maintains init state, so 
initializing it the second time results in a no-op.
However, if you like to adhere to the published documentation, it is trivial 
to take my proposed patch and either

a)      condition the call to INITSOCKET by a global variable recording 
initialization state, or

b)      shove the  INITSOCKET call into a start-up section of the code 
guaranteed to only be called once.

If we don't feel like patching v0.82 so that it will actually work on 
Windows, that's okay, I suppose.
But we should at least say something about how to make v0.82 actually work on 
Windows in the documentation, release notes, install notes, or something.
It's probably less work to just stick in the patch.


From: freetds-bounces AT lists.ibiblio.org 
[mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of James K. Lowden
Sent: Wednesday, May 12, 2010 8:41 PM
To: FreeTDS Development Group
Subject: Re: [freetds] [Bug Report] Missing Winsock initialization in v0.82


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.



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



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.



Regards,



--jkl

_______________________________________________

FreeTDS mailing list

FreeTDS AT lists.ibiblio.org<mailto:FreeTDS AT lists.ibiblio.org>

http://lists.ibiblio.org/mailman/listinfo/freetds