7

PORTING from page 6
PRESIDENT from page 1
I would say that was central problem 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 Presentation 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 entire resources of companies for years.
Even to say that it was a nine month project is a little bit of an understatement, 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 discussions with Microsoft since the beginning of last year. We realize that we have to have a product for that. With OS/2 you have to distinguish relatively sharply between the character mode and the graphic mode.
What’s the implication for you?
Well, the structure of the Presentation 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 subtractive.
OS/2 is actually a far easier environment 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 horribly 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 version 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 acceptably under DOS, because the kind of rigid memory utilization patterns 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 unloading most of dBASE IV and loading 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 character-based environment, we don’t worry about using different type faces and sizes on the screen. In the graphical 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 special 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 expectations 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

7