PORTING from page 6

PRESIDENT from page 1

I would say that was central prob-

lem for us, being forced to take a very

large application and, bit by bit, turn

in inside out to make it into a true

Mac-type application. A Mac-type

application is the same as a Presenta-

tion Manager-type application.

Writing of the original

FoxBASE + took us about seven

months, so it took us longer to make

it into a Mac product than it took us

to write it in the first place. It’s not

an effort to be undertaken trivially,

and we understand now that we were

a little bit arrogant in thinking that we

could just go galloping in to make it

work. It’s clear to me how making

Mac products can swallow up the en-

tire resources of companies for years.

Even to say that it was a nine

month project is a little bit of an un-

derstatement, because we’re still

working on some of the pieces.

So what about OS/2 now? Is your

original strategy the same?

DF: We had a very early beta test

copy of OS/2 before it was called

OS/2. We knew quite a lot about

what the design was; as I mentioned,

we’ve been having detailed discus-

sions with Microsoft since the begin-

ning of last year. We realize that we

have to have a product for that. With

OS/2 you have to distinguish relative-

ly sharply between the character

mode and the graphic mode.

What’s the implication for you?

Well, the structure of the Presen-

tation Manager under OS/2 is such

that the Presentation Manger version

of FoxBASE + will look very, very

much like the Macproduct. I suspect

the process will be largely subtrac-

tive.

OS/2 is actually a far easier en-

vironment to design for than DOS in

general. It does allow you very large

programs running in native mode.

The only real downside is that the

loading of segment registers is a hor-

ribly painful and expensive process

on the current OS/2, and the segment

architecture is a major limitation.

That’s not going to be removed until

they come up with a native 80386 ver-

sion that runs, so you can run all

small-model programs again. Multi-

threading in OS/2, on the other hand,

can really help a database system. If

it made economic sense, we’d just

LA. FOX

have OS/2 and Mac products, plus

maybe some Unix and Xenix

products down the road.

But that’s losing track of where the

money comes from. Probably our

major challenge for the next few

months is figuring out how to run ac-

ceptably under DOS, because the

kind of rigid memory utilization pat-

terns that traditional DOS products

have is just not good enough.

I have heard it said that dBASE

IV, for example, takes 20 to 30

seconds to process even the simplest

of SQL commands. I have to believe

that the reason is because they’re un-

loading most of dBASE IV and load-

ing in an SQL engine, processing the

SQL command, and then putting it all

back again. I suspect that that’s the

major performance bottleneck they

have right now.

What’s the future for DOS? Do

you think it will disappear?

DF: Well, it’s a consummation

devoutly to be wished, but it’s not

likely.

I take it, by the way, that there Is

no doubt in your minds that OS/2 Is

a success story.

WF: Primarily because it has the

three letters “IBM” in front of it,

regardless of its technical merits,

which it does have. Five years from

now it’ll be a great operating system.

There will certainly be new factors,

however. For example: in the charac-

ter-based environment, we don’t

worry about using different type faces

and sizes on the screen. In the graphi-

cal environment, they are expected in

a polished work. So just how do you

code the @ SAYs for an input screen

in a multiple-font environment where

one line may require more vertical

space than another?

The same problem exists for

reports. Even though multiple fonts

are generally possible on any given

printer, we PC developers tend

toward the prosaic in the design of our

reports. After all, you often don’t

know what kind of printer will be on

the other end of that parallel cable,

and it’s an awful lot of trouble, and not

much fun, to write the code to do spe-

cial effects on a bunch of different

printers. Since most of our end users

don’t expect anything fancy, either, we

tend to stay pretty generic (Courier

12-point on the LaserJet!)

As the graphical user interface

comes to the PC, and as Windows and

OS/2 gradually succeed in their goal of

insulating developers from hardware

specifics, the possibilities and expec-

tations will change in our world. Fox-

continued on page 8

Yellow Pages

[Free to L.A. Fox members. ]

Greg Dunn Associates (213)

D-I-S-C (Discovery Informa- J

371-6035. DOS, dBaselll, and

FoxPro training; FoxPro and Clip-

tion Systems Company), George

per programming; Telemagic

Dvorak (213) 539-2704. Ac-

sales and support; technical

countmate, SBT modifications,

documentation and demo diskette

custom LAN applications,

development. Redondo Beach.

hardware and technical support.

Torrance.

KD Associates, Krls Dablin,

Charles Williams, Macintosh

(213) 396-5632. FoxPro and

Consultant, (213)

generalPC consulting. Legal and

Macintosh Expertise + Manage-

barcode applications, legal time

ment Expertise. Foxbase+lMac

and billing package, contact

applications. Harbor City.

management package. Mar Vista.

Gay Dunn Graphic Design

(213) 371-6035. Graphic design

Unruh Consulting, Randy

and desktop publishing. Newslet~

LTnruh, (213) 390-8039. FoxPro

ters, logos, brochures, and ads.

and Clipper applications consult-

Redondo Beach.

ing. Santa Monica.

7