[comp.databases] Foxpro on SCO Xenix

zureick@ucunix.san.uc.edu (John H. Zureick) (06/21/91)

I received a mailing some time ago from SCO explaining that they had
plans to bring Foxpro over to xenix or unix at some future date.   
Yesterday while talking to a sales rep from SCO he told me that they
have decided NOT to make Foxpro available, choosing instead to 
concentrate on Oracle and Ingres.  Does anyone have the real true
story on what is going the plans are for Foxpro and SCO?

-- 
John H. Zureick					zureick@ucunix.san.uc.edu

pew@cs.brown.edu (Peter E. Wagner) (06/21/91)

In article <1991Jun20.182306.26927@ucunix.san.uc.edu>, zureick@ucunix.san.uc.edu (John H. Zureick) writes:
|> I received a mailing some time ago from SCO explaining that they had
|> plans to bring Foxpro over to xenix or unix at some future date.   
|> Yesterday while talking to a sales rep from SCO he told me that they
|> have decided NOT to make Foxpro available, choosing instead to 
|> concentrate on Oracle and Ingres.  Does anyone have the real true
|> story on what is going the plans are for Foxpro and SCO?
|> 

From a Fox Software press release of a few weeks ago:

For the future, versions of FoxPro for Windows, the Apple Macintosh, and
UNIX/Xenix are under development, with a Fox client/server solution planned
for 1992 to further extend the power and scope of this new technology.


I suspect that Fox is doing the Unix version themselves.

    Peter

alan@ahmcs.uucp (Alan Mintz) (06/22/91)

In article <1991Jun20.182306.26927@ucunix.san.uc.edu>, zureick@ucunix.san.uc.edu (John H. Zureick) writes:
> I received a mailing some time ago from SCO explaining that they had
> plans to bring Foxpro over to xenix or unix at some future date.   
> Yesterday while talking to a sales rep from SCO he told me that they
> have decided NOT to make Foxpro available, choosing instead to 
> concentrate on Oracle and Ingres.  Does anyone have the real true
> story on what is going the plans are for Foxpro and SCO?

The semi-official word from Fox Software is that they will be developing the
some_UNIX_platform product (the sale critter didn't know there were different
UNIX platforms) for release around 1st quarter of 1992. 

SCO has said that they will definitely NOT be porting Foxpro. In fact, there
will not be ANY further release of Foxbase+ for SCO XENIX/UNIX
(at least not from SCO). There will be (hopefully) a maintenance release
to fix some of the outstanding problems, but no new features will be added.
-- 
< Alan H. Mintz  | alan@ahmcs.mq.com | ...!uunet!ahmcs!alan >

shevett@dworkin.UUCP ( Sysop) (06/22/91)

pew@cs.brown.edu (Peter E. Wagner) writes:
>In article <1991Jun20.182306.26927@ucunix.san.uc.edu>, zureick@ucunix.san.uc.edu (John H. Zureick) writes:
>|> Yesterday while talking to a sales rep from SCO he told me that they
>|> have decided NOT to make Foxpro available
>|> 

>From a Fox Software press release of a few weeks ago:
>For the future, versions of FoxPro for Windows, the Apple Macintosh, and
>UNIX/Xenix are under development, with a Fox client/server solution planned
>for 1992 to further extend the power and scope of this new technology.
>I suspect that Fox is doing the Unix version themselves.

You suspect correctly.  From a conversation I had with a fellow asked to
port FoxPro to Sun's, there was a big bruhaha involving licensing FoxBase
to SCO.  Apparently Fox pretty much said "Here's FoxBase for the PC in
all it's source code form.  From now on, it's your problem."  Once that
cut was made, Fox wouldn't touch the SCO product.  There was a lot of
issues in the works when the question of 'Who will do FoxPro for Unix'
came up, and Fox won out, saying they'll do it themselves.

I personally am looking forward to it with *BAITED* breath.  We have
several applications under DOS that are screaming for Unix ports, but
the FoxBase under Unix is too limited in keyboard and video handling 
to be worth it. 

--------------------------------------------------------------------
shevett@dworkin.amber.mccc.edu <--- Should work  | Dave Shevett
shevett@mccc.edu <----------------- works great. | Lawrenceville, NJ
--------------------------------------------------------------------

fred@compu.com (Fred Rump) (06/24/91)

shevett@dworkin.UUCP ( Sysop) writes:

>I personally am looking forward to it with *BAITED* breath.  We have
>several applications under DOS that are screaming for Unix ports, but
>the FoxBase under Unix is too limited in keyboard and video handling
>to be worth it.

        What doesn't the keyboard do?
        
        As for video, aren't you still stuck with dumb terminals as the 
        main limitation? Unless they do FoxPro for X nothing will really 
        change from that perspective.
        
        We supply hardware and integration services to a software house 
        that sells a $60K foxbase application. They did not wait for 
        fancy video to come out. They simply automate warehouseing 
        applications.
        
        Fred
-- 
Fred Rump              | 'A little learning is a dangerous thing/Drink deep
CompuData, Inc.        | or taste not the Pierian spring'    Alexander Pope
10501 Drummond Rd.     |		SCO Advanced Product Center
Philadelphia, Pa. 19154| Internet: fred@COMPU.COM         (215-824-3000)

markc@sql.sybase.com (Mark Chojnacki) (06/26/91)

shevett@mccc.edu (Dave Shevett) writes:
>pew@cs.brown.edu (Peter E. Wagner) writes:
>
>>From a Fox Software press release of a few weeks ago:
>>For the future, versions of FoxPro for Windows, the Apple Macintosh, and
>>UNIX/Xenix are under development, with a Fox client/server solution planned
>>for 1992 to further extend the power and scope of this new technology.
>>I suspect that Fox is doing the Unix version themselves.
>
>You suspect correctly.  From a conversation I had with a fellow asked to
>port FoxPro to Sun's, there was a big bruhaha involving licensing FoxBase
>to SCO.  Apparently Fox pretty much said "Here's FoxBase for the PC in
>all it's source code form.  From now on, it's your problem."  Once that
>cut was made, Fox wouldn't touch the SCO product.  There was a lot of
>issues in the works when the question of 'Who will do FoxPro for Unix'
>came up, and Fox won out, saying they'll do it themselves.

Also, at the time of the negotiations between SCO and Fox Software, the
marketing manager for SCO FoxBASE+ at SCO left SCO to join Fox Software.
However, this doesn't mean development work with FoxBASE+ is dead at SCO.
In fact, custom ports to other versions of UNIX (under contract to OEMs)
were being done at SCO Canada the last time I checked. These were based
on the current version of SCO FoxBASE+ (2.1.2).

(I should know...I was managing them up until the time I left SCO...:-))

I don't know of any plans by SCO to upgrade FoxBASE+ under SCO UNIX.

Mark Chojnacki
SQL Solutions, Toronto, Canada
markc@sql.sybase.com

AR.HFN@forsythe.stanford.edu (Hooshyar Naraghi) (06/26/91)

In article <79012@brunix.UUCP>,
pew@cs.brown.edu (Peter E. Wagner) writes:
>In article <1991Jun20.182306.26927@ucunix.san.uc.edu>, zureick@ucunix.san.uc.edu (John H. Zureick) writes:
>|> I received a mailing some time ago from SCO explaining that they had
>|> plans to bring Foxpro over to xenix or unix at some future date.
>|> Yesterday while talking to a sales rep from SCO he told me that they
>|> have decided NOT to make Foxpro available, choosing instead to
>|> concentrate on Oracle and Ingres.  Does anyone have the real true
>|> story on what is going the plans are for Foxpro and SCO?
>|>
>
>From a Fox Software press release of a few weeks ago:
>
>For the future, versions of FoxPro for Windows, the Apple Macintosh, and
>UNIX/Xenix are under development, with a Fox client/server solution planned
>for 1992 to further extend the power and scope of this new technology.
>
>
>I suspect that Fox is doing the Unix version themselves.
>
>    Peter

I asked one of Fox Regional Managers in a Foxpro 2.0 demo session in
San Francisco, and he confirmed that yes Fox is going to take on the
Foxpro/Unix project itself.

He said that the R&D team was just starting to tackle the problem of
chr-based windows on dumb terminals!  As to the shipping date, he
remained silent but quietly mentioned the beginning of '92.

Hooshyar F. Naraghi
(415) 324-1055
AR.HFN@forsythe.stanford.edu

dhartung@chinet.chi.il.us (Dan Hartung) (06/26/91)

fred@compu.com (Fred Rump) writes:
>        As for video, aren't you still stuck with dumb terminals as the 
>        main limitation? Unless they do FoxPro for X nothing will really 
>        change from that perspective.

The word from Fox Software is that, while they have not yet gotten down
to brass tacks on this question, they will probably support X Windows.


-- 
Daniel A. Hartung           |  "What's the difference anyway, between being
dhartung@chinet.chi.il.us   |  safe and being rad, the joke's on us, we've
Birch Grove Software        |  all been had."  -- John Wesley Harding
-----------FoxPro Programmer Looking For Work--------------

pew@cs.brown.edu (Peter E. Wagner) (06/26/91)

In article <1991Jun26.030619.974@morrow.stanford.edu>, AR.HFN@forsythe.stanford.edu (Hooshyar Naraghi) writes:
|> 
|> He said that the R&D team was just starting to tackle the problem of
|> chr-based windows on dumb terminals!  As to the shipping date, he
|> remained silent but quietly mentioned the beginning of '92.


Don't hold your breath.

    Peter

shevett@dworkin.UUCP ( Sysop) (06/28/91)

fred@compu.com (Fred Rump) writes:

>shevett@dworkin.UUCP ( Sysop) writes:

>>the FoxBase under Unix is too limited in keyboard and video handling
>>to be worth it.

>What doesn't the keyboard do?

Under Xenix, there is no way to trap more key definitions than those 
allowed under the termcap.  Our DOS systems use Up,Down,Left,Right,Home,
End,PageUp,PageDown, and all 10 function keys.  We can't trap those
keys in a meaningful way under Xenix.  It just can't do it.

>        As for video, aren't you still stuck with dumb terminals as the 
>        main limitation? Unless they do FoxPro for X nothing will really 
>        change from that perspective.

Yes and no.  The interface under Xenix is *very* primitive.  Again, the
keyboard problems come to mind, but if you look at an application like
WordPerfect, they are doing some mighty fancy keyboard and video functions
on 'dumb' terminals.

>        We supply hardware and integration services to a software house 
>        that sells a $60K foxbase application. They did not wait for 
>        fancy video to come out. They simply automate warehouseing 
>        applications.

The problem is we need to port an application that is already running 
under DOS with a *very* specific user interface to Unix.  We need the 
advanced video and keyboard functions.

--------------------------------------------------------------------
shevett@dworkin.amber.mccc.edu | Dave Shevett - Lawrenceville, NJ
CSAccess BBS (609) 584-8774    | Keeper of yon FoxPro mailing list
--------------------------------------------------------------------

fr@compu.com (Fred Rump from home) (06/30/91)

shevett@dworkin.UUCP ( Sysop) writes:
>Under Xenix, there is no way to trap more key definitions than those
>allowed under the termcap.  Our DOS systems use Up,Down,Left,Right,Home,
>End,PageUp,PageDown, and all 10 function keys.  We can't trap those
>keys in a meaningful way under Xenix.  It just can't do it.

I'm not a termcap expert but don't you simply need a PC TERM (scan code) type 
terminal like a wyse 60 to capture all those codes? You need the keyboard with 
all those functions plus ALT anyway, right? After all WORD uses ansi termcaps 
entries and works fine on both a PC console and a wyse 60 PC keyboard.

Besides, in our own applications we use function keys on even non-scan code 
terminals - all with termcaps. I'm sure more could be done in that direction.

>>        As for video, aren't you still stuck with dumb terminals as the
>>        main limitation? Unless they do FoxPro for X nothing will really
>>        change from that perspective.

>Yes and no.  The interface under Xenix is *very* primitive.  Again, the
>keyboard problems come to mind, but if you look at an application like
>WordPerfect, they are doing some mighty fancy keyboard and video functions
>on 'dumb' terminals.

I'm trying to think if they really do these things on a TV950 for instance. I 
don't think so. Only certain terminals with certain hardware qualifications 
make the grade into functionality. I also think that they use the scan code or 
PCTERM type emulation just like ms word.

>The problem is we need to port an application that is already running
>under DOS with a *very* specific user interface to Unix.  We need the
>advanced video and keyboard functions.

And I'm sure you'll find that a monitor does not make a dumb terminal look 
like it. There are solutions to the problem by using inexpensive PCs as 
terminals under various emulation facilities or something like Sun River under 
optics. Price wise there is not much difference anymore.

So if you need DOS tools and are not yet ready to climb to MOTIF it is perhaps 
best to stay there as the worlds are not quite yet the same.

Fred


-- 
W. Fred Rump 			office:		   fred.COMPU.COM	
26 Warren St.   	          home:     fred@icdi10.COMPU.COM 
Beverly, NJ. 08010                bang:   ...{dsinc uunet}!cdin-1!icdi10!fred
609-386-6846          "Freude... Alle Menschen werden Brueder..."  -  The Ode

alan@ahmcs.mq.com (Alan Mintz) (06/30/91)

In article <53@dworkin.UUCP>, shevett@dworkin.UUCP ( Sysop) writes:
) fred@compu.com (Fred Rump) writes:
) 
) >shevett@dworkin.UUCP ( Sysop) writes:
) 
) >>the FoxBase under Unix is too limited in keyboard and video handling
) >>to be worth it.
) 
) >What doesn't the keyboard do?
) 
) Under Xenix, there is no way to trap more key definitions than those 
) allowed under the termcap.  Our DOS systems use Up,Down,Left,Right,Home,
) End,PageUp,PageDown, and all 10 function keys.  We can't trap those
) keys in a meaningful way under Xenix.  It just can't do it.

To be more accurate, it takes more code to trap these keys. Using SCO Foxbase+
and the INKEY() function, we have done a number of unusual things like

- A full-screen text editor that DOESN'T have to store it's output in
  MEMO files.

- A replacement for @ GET that allows initial cursor positioning, multiple
  hot keys, variable length fields, return of key value that was used to
  exit the field.

- A screen that updates itself every n seconds automatically WITHOUT running
  a processor-consuming loop.

) >        As for video, aren't you still stuck with dumb terminals as the 
) >        main limitation? Unless they do FoxPro for X nothing will really 
) >        change from that perspective.
) 
) Yes and no.  The interface under Xenix is *very* primitive.  Again, the
) keyboard problems come to mind, but if you look at an application like
) WordPerfect, they are doing some mighty fancy keyboard and video functions
) on 'dumb' terminals.

What's fancy about using function keys (again - available through SET FUNCTION
or INKEY())? Admittedly, it would be nice to see support for bold/underline/
blink and color in the SCO (or future Fox) product. I tried implementing this
within Fox+, but the (color) sequences I was sending were getting intermingled
with cursor positioning sequences.

) >        We supply hardware and integration services to a software house 
) >        that sells a $60K foxbase application. They did not wait for 
) >        fancy video to come out. They simply automate warehouseing 
) >        applications.
) 
) The problem is we need to port an application that is already running 
) under DOS with a *very* specific user interface to Unix.  We need the 
) advanced video and keyboard functions.

Then wait for Foxpro/*NIX (1Q92). It is reasonable to presume that they will
allow color support on terminals that support color. The point is, it is
possible to develop dynamic, "pretty", user-friendly applications using
the existing product - it just takes more work.
-- 
< Alan H. Mintz  | alan@ahmcs.mq.com | ...!uunet!ahmcs!alan >

shevett@dworkin.UUCP ( Sysop) (07/01/91)

alan@ahmcs.mq.com (Alan Mintz) writes:

>In article <53@dworkin.UUCP>, shevett@dworkin.UUCP ( Sysop) writes:
>) fred@compu.com (Fred Rump) writes:
>) >shevett@dworkin.UUCP ( Sysop) writes:
>) 
>) Under Xenix, there is no way to trap more key definitions than those 
>) allowed under the termcap.  Our DOS systems use Up,Down,Left,Right,Home,
>) End,PageUp,PageDown, and all 10 function keys.  We can't trap those
>) keys in a meaningful way under Xenix.  It just can't do it.

>To be more accurate, it takes more code to trap these keys. 

Theree are two ways keystrokes can be trapped into SCO Foxbase:

	Readkey() - which returns what pre-defined key was pressed to exit
		a read function, and

	inkey() - which returns the actual ascii definition received by the
		program.

Using inkey(), you can make your system react to any sequence the terminal
throw at you, simply by trapping the entire escape sequence.  Likewise,
with readkey(), you may trap any COMPLEX string sent to the applciation,
and Foxbase will translate into one of the following pre-defined
sequences:

	Up		Down		Left		Right
	PgUp		PgDn		CtrlLeft	CtrlRight
	F1-F10		Insert		Delete

Our applications need many more keystrokes, such as Home and End,
Shift and Control versions of the function keys, etc.  We could write
our own handler for these functions, that would translate ESC-BlahBlah
into a Shift-F7, but the program would not be portable across
different terminals.  

>Using SCO Foxbase+
>and the INKEY() function, we have done a number of unusual things like

[Various neato functions that FoxBase cannot do included]

We too have done these under FoxBase for DOS, using inkey(), translated
to Function Keys and other keys.  We have written an interactive
BROWSE function to replace the brain-dead BROWSE in SCO Foxbase, but it
is very keyboard specific.

[Comments about lack of Video/Keyboard operations under Foxbase, while
WordPerfect for Unix does a *wonderful* job of handling odd terminals.]

>What's fancy about using function keys (again - available through SET FUNCTION
>or INKEY())? Admittedly, it would be nice to see support for bold/underline/
>blink and color in the SCO (or future Fox) product. I tried implementing this
>within Fox+, but the (color) sequences I was sending were getting intermingled
>with cursor positioning sequences.

We had this problem also, but again you end up writing an application that
is terminal specific.

(A thought comes to mind we played with - making a TERMCAP like system
for FoxBase, but this requires using, yech, macros.  Bleh - slow down city.

>) The problem is we need to port an application that is already running 
>) under DOS with a *very* specific user interface to Unix.  We need the 
>) advanced video and keyboard functions.

>Then wait for Foxpro/*NIX (1Q92). It is reasonable to presume that they will
>allow color support on terminals that support color. The point is, it is
>possible to develop dynamic, "pretty", user-friendly applications using
>the existing product - it just takes more work.

I agree with the 'more work' department.  I think it's too difficult to 
maintain a DOS product, then realistically port it to Unix, giving up 
so much to make the port.  I can't *WAIT* to see FoxPro for unix.  (Fact
of the matter is, I can't wait to see FoxPro 2.0 for DOS!

>< Alan H. Mintz  | alan@ahmcs.mq.com | ...!uunet!ahmcs!alan >

--------------------------------------------------------------------
shevett@dworkin.amber.mccc.edu | Dave Shevett - Lawrenceville, NJ
CSAccess BBS (609) 584-8774    | Keeper of yon FoxPro mailing list
--------------------------------------------------------------------