Hi,

I think both William and Oliver have good points.

DAW strongest point/market value is its DDO and DEO interfaces.
And having a character mode product not moved for 6 years is also bad image.

We use DF3.2 for Linux - and its DD is compatible with VDF.

If DAW has come this far with its character-mode software, why not take the
leap of faith and invest 8 weeks (as William claims) to have a GUI DataFlex
for Linux. There will be some bugs at first but I'm sure it would settle. I
can still remember VDF4 for Windows - if I was a newcomer then I would have
never looked at VDF again - but being a old timer that has seen DAW thru
DF2.3 right up to VDF11, I think a GUI for Linux would be next step for all
reasons posted on various threads on this newsgroup.

Oliver made a good point - maybe DAW should seperate its GUI interface and
its DDO interface? That could make cross platform development easier?

Just a thought.

Raveen


"William Baker" <bbaker@priefert.com> wrote in message
news:C2F8E58C1F7D4A4CB525AC96D503B58E0D2235@bunyip .abacus-labs.com...
> > Yes, VDF does support multiple DB's out of the box. Remember, ODBC is
>> is included in the main product. What I mean by my statement there is
>> that a VDF app can be developed with no particular DB in mind at the
>> start, and not require ANY changes or recompiles to attach to most any
>> DB.

>
> No need for connectivity kit? Starting with a particular version? VDF8?
> VDF9? Speed issues for classic FIND GT type commands? Now the big
> question for me...character mode windows console stuff? (Linux has ODBC
> support too, but I really don't expect character mode linux to support
> it.) Most SQL database vendors, though they support ODBC, have another
> recommended API into their database which is faster and has more features.
> Some connectivity kits take advantage of this, which I suspect is why DAW
> has an ODBC connectivity kit, as well as one for MSSQL. Don't get me
> wrong, I'm glad they DAW apparently have ODBC support, but that may not
> solve a lot of problems. And it certainly won't solve my problems,
> because development of character mode features ceased a long, long time
> ago. And my existing code uses a lot of FIND GT by INDEX(i+1) style code.
>
> I did the search on google for "wine linux speed" also, and found a lot of
> articles dating from 2000 and a few from 2001, and they were all referring
> to using wine to run Windows binaries, not Linux binaries.
>
> Remember OS/2's slogan, "a better DOS then DOS, a better Windows than
> Windows?" It was indeed a better DOS than DOS. But they never supported
> the Win32 API, only the Win16 API. And arguebly, they were a better
> Windows than Windows 3.1, but not better than Windows 98. So, sometimes
> it is possible to outperform the native operating system. Just look at the
> success of Samba, which has been bestowed the title "a better Windows NT
> server than Windows NT". With the addition of Active Directory in Samba
> 3.0 (currently in late beta), it will probably claim the title "a better
> Windows XP server than Windows XP".
>
> I'm don't claim that Wine is a better Windows than Windows, but in all
> honesty, you must benchmark and compare recent versions of both Wine and
> Windows. A comparison of Wine to Windows ME might show Wine in a
> favorable light, but in 2003, it is not appropriate. Likewise,
> speculative articles written in 2000 about releases from 1999 are more
> than a little bit outdated. For emulation, the only way to know for sure
> is to install RH9 and the Wine that comes with it and see. For native
> mode, the only way to know for sure would be to compile and test a few
> samples. Development just progresses too fast for any other analysis.
>
> This is what Wine's FAQ states today:
>
> ... Now you can start your Windows application straight from your regular
> desktop environment, place that application's window side by side with
> native application windows, copy/paste from one to the other, and run it
> all at full speed.
>
> As far as MicroSoft screwing around their API in Windows 2006 and breaking
> everybody's programs, well, they would break VDF9 on Windows, but not on
> Linux. As well as break AutoCad, MSOffice, Crystal, DB2, Oracle, MSSQL,
> MicroSoft Project, etc. In short, they can't afford to break their API,
> or else their consumers would never upgrade. Imagine how many
> manufacturers would discover that their program, though broken on Windows
> 2006, runs just fine on Linux RH10? I can't imagine a worse situation for
> MicroSoft.
>
> Sure MicroSoft can add _new_ API's, but few choose to recode their apps to
> use them. Not me.
>
> bbaker