Thread: ODBC 16 bit support
Hello all, Boy the discussions on this list are certainly lively these days! I didn't say that "Postgres" shouldn't offer a 16 bit ODBC driver to go with its distribution. After all, you still have the old PostODBC driver that works for 16 bit. I said that this new driver probably shouldn't support 16 bit. It is still, as it always has been, YOUR decision to use this new driver or not. We (meaning Insight) needed a good solid driver for our clients and the old one just wasn't cutting it, thus a rewrite, reorganization, whatever you want to call it, was necessary for us. We offered this driver in the hopes of helping the Postgres effort. When we made this new driver available, we provided a whole list of things that were changed or removed or enhanced to make this driver work really well. The first thing on the removed list is "Win 3.1". How come now everybody is complaining? Didn't you read the list? Now that said, on my own time over the weekend, I will look into what it would take to make the current driver support win3.1. But if it turns out that it would degrade the performance of the driver for 32bit or require major rework, I would probably have to say, it would be best to have 2 separate drivers. Regards, Byron
On Sat, 18 Apr 1998, Byron Nikolaidis wrote:
> Now that said, on my own time over the weekend, I will look into what it
> would take to make the current driver support win3.1. But if it turns
> out that it would degrade the performance of the driver for 32bit or
> require major rework, I would probably have to say, it would be best to
> have 2 separate drivers.
And I've have to say a *definite* no here...the result of that
would be two different drivers, with different features available to
it...totally unacceptable.
That would be like taking our 32bit vs 64bit server and saying
that since nobody many ppl are using 64bit right now, we're going to get
rid of those features that are currently broken, instead of trying to
address them.
Quite frankly, this whole thread is starting to cause me to
reconsider my decision to move away from the old driver over to this new
driver... *sigh*
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> On Sat, 18 Apr 1998, Byron Nikolaidis wrote:
>
> > Now that said, on my own time over the weekend, I will look into what it
> > would take to make the current driver support win3.1. But if it turns
> > out that it would degrade the performance of the driver for 32bit or
> > require major rework, I would probably have to say, it would be best to
> > have 2 separate drivers.
>
> And I've have to say a *definite* no here...the result of that
> would be two different drivers, with different features available to
> it...totally unacceptable.
>
Why?
Pretty much every product that I can think of has separate 16-bit and 32-bit
product groups.
Albeit that most of those are MS products, there is no real reason why
different environments should not have different solutions.
The ODBC spec is well defined so anything conforming to it should be
reasonably feature-compatible.
> That would be like taking our 32bit vs 64bit server and saying
> that since nobody many ppl are using 64bit right now, we're going to get
> rid of those features that are currently broken, instead of trying to
> address them.
>
Not a good example I think. The 16/32-bit ODBC question says nothing about
dropping features. As I said above, ODBC is ODBC: you either conform or you
don't. If there happen to be differences between the levels of conformance or
of performance between 16 and 32-bit models, that would be a pity but not
earth shattering.
Next you will want to ban anything that behaves/performs differently on NT
than on UNIX;-)
> Quite frankly, this whole thread is starting to cause me to
> reconsider my decision to move away from the old driver over to this new
> driver... *sigh*
>
> Marc G. Fournier
> Systems Administrator @ hub.org
> primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
>
Cheers,
Stephen
========================================================================
Stephen Davies Consulting scldad@sdc.com.au
Adelaide, South Australia. Voice: 61-8-82728863
Computing & Network solutions. Fax: 61-8-82741015
Quoting Stephen Davies (scldad@sdc.com.au):
> Not a good example I think. The 16/32-bit ODBC question says nothing about
> dropping features. As I said above, ODBC is ODBC: you either conform or you
> don't. If there happen to be differences between the levels of conformance or
> of performance between 16 and 32-bit models, that would be a pity but not
> earth shattering.
>
But there should be one code tree... With some #ifdef's not 2
seperate code tree's. I think this is the point everyone is making.
Julie
--
[ Julia Anne Case ] [ Ships are safe inside the harbor, ]
[Programmer at large] [ but is that what ships are really for. ]
[ Admining Linux ] [ To thine own self be true. ]
[ Windows/WindowsNT ] [ Fair is where you take your cows to be judged. ]
On Sun, 19 Apr 1998, Stephen Davies wrote:
> > And I've have to say a *definite* no here...the result of that
> > would be two different drivers, with different features available to
> > it...totally unacceptable.
> >
>
> Why?
>
> Pretty much every product that I can think of has separate 16-bit and 32-bit
> product groups.
>
> Albeit that most of those are MS products, there is no real reason why
> different environments should not have different solutions.
That should be your first clue right there. It's not in MS interests to
promote the use of 16 bit products. They want you to buy win9x. The
feature sets in *their* 16 bit products will intentionally be dwindled
with each new release or update. Look what they tried to pull with office
97.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> TEAM-OS2
Online Searchable Campground Listings http://www.camping-usa.com
"I'm just not a fan of promoting stupidity!
We have elected officials for that job!" -- Rock
==========================================================================
At 15:34 +0300 on 19/4/98, Stephen Davies wrote:
> Why?
>
> Pretty much every product that I can think of has separate 16-bit and 32-bit
> product groups.
>
> Albeit that most of those are MS products, there is no real reason why
> different environments should not have different solutions.
I know it's not entirely my place to intrude here, being the last candidate
to use *any* ODBC product, due to the fact that I keep my computer proudly
M$-free...
But being a Macintosh user, I've seen the problem in the Macintosh
industry. Almost every self-respecting application is programmed to fit
both PPC based Macintoshes and 68xxx Macintoshes - either in the same
executable or in separate executables. Of course, the difference between
PPC programming and 68K programming is not as great as the difference
between Win32 and Win16. But still, you have to do the extra work, and
maintain the extra branches in the source tree, and so on. And everybody
does that.
Also, being the "neighbourhood guru" (you know, when people who are
computer illiterate want something installed, they call the nearest person
who can tell a keyboard from a modem, no matter that he is a Mac/unix
person and they have a PC - they don't actually know the difference) - I
work with people who have Win16, and I always install the latest and
greatest software - latest version of Netscape Communicator, latest version
of Eudora Light, etc. - on their old Windows Machines. If Eudora and
Netscape bother to update their freeware for the benefit of that market, I
think someone who really believes in freeware should do the same.
I think the best way is to regard Win16 and Win32 as separate platforms.
Careful design *may* help you to write some of the code only once for both
platforms (for example, all the code that processes the data from the
Postgres backend). But the products should be separate, and should *try* to
have the same features - just like Eudora Light for Win16 and Win32.
You may say that you lack the expertise to write a good Win16 program.
Well, Postgres is a collaborative effort, and you may find someone who will
be willing to complement your work. You coordinate the features with
him/her, agree on which parts may be common to both of you, and then go
your separate ways about the separate drivers.
Herouth
--
Herouth Maoz, B.Sc. Work: herouth@oumail.openu.ac.il
Home: herutma@telem.openu.ac.il
HOME PAGE: http://homes.openu.ac.il/~herouth/
Internet technical assistant Open University, Telem Project
The Hermit Hacker wrote: > > On Sat, 18 Apr 1998, Byron Nikolaidis wrote: > > > Now that said, on my own time over the weekend, I will look into what it > > would take to make the current driver support win3.1. But if it turns > > out that it would degrade the performance of the driver for 32bit or > > require major rework, I would probably have to say, it would be best to > > have 2 separate drivers. > > And I've have to say a *definite* no here...the result of that > would be two different drivers, with different features available to > it...totally unacceptable. Not totally, I like working drivers. Despite what Microsoft tries to tell you Win16 and Win32 are two quite different OSes. I think that it would be easier to have a unified Win32/UNIX ODBC driver than to keep the sources for Win16 and Win32 together (and get some benefit out of it) For me, having a fast and working 32 bit driver and mostly broken 16 bit driver is much better than having 16 and 32 bit drivers both mostly broken, even though tha last one is closer to giving us two similar drivers with similar features <grin>. > That would be like taking our 32bit vs 64bit server and saying > that since nobody many ppl are using 64bit right now, we're going to get > rid of those features that are currently broken, instead of trying to > address them. Actually not, as 64bit is something that we will have to adress some day anyhow, and it also gives an extra test for some aspects of code quality (maybe;) > Quite frankly, this whole thread is starting to cause me to > reconsider my decision to move away from the old driver over to this new > driver... *sigh* Have you ever tried to use the old driver ? Or are you just talking about general principles ? In principle I like the idea of having both 16 and 32 bit driver and having a common source for them, but if this produces broken drivers and no progress in fixing them (just complaints that nobody is sending patches) then I still think that your decision to move away from the old one was right. It may still be a good idea to bring it back as a 16 bit solution. The workarounds required in very limited memory situations that the 16 bit driver has to live in may be fundamentally different than in the 32 bit one. For example it might be easier to have the current 32bit driver run on the unix side and have just 16-bit proxy functions run in the client (somewhat like the Openlink crowd is doing it). Then later, when we get a real ISO/ANSI compatible CLI (Call Level Interface), we may put something thinner than a whole ODBC driver in the server. Hannu
On Sun, 19 Apr 1998, Julia A.Case wrote:
> Quoting Stephen Davies (scldad@sdc.com.au):
> > Not a good example I think. The 16/32-bit ODBC question says nothing about
> > dropping features. As I said above, ODBC is ODBC: you either conform or you
> > don't. If there happen to be differences between the levels of conformance or
> > of performance between 16 and 32-bit models, that would be a pity but not
> > earth shattering.
> >
> But there should be one code tree... With some #ifdef's not 2
> seperate code tree's. I think this is the point everyone is making.
Its kinda sad when a piece of software as small as the ODBC driver
can't deal with two different OSs (16bit vs 32bit Windows), while
PostgreSQL itself, substantially larger, can currently handle *how* many
totally disparate operating systems, from totally different vendors??
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker wrote: > > On Sun, 19 Apr 1998, Julia A.Case wrote: > > > Quoting Stephen Davies (scldad@sdc.com.au): > > > Not a good example I think. The 16/32-bit ODBC question says nothing about > > > dropping features. As I said above, ODBC is ODBC: you either conform or you > > > don't. If there happen to be differences between the levels of conformance or > > > of performance between 16 and 32-bit models, that would be a pity but not > > > earth shattering. > > > > > But there should be one code tree... With some #ifdef's not 2 > > seperate code tree's. I think this is the point everyone is making. > > Its kinda sad when a piece of software as small as the ODBC driver > can't deal with two different OSs (16bit vs 32bit Windows), Of course it would be nice if it supported the other platforms whith ODBC capabilitries: alse Macs and UNIX. > while PostgreSQL itself, substantially larger, Just FYI: PostgreSQL source is a little less than 10x bigger than PostODBC source. PostODBC source is more than 6x bigger than libpg source. > can currently handle *how* many > totally disparate operating systems, from totally different vendors?? PostgreSQL itself can currently handle only UNIX and no /totally different/ oses. And we don't even support the oldest unixen (say the one on PDP11 without MMU) with awkward memory architectures reminscent of Win16 (swapping instead of paging, need to manually lock virtual memory). Or do we ? I remember several requests for supporting at least Win32, but as nobody was ready to do much about it, the whiners were told to buzz off and the #ifdefs for WIN32 were removed (was it since 1.0.1 or 1.0.9 ?) Hannu
On Sun, 19 Apr 1998, Hannu Krosing wrote:
> Of course it would be nice if it supported the other platforms whith
> ODBC capabilitries: alse Macs and UNIX.
There's no reason it can't. You write the driver using a common set of
functions from the std C or C++ libs. ANYTHING that is OS specific is
called using a generic name (eg. AllocateSomeMemory()) and have the
function in an OS specific file and it can call the correct function for
that OS. I've written a number of things this way and do my testing and
debugging of the main routines in OS/2. Quickly write a file to handle
the windows 16 and 32 and the unix stuff and compile on the machines it's
going to. Unless I add things that require additions to the OS specific
files, I may not need to touch them again and the main app is updated
easily.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> TEAM-OS2
Online Searchable Campground Listings http://www.camping-usa.com
"I'm just not a fan of promoting stupidity!
We have elected officials for that job!" -- Rock
==========================================================================
On Sun, 19 Apr 1998, Hannu Krosing wrote:
> I remember several requests for supporting at least Win32, but as
> nobody was ready to do much about it, the whiners were told
> to buzz off and the #ifdefs for WIN32 were removed (was it since 1.0.1
> or 1.0.9 ?)
Close, but no prize...yes, WIN32 #ifdef's were removed, since a)
they didn't work and b) nobody was working on it.
As for telling ppl to buzz off...go read the archives a little
more closely... each time someone asks, we tell them that its not support
and ask them for patches to make it happen. *shrug* Nobody, yet, has done
anything about it ...
We don't support Windows because nobody out there seems to care
enough to do anything about it...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> On Sun, 19 Apr 1998, Julia A.Case wrote: > > > Quoting Stephen Davies (scldad@sdc.com.au): > > > Not a good example I think. The 16/32-bit ODBC question says nothing about > > > dropping features. As I said above, ODBC is ODBC: you either conform or you > > > don't. If there happen to be differences between the levels of conformance or > > > of performance between 16 and 32-bit models, that would be a pity but not > > > earth shattering. > > > > > But there should be one code tree... With some #ifdef's not 2 > > seperate code tree's. I think this is the point everyone is making. > > Its kinda sad when a piece of software as small as the ODBC driver > can't deal with two different OSs (16bit vs 32bit Windows), while > PostgreSQL itself, substantially larger, can currently handle *how* many > totally disparate operating systems, from totally different vendors?? > That is very commendable but, while not trivial, the differences between flavours of UNIX are nothing compared with the differences between W16 and W32. I have ported some pretty major codes between UNIXes (eg gated) and I have also ported a number of apps from W16 to W32. I definitely prefer doing the former. Despite the fact that we are looking for solutions to the same need and conformance to the same spec, I cannot see anything wrong with having two "products" to achieve that. Cheers, Stephen. ======================================================================== Stephen Davies Consulting scldad@sdc.com.au Adelaide, South Australia. Voice: 61-8-82728863 Computing & Network solutions. Fax: 61-8-82741015
On Mon, 20 Apr 1998, Stephen Davies wrote:
> Despite the fact that we are looking for solutions to the same need and
> conformance to the same spec, I cannot see anything wrong with having two
> "products" to achieve that.
Except that the two "products" should be only different in their
coding...I, as a non-Windows person, should be able to take either or
binaries and install them with little to no differences...
The Hermit Hacker wrote: > On Sat, 18 Apr 1998, Byron Nikolaidis wrote: > > > Now that said, on my own time over the weekend, I will look into what it > > would take to make the current driver support win3.1. But if it turns > > out that it would degrade the performance of the driver for 32bit or > > require major rework, I would probably have to say, it would be best to > > have 2 separate drivers. > > And I've have to say a *definite* no here...the result of that > would be two different drivers, with different features available to > it...totally unacceptable. > > That would be like taking our 32bit vs 64bit server and saying > that since nobody many ppl are using 64bit right now, we're going to get > rid of those features that are currently broken, instead of trying to > address them. > > Quite frankly, this whole thread is starting to cause me to > reconsider my decision to move away from the old driver over to this new > driver... *sigh* > Let me save you some trouble. We offered our driver to you, to do with, as you wish. Our only purpose was to strengthen the PostgreSQL effort. It appears that we have failed in this effort. Nonetheless, the offer still holds. Only, we are withdrawing our cooperative support. Life is too short to take this kind of grief. (see Billy Gates karma.) Marc, you seem to know much about managing these sorts of projects. For that you deserve much credit. However, you may have been better served by not taking sides on this Windows issue. You, yourself claimed you did not know much about Windows programming. At least that is what you said, when you installed an overseer (Julie) between us and the source we were trying to support . I do not understand your absolutist positions on these matters. We will continue to post our version of the driver at our site. If anyone wants to use it or distribute it, including the PostgreSQL.org, great. Furthermore, we will consider any patches or comments that are sent our way - via direct mail. I apologize to our two or three supporters.
Attachment
Quoting David Hartwig (daveh@insightdist.com):
> We offered our driver to you, to do with, as you wish. Our only purpose was to
> strengthen the PostgreSQL effort. It appears that we have failed in this
> effort. Nonetheless, the offer still holds. Only, we are withdrawing our
> cooperative support. Life is too short to take this kind of grief. (see Billy
> Gates karma.)
>
I warned you that the 16/32 bit issue was a powder keg... The
trouble I believe is that, even under NT/95, if you are running 16 bit
apps they need a 16 bit ODBC driver. And dropping support for 16 bit
machines is only going to cause grief.
David... Your company did a bang up job on fixing the 32 bit
support. That can't be denied. We just need to figure out how to mesh
the support for 16 bit into it.
Julie
--
[ Julia Anne Case ] [ Ships are safe inside the harbor, ]
[Programmer at large] [ but is that what ships are really for. ]
[ Admining Linux ] [ To thine own self be true. ]
[ Windows/WindowsNT ] [ Fair is where you take your cows to be judged. ]
> The trouble I believe is that, even under NT/95, if you are running > 16 bit apps they need a 16 bit ODBC driver. I'm successfully using INFORMIX and Borland Interbase 32-Bit ODBC drivers from 16-Bit applications running on Windows NT 4.0. I used ODBCAD32.EXE to define/configure my data sources. Olaf -- Olaf Mittelstaedt - IuK - mittelstaedt@fh-ulm.de Fachhochschule Ulm Prittwitzstr. 10 89075 Ulm Tel.: +49 (0)731-502-8220 Fax: -8270 Beati pauperes spiritu.