[All]
Historical Document: Delphi Product Definition 3rd Draft - May 13, 1993
By: David Intersimone
Abstract: Zack Urlocker, Delphi Product Manager, wrote the product definition for Delphi version 1.0. This is the HTML version of the 3rd draft, dated May 13, 1993. Notable items include the original target dates and technical terms like "lotsa".
Delphi
Product Definition
3rd Draft (incomplete)
May 13, 1993
Zack Urlocker
I. Executive Overview
We will create new "Windows only" Pascal products (code name Delphi) to compete directly with Visual Basic and revitalize the Pascal market. Delphi will offer better performance, more capabilities and more tools than Visual Basic and will be targeted towards vertical market developers and departmental programmers. We will follow up six to nine months later with 32 bit versions of Pascal for DOS and Windows.
Availability:
II. Proposed Schedule
|
| EBT | Jun 07 | Jun 21 |
| Beta 1 | Aug 09 | Aug 23 |
| Beta 2 | Sep 13 | Sep 27 |
| Beta 3 | Oct 18 | Nov 01 |
| Gamma | Nov 22 | Dec 06 |
| FCS | Jan 03 | Jan 17, 1994 |
III. Product Strategy
A. Delphi 8.0 for Windows
This is targeted to new customers. It will have a low SRP and will be sold almost exclusively through the retail channel and positioned directly against Visual Basic. Current Pascal customers will be up sold to Delphi Pro.
B. Delphi Pro for Windows 8.0
This is targeted to new customers as well as upgrade customers. It will have an intermediate SDP and will be sold through both retail and direct mail. It will be positioned directly against Visual Basic Pro.
IV. Target Market
Delphi is targeted to application developers who want the highest possible productivity in creating efficient applications. This includes programmers in vertical markets (e.g. construction, health care, consulting), departmental programmers and professionals who program in order to accomplish their job (e.g. scientists, engineers, network administrators). These customers are characterized by their willingness to use whatever tool that "gets the job done". Many of these programmers are long time Pascal users on DOS.
High on their list of priorities are:
A. visual design tools
B. fast, incremental application development
C. ability to create applications without learning new concepts
D. ability to use existing components rather than write new code
E. efficient performance of resulting applications
F. standard windows look and feel of resulting applications
G. ability to access standard databases
H. ability to create forms and reports
I. price sensitive
Low on their list of priorities are:
A. compliance to language standards
B. cross platform portability
C. language features
V. Competition
Our chief competitor is VB 3.0. We must be sure to beat VB 3.0 in some significant, but not necessarily all, areas.
A. VB Position
1. The fastest way to program for Windows
2. Very easy to use, but has limitations for pros
3. Use VB for easy apps, use VC for components
B. VB Strengths
1. Integrated visual design tools for building UI
2. Easy to prototype apps and build incrementally
3. Few concepts to learn; just drag, drop, write code
4. Easy access to databases through "data aware" controls
5. Easy access to databases programmatically
6. Easy access to ODBC, SQL
7. Includes database components, report writer tools
8. Can use DLLs, VBXs, OLE 2.0 objects written in C
9. Ease of Basic language
C. VB Weaknesses
1. Primarily for single person development
2. Speed/space inefficiency of large runtime and slow interpreter
3. Non extensible (can't create DLLs, VBXs or OLE 2.0 servers)
4. Some limitations in Access engine
a) can't restructure dBASE, Paradox tables without conversion
b) can't use dBASE, Paradox indices
5. Doesn't scale well for medium and large applications
a) Language limitations of Basic
b) Limited debugging tools
c) Poor source code management
VI. Delphi Points of Differentiation
A. Faster performance and better runtime efficiency (compiled)
B. Extensible (create DLLs, VBXs, OLE 2.0 servers)
C. More visual (browsing, inspectors etc)
D. Easier to use (better help, CBTs, docs)
E. Better native database support for dBase, Paradox
F. More debugging views (disassembly, watches, registers, inspector)
G. More debugging tools (TDW, Winsight, Winspector)
H. Better source code management (class, project browser)
I. Better language (structured, strong typing, OOP)
J. Generates working help system
K. Scales better for medium, large apps
VII. Product Component Matrix
| Feature | Delphi | DelphiPro | VB3 | VBPro |
|---|
| A. Windows IDE | Y | Y | Y | Y |
| B. Windows UI Builder | Y | Y | Y | Y |
| C. Windows GUI Debugger | Y | Y | Y | Y |
| D. Windows project view | Y | Y | (1) Y | Y |
| E. Standard components | Y | Y | Y | Y |
| F. Use VBX controls | Y | Y | Y | Y |
| G. Windows object help | Y | Y | | |
| H. Windows experts CBT | Y | Y | | |
| I. Windows Inspectors | Y | Y | | |
| J. Windows Objectbrowser | Y | Y | | |
| K. VCL Windows class library | Y | Y | | |
| L. Component building | Y | Y | | |
| M. Advanced components control pack | Y | Y | | |
| N. Database access (dBase, Pdx, SQL) | Y | (2) | Y | |
| O. Report Writer | Y | (3) | Y | |
| P. Database Desktop | Y | ? (4) | Y | |
| Q. Command line compiler | Y | ? | | |
| R. DOS target | N | ? | | |
| S. Newt OLE 2.0 server support | N | ? | | |
| T. Resource Workshop | Y | ? (5) | | |
| U. Winsight | Y | (6) | | |
| V. WinSpector | Y | (6) | | |
| W. OWL | N | ? (7) | | |
| X. RTL source code | Y | ? premium | | |
| Y. Turbo Debugger Win / TASM | N | ? up sell (8) | | |
Notes
1. Project view to be defined
2. VB Pro includes "access" engine and ODBC
3. We will bundle Crystal Reports, same as VB 3.0.
4. Database desktop must be extended to allow creation and restructuring of tables; VB's is written in VB
5. New features include browsing, extensible OLE editing
6. No new features
7. For compatibility only
8. TDW 4.0 has new features including
a) new "virtual" screen running in a window
b) new session state saving (e.g. windows, breakpoints etc)
c) new higher capacity
d) new exception views
e) Note: current TDW 3 is not compatible with Delphi!
f) Protected mode hosted TASM (higher capacity)
VIII. Components list
Here's a list of the standard and "advanced" components we need to build. This is a tentative list and its likely that some components may move from the "advanced" area to become "standard" or vice verse depending on competitive issues with VB 3.0.
A. Standard components (required) - These are necessary to match VB
1. standard Windows controls
2. 3D user interface controls (MS 3D)
3. common dialogs
4. timers
5. MDI
6. Drive/directory/file list components
7. validated input fields, formatted output
8. images (bitmaps, icons etc)
9. drawable graphics
10. icon speedbar
11. status bar
12. grid control
13. OLE 2.0 client
B. "Advanced" components control pack (BPW only) Some of these may be from third party libraries.
1. ODAPI database access (dBASE, Paradox and SQL access)
2. database table control (inherits from grid?)
3. database browser controls
4. database query control
5. database report writer (crystal reports)
6. database desktop (with extensions)
7. OLE 2.0 server capabilities
8. OLE 2.0 analysis & testing tools
9. MAPI
10. 2D/3D business charts (with printing)
11. asynch comms
12. printing stuff: preview?
13. scrollable dialog support?
14. Currency support (same as VB)
15. multimedia player (video, sound)
C. "Nice to have" bonus components. These could be "standard" or "advanced" components or examples featured on a separate bonus disk.
1. gauges (status bars, % complete etc)
2. spin control (e.g. increment/decrement control)
3. animation
4. outliner (with descendants for disk directory)
5. Borland style mufti-page dialogs
6. DDE
7. Obex
8. expression evaluator
9. grep search component
10. color palette
11. paint tool palette
12. time/date controls
13. calendar
14. magnifier component or tool
15. spy message viewer component or tool?
16. LED-style displays (equalizers, digital displays, wave forms)
17. rich text editing
18. games pack: cards, chess, checkers, bonk, screensaver, etc
IX. Features details
A. Docs
1. Easy, accessible streamlined docs
2. Printed tutorials
3. Printed reference
4. Pro manual
5. CBTs
6. ObjectHelp
7. MS Win Help
B. IDE
1. integrated UI builder
2. integrated GUI debugger
3. integrated project viewer
4. code browser (frodo window)
5. class browser with enhancements
6. outlining
7. CBT / object help support
8. Non MDI?
C. GUIDO
1. integrated debugger similar to DOS IDE
2. single step over, trace into
3. call stack
4. register window
5. watch window
6. conditional, pass count breakpoints
7. expression evaluator
8. inspector
9. DLL debugging (e.g. multiple symbol table support)
10. disassembly view (CPU viewer)
D. UI builder
1. extensible palette
2. property editor
3. menu / accelerator / menu hints editor
4. dialog builder
5. integrated bitmap/icon/cursor editor
6. speedbar editor
7. statusline editor
8. generate help files automatically
E. Project Viewer
1. view all units, forms, DLLs, resources in project
2. mufti target
3. define "make" logic for apps
F. Language
1. easier OOP
2. exception handling
3. properties
4. new case statement optimization
5. dynamic arrays?
6. big arrays?
7. easy collections, linked lists
G. RTL
1. lotsa new functions (string conversions, parsing)
2. international unit (non-wide chars)
H. Upgrade issues
1. compiles all existing TPW, BPW code with no changes
2. automatically convert RES files into new UI format
3. manual includes chapter on converting existing OWL code, resources etc
I. Delphi Localization Issues
1. Probable Localizations
Based on current localizations and stated policies; unconfirmed with subs.
| Country | Type | Schedule |
| Germany | Full | Simultaneous |
| France | TP8: Full | Simultaneous |
| | Pro: Docs-only | Simultaneous |
| Spain | Docs-only | Post-FCS |
| Czech | Full | Post-FCS |
| Russia | Full? | Post-FCS |
2. Potential Localization Problems
A. Doc & Help Change Volumes
We expect that both the paper doc and the online help will have to be completely retranslated from scratch for this product. New CBTs will also need to be translated from scratch. This adds up to a large volume of translation work. This is somewhat mitigated by the bonus of not having to manage updates of older materials. Simultaneous schedules probably won't be endangered by such large volumes.
B. Possible Schedule Conflicts
The translation facilities at the subs (and to a lesser extent, the international resources here in SV) could be overwhelmed if Delphi overlaps the BCW 4, TCW 4, an/or BCDOS 4 projects. In this case we'd have to work with the subs to decide which projects get the resources first, which of course would significantly decrease the possibility of simultaneous or near-simultaneous shipments of some of these projects.
Latest Comments View All Add New RSS ATOM